Because Umbraco is a CMS with more involved than a static site, I'm wondering what y'all do to handle temporary development requirements when the existing website/domain has to stay live while getting the new one ready.
With a static site, I just set up the new hosting account and use a temp domain for dev, then switch the DNS for the real domain to point at the new account when it's final. I think if I do that with Umbraco, something in the db content may end up pointing to a bogus url and I'll have to clean it up by hand.
The first couple Umbraco sites I did were for completely new domains so I didn't have to worry about it. This one is a conversion and I can't take down the old site until the new one is ready. I've also been able to avoid learning much about the webconfig, etc, with SoftSys's great support, so I'm hoping there's a methodology I can follow.
If so then you can add an entry to your hosts file (typcially C:\windows\system32\drivers\etc\hosts) so that the URL points to the new IP address.
Assuming you can browse to the existing site with both "http://www.mysite.com" and "http://mysite.com", you can only add the "www" record to your hosts file. This enables you to view the original site under the non www record, whilst viewing the new site you are working on with the www record.
I use the same tactic you do, even when the site is going to live on the same domain.
Create new site (same webserver, or elsewhere)
Temporary point a dev domain (or subdomain such as dev.mysite.com) to the site, create site.
Update DNS (or webserver settings) to point to new site.
If your dev site is doing to be available on a URL that is publicly available (i.e. not IP restricted), make sure to add a simple username/password requirement on the site - this will stop Google and other sites that use spiders/bots to scan sites out - keeping your dev site out of search results.
Unlike Wordpress, Umbraco doesn't store the URL of the site in the database (unless you've made it do that somehow) - this means that when you want to move a site, change the domain or such, you shouldn't have to touch the DB or run any updates. URL's in the content should also be relative.
This means that you can easily change the domain of your website, without causing issues with the DB (or in this case, point a different domain to the site).
Is there something specific regarding the contents of the Umbraco DB and domains/URLs that you're concerned about?
Thank you both very much, this is helpful. @Drew, no, nothing specific, just not entirely sure how things functioned in there and didn't want to create a mess I'd have to clean by hand. Relative URL's makes sense and reassures me that I can do preliminary dev locally, which was at least as much concern as getting through the pre-live final approval phase.
best practices for juggling old and new websites/domains
Because Umbraco is a CMS with more involved than a static site, I'm wondering what y'all do to handle temporary development requirements when the existing website/domain has to stay live while getting the new one ready.
With a static site, I just set up the new hosting account and use a temp domain for dev, then switch the DNS for the real domain to point at the new account when it's final. I think if I do that with Umbraco, something in the db content may end up pointing to a bogus url and I'll have to clean it up by hand.
The first couple Umbraco sites I did were for completely new domains so I didn't have to worry about it. This one is a conversion and I can't take down the old site until the new one is ready. I've also been able to avoid learning much about the webconfig, etc, with SoftSys's great support, so I'm hoping there's a methodology I can follow.
Any guidelines for this?
Hi Matthew
Is the new site on a separate host ?
If so then you can add an entry to your hosts file (typcially C:\windows\system32\drivers\etc\hosts) so that the URL points to the new IP address.
Assuming you can browse to the existing site with both "http://www.mysite.com" and "http://mysite.com", you can only add the "www" record to your hosts file. This enables you to view the original site under the non www record, whilst viewing the new site you are working on with the www record.
Hope this helps / provides a solution for you.
Cheers, Nigel
I use the same tactic you do, even when the site is going to live on the same domain.
URL's in the content should also be relative.
Drew
Thank you both very much, this is helpful. @Drew, no, nothing specific, just not entirely sure how things functioned in there and didn't want to create a mess I'd have to clean by hand. Relative URL's makes sense and reassures me that I can do preliminary dev locally, which was at least as much concern as getting through the pre-live final approval phase.
Thanks again.
is working on a reply...