How to clone a site on same server for dev and pre-rollout?

Hi, am struggling to clone an original typical nopCommerce install site (called say MySite) onto a Mirror site (MySiteClone), so we can do dev and pre-rollout on it before pushing deployment to live. It should use the same web and DB server as live MySite.

In prep, have restored the original DB into a new DB (called, say MySiteSQLDBClone). In a new website directory (IIS site created and bound to clone.mysite.com), all the files from original MySite are copied, and then:

1. App_Data\Settings.txt edited to update to new DB:
DataProvider: sqlserver
DataConnectionString: Data Source=INSTNAME\SQLSERV001;Initial Catalog=MySiteSQLDBClone;Integrated Security=True;Persist Security Info=False;MultipleActiveResultSets=True

2. In the new MySiteSQLDBClone, edit dbo.Store so that the URL field changed to http://clone.mysite.com/ (similar for SecureURL).

3. Recycle the app pool for clone.mysite.com.

I would have optimistically thought that this should be all that is required, however browsing to clone.mysite.com redirects to www.clone.mysite.com!. This, of course, fails to even load.

This is a bit of a mystery to me, as there's nothing I can see in IIS that redirects this, so can only assume its in the nopCommerce.

Are we missing something?

TIA, Phil.

Have a look at the WWW prefix requirement setting in Configuration > Settings > General And Miscellaneous Settings > SEO settings.  Is it set to pages should have WWW prefix?

Ok, so assuming nopCommerce only likes www hostnames (likely due to licencing), I used a new domain www.newdomain.com and pointed it to the server and MySiteClone directory through IIS (and updated the DB URLs of course). Waited an hour for TTL to kick in and recycled app and now it does now load the commerce site under this new domain name, great!

It warned me about the invalid SSL Cert which is fair enough - it would not be valid on this clone site unless I buy another for that or use a wildcard, so I accepted the exclusion rule for now. Should not impact this issue though.

However... on making a change to the DB, (eg Content Topic Page), I checked and it's applying it to the original DB not the Clone!

Yet, as previous stages noted, I have def set the APP-Data\Settings.txt to the new Clone DB! So why (even after recycle) is it still pointing to the original DB? Grrr.

Must be something in the compiled code - even after recycle/iisreset, it does not seem to load the new Settings.txt into the new clone site.

The whole point of this is to be able to quickly setup a dev site from any current live, to test changes on. This would be much quicker than having additional source recompilations which need constant resynchs before deployment. Am sure there is a better way to test, upgrade and rollout, but all the docs/posts I can find are just about a base install.

Any ideas welcome!

Excellent point Pete, good one - and that'll be what that behaviour is then! Easily sorted with your note.

Sorry, crossed posts, have gotten round this www bit now but still need to somehow update the DB pointer on the cloned site to make this work?

The settings.txt is the only place the db connection string is stored. It gets read from the text file when the application starts (you can follow the code through from the global.asax in the nop.web project).  I'd double check that you're editing the correct file and that your IIS site is definitely pointing at the folder you think it is and your bindings are setup correctly.  Try changing settings.txt to an intentionally wrong connection string - you should get a No database instance exception when you restart nop - that will at least reassure you that you're editing the correct file.  If not, something else is amiss.

Thanks for the heads up - that is good to know and yep, changing the connection string was ignored, whereas changing it on the original live site does whack it into No Database Instance. Bindings and home dir all correct. Just the SSL binding suspicious so thanks to your conf, revisit that - and work out that although it looks (from the browser) like the site stays on the new Clone site domain even with the SSL Exclusion, what it actually does is slip it under to the default 443 socket, which for this same IP happens to be the original site, d'oh!

So, setting the clone's dbo.Store SslSetting=False instead of True stops it moving to SSL... and great, browser now stays on the clone's site where changes are indeed made to the clone DB too!

Will remember to get rid of that www prefix to hopefully avoid having to add new domain too in future.

Hope this helps somebody else in a Homer moment, many thanks for your help Pete, much appreciated!

Phil