Hello my questions is in regards to copying one Dnn installation over to another place so that one could be for production and the other development let me explain the issue.

Back a couple months ago I got involved with this dotnetnuke site that was already in production.  So the issue was I needed a development environment that simulated the production environment.  So what I did was add a portal alias to the production portal for localhost.  I than installed sql2005 express and got everything wired up correctly.  Once I got the development environment on my windows xp pro to interact with my sql 2005 express server on my computer I found that the site slowed way down taking me about a minute to 2 minutes per click. 

As you can imagine this was not well suited for a development experienced upon asking around I discovered windows xp pro was not best suited for the job of serving data that continuously came from a database but I would rather need something like Windows server 2003.  Upon looking at my options I opted to go with another account with my hosting company for development purposes since they kept up and maintained hardware, servers, etc... for optimum speed.

Well Suffice it to say I did the same thing as I did for localhost except I did it for this other account which by the way is attached to a different domain.  I did just as I did for localhost copied the dnn files to where the domain was pointing than backed up the database and restored it into its new home and of course did all the wiring I needed to do via web.config.  Well Suffice it to say it kept redirecting me back to the web site in which I took the back up from. 

Remembering that I forgot to add another alias for this new domain on my main portal I went ahead did that and rebacked up the database to restore it again on the host server.  Well this time it took however like the localhost version this version was no faster.  This makes me believe that the reduction in speed is do to the dnn application possibly do to creating an alias on the main portal to point to this domain.  Even though I was using a copy of the database on this other server apprently there has got to be some issue with creating an alias on a production server backing up that database and plunking it in a new home for development purposes.

I am not sure what to do here, why creating an alias to another domain when you transport taht whole database to a another server and point to that new location would cause such a slow down as 1 minute or more per click but I can't imagine it is the server anymore since it is hosted with the same host that hosts the production side which works great. 

Is their any suggestions out there of the best way to make a carbon copy of a production site to a new location for development purposes.


----------------------------------------------------------------------------------------------------------------------

The other issue I found myself running into is that in the production server dotnetnuke is in the route directory and hence all the links that link to external files in the ftp server start from the root.  This is a great idea in most cases however in my case while the DNN that is in production has all its core files in the root the development area is set up to have all its core files in a sub directory of the root called bvbdev.  The reason I chose this alternative for the development side is do to the fact I have another app running on this same account in another sub folder.  An app that is not DNN compliant and so I felt in order to host both web applications and not run into problems because one is encapsulating another I opted to use two domains one for the development environment for DNN and one for my store app.  Than I set up a default.aspx script that routed the domain name to their respective sub folders hence the only thing that lies in the real root of thsi account is that default.aspx that routes the domain to the correct folders so when you type the domain in you immediately come to the subfolder. 

This works great for the store as I am building that from scratch and not trying to reproduce a carbon copy of an already functional store as is the case with this dotnetnuke issue.  Hence because the production side of dotnetnuke has all of its files in the real root of the account and the development side has all its files in a sub folder of the account I have run into this interesting dilemna.

Therefore I have come here for guidance I was wondering do you know where in dotnetnuke the place is that draws out the starting path for folders, files, etc... right now the starting path is "\" but I need it to be "\bvbdev" so that when it looks for the skin of the site it will be going to \bvbdev\portals and not \portals

I don't know maybe I need to just start from a fresh application and than specify the starting path from the installation process and than copy tables from one database to another to generate the feel of the web site that is now in production.  What would you guys suggest I do can I change something in web.config that would dynamically cause dotnetnuke to generate a path starting with a subfolder like "\BVBDEV" at run time or is this not possible or easy to do.

Of course the second question which is just as important is the speed issue and how it might relate to using an http alias of the same portal that the main production installation is on.  Should I rather create a new portal a parent portal and if so is their a way to copy all the attributes of the site I created the new portal from or do I need to reupload all the skins I want, etc... I noticed when I looked at this option that the only skin choice I had besides non specified was the generic dotnetnuke skin.  I didn't see any of the skins show up as an option to use on a parent portal that was on the main installation.

So if you have any ideas of the best way to make a carbon copy of a production dotnetnuke site on another server for development purposes and also how to globally tell dotnetnuke to generate a new starting path for the external files (like skin files) it needs to link to so there are no broken links or other funny things like flash not working or dnn:menu token not showing up etc....

Thanks for any ehlp you can provide me with

Bo

I'm not sure why your localhost version is running so slow, I find my localhost versions actually run quicker than the live website.
I am running various versions, but 1 of them is:

windows XP Pro
SQL Server Express

(This is on a virtual PC so it's running inside another windows XP operating system) - I can run several at once, so it should show that you should be able to run this as a development environment.

This computer is 3Ghz dual core - 2GB mem
Laptop can also handle it - 2.4Ghz dual core 2GB mem

Old Laptop was a P4 2.4Ghz - 512MB ram and was able to run DNN without problems locally in win XP with SQL Server (this was prob. v3 dnn)


As for URLs, the method I have used is:

Find and Replace SQL queries for DotNetNuke
(To fix problems after transferring a localhost database to a live website and other useful functions)

- this may not fix all of your problems but it will give you a starting point, it's mainly aimed at URLs in the text HTML module, but can be adapted.

Hi guys, I've recently moved a live (5.2.4) installation to my localhost using the article in DNNC#22. Great article, and all my portals seem to work as expected. Also, as expected, all images and links don't work as the relative URL path was specified on the live server. I just wanted to know if the find/replace SQL query still works with version 5? I noticed that Mitch Sellers had a module that would do the same link updates, but no longer functions with DNN 5+. If this find/replace query no longer works, is it best practice to specify the full URL for links/images on the live server so these continue to work even when the installation is transported to a different location, or is there a better method of doing this? Thanks, ~Chris

The FREE F3 module from Engage Software (engagesoftware.com) works with DNN 5.x and does a great job in a WYSIGYG editor environment.  It's much friendlier that SQL find/replace.

Thanks for pointing me in the right direction, Joe. I appreciate the help.

This utility seems most useful when going from localhost to live where you do a global search for "/localhost" then replace it with nothing so the links work on the hosted server.

This will also certainly speed up the process of going from live to localhost so you don't have to go to each page individually and modify the link/image path. However, you still need to identify each path individually and attach the local alias to it to get it to work on the test server - e.g. need to find "/Portals/0/images/picture.jpg" and replace it with "/{localalias}/Portals/0/images/pictures.jpg".

For this reason, is it generally best practice to use the full URL instead of the relative one for paths and links? I was setting up the site with relative paths just in case someone wanted to move it to another domain. (Of course, I guess I could use the F3 utility to change the domain name.) Or, am I missing something and there's a better way to do this?

Thanks again,
~Chris

I've really not thought too much about what would be a "best practice" but your suggestion seems reasonable.

Generally I do like to use full URLs for that reason, but as you mention you will need to make changes if you move to another domain. I guess it depends on what method you find quickest to implement and how often you will be moving from local to live and vice versa.

Great. Thanks a lot for your input, guys.
~Chris