Best Practices for migrating your website or web site content over to DotNetNuke
With DotNetNuke you can quickly build and edit a website using only your web browser. DotNetNuke websites are made up of Pages and Modules.
Pages provide a place for you to display your site content. These Pages are made up of one or more Modules. Modules define the functionality that can be added to a page. DotNetNuke has many built-in modules including, Text, Table, Events, Links, Picture and more. In addition, many more modules are available from the community including Web Forums, Blogs etc.
Building a new Website with DotNetNuke involves the following steps:
- Install DotNetNuke on your computer.
- Sign up with a Web Hoster who provides DotNetNuke hosting accounts. This Web Hoster will set up a blank DotNetNuke website for you.
- The Web Hoster gives you login information. Log in to your DotNetNuke site using this information.
- Using DotNetNuke, add pages, modules and select skin for your website.
Suppose you have an existing website and you want to use the database provided with the existing website.
Suppose in an existing website you have a MSSQL database that contains data to be displayed. If you've got a legacy database that contains hundreds of tables, procedures, views, etc. it may not be practical to move everything into your DNN database or build the DNN database within the legacy database. Here one can define the database connection string via a reference in Web.Config. This database will co-exist with the DotNetNuke database and be accessed by the DotNetNuke site. The content can be used by DNN site via following steps:
1) In Web.config Within
2) Within add key for mydata's connection string - similar to SiteSqlServer - but pointing to appropriate server/database.
3) Within Added
type = "myStuff.myProject.Data.SqlDataProvider, myStuff.myProject.SqlDataProvider"
connectionStringName = "mydataserver"
providerPath = " -- appropriate path --
objectQualifier = ""
databaseOwner = "dbo"
upgradeConnectionString = ""
/>
4) Set the Assembly Name for the MyProject to myStuff.myProject. A dll should exist in \bin directory where dotnetnuke.dll exist called myStuff.myProject.dll
5) Set the Assembly Name for the SQLDataProvider to myStuff.myProject.Data.SQLDataProvider. A dll should exist in \bin directory where dotnetnuke.dll exist called myStuff.myProject.Data.SQLDataProvider.dll
6) Set the Namespace for DataProvider to myStuff.myProject.Data.
7) In my DataProvider.vb class that must inherit DataProvider, change the CreateProvider sub to
objProvider = Ctype(Framework.Reflection.CreateObject("mydata", "myStuff.myProject.Data", "myStuff.myProject.Data"), DataProvider)
8) In my SQLDataProvider.vb class that inherits DataProvider, set the ProviderType = "mydata"
You might want to add an additional descriptor to the convention here so that myStuff.myProject becomes myStuff.myProject.myModule, but that is personal choice.
Generally, with the existing websites or systems, one wants to switch over to DNN as a base for providing the portal-functionality that we need in many areas of the application. Most of the sites going for DNN are workflow application but large parts of the site are content heavy and should be updated by certain groups of users with specific security roles. A lot of VBscript code that does page HTML rendering, so is a first pass at "hosting" DNN within the existing ASP application. Eventually all HTML logic is to be replaced with .NET code, but here comes the point as to where we can host DNN and some off-the-shelf modules and make the site running, follow the following steps:
1. In the ASP application: create a .asp page which creates a javascript with three variables: htmlMenuAndTopLeft, and htmlMain, and htmlStyleAndScript. These variables are loaded up with the HTML content needed to render the client interface.
2. Create a DNN skin that references the .asp page from the legacy application.
3. The DNN skin uses client-side document.write(htmlMenuAndTopLeft) .. etc to place the HTML "wrapper" around the DNN contentpanes. This way, all the links, CSS, and images etc point to the proper location. The content area of DNN is generated from 100% .net code.
However, if you have to install DNN tables/stored procedures into an existing database an object qualifier of DNN is a good option. Here other features like role-base security for selective display of content and functionality can be used.
A designer shouldn’t be in charge of migration of an existing site to DNN site. The work should be assigned to the developer who might be able to write scripts or code to perhaps assist in importing of data. Regardless of how much you try to automate, its' really an initial hands on job of copy and pasting of information to a certain extent. The key area to look for is when copying and pasting data, to make sure it's nicely pasted without taking the other formatting into the page. This is only about the content but the original look and feel is not intact here.
If you want the original look and feel of the site and the work ids assigned to a designer, the knowledge of DNN architecture, concepts of skinning, or experience in CSS or html is a must. Get a dev environment setup , copy the content and add the pages. Initially you can provide the layout using the default skinning scheme but once the site is up more and more intricate schema can be build to let the site preserve original look and feel.
Suppose you are working on a site and want to transfer data to DotNetNuke This data conversion is possible by exporting your existing data in tabular format and then use that data to import into DNN. This typical procedure requires mapping of all your existing data to the required formats. Depending upon how much data you have, it may be more efficient to go through the process of recreating some pages in DNN and then import certain other data that make sense. For example consider a specific situation of moving data from phpNuke to DotNetNuke. The core PHP-Nuke modules are somewhat similar to the DNN modules. One can initially find the modules that correspond to each other in basic functionality:
1) The PHP-Nuke Content Module is similar to DNN Core Text/HTML Module.
2) The PHP-Nuke News Module is similar to DNN Core Announcements Module.
3) The PHP-Nuke Gallery Module is similar to DNN non-core DNNGallery Module.
4) The PHP-Nuke Downloads Module is similar to DNN Core Documents Module and non-core DNNDownloads Module.
5) The PHP-Nuke GBook Module is similar to DNN non-core Bring2Mind Guestbook Module.
6) The PHP-Nuke Feedback Module is similar to DNN non-core Feedback Module.
At time when you are moving to DNN from existing website, there might be certain complicated web pages or web forms which you don’t want to alter for example those with intricate calculations or analysis forms or certain other forms where particular formatting is a requirement. Here you find out ways so a static web form can be used in DNN.
If multiple instances of these pages don’t hamper your basic design, a simple way out it to make each of these programs as modules and then insert them in to DNN portal. Modules are the best suited for web items that are intended to be used at multiple instances in your web site and have a need to communicate with databases to store/take the data from a particular instance. Here you must check with the data Pages with these Modules are caching during page loading. If data is large then you might need to throw some of that information within the page onto the database to avoid slowing. But there is a drawback as the design incorporated through making these web pages Modules may slow down your site making it less efficient. But there are certain pages, web forms/programs etc which do not need to communicate with databases. They just take the data that user provided do the engineering calculations etc, get the results and post it back to the user. Moreover since these web forms are unique, multiple instances of these programs may not be needed. The way out here is to use the Links module (standard) and link to the pages in a new window. Or, to give website a consistent look use the I-Frame module and nest the page as an I-frame within DNN.