Most newcomers to building a web site simply put their site in the root folder of their web space. On an offline development site they put it in the root folder provided by a WAMP or MAMP server installation. For a live site, they buy a domain name and a cheap shared hosting account and put their files in the root folder of the web space provided.

There is nothing fundamentally wrong with cheap shared hosting accounts. For some sites they are a perfectly adequate solution. However, with a little forethought there are much better ways to organise your concrete5 site that to simply install it in the root folder of your web space. The big problem with using the root folder is that once you put your site in it, there is no convenient way to add anything else that does not become implicated in that site.

Rather than continue beating about the bush, here is how I like to organise my web space, both on my development systems and on live servers.

I never put anything in the root. I always work in sub-folders of the web-root. Rather than installing concrete5 in:

/web-root/my-site-files-and-folders...

I create a sub-folder (or sub directory if you prefer that terminology, they are both the same thing), and put concrete5 in the subfolder:

/web-root/cms1/my-site-files-and-folders...

For a live site, I then use the host control panel to point the domain name www.mysite.com at /web-root/cms1/, so anyone visiting www.mysite.com will now be visiting the concrete5 site at /web-root/cms1/.

www.mysite.com  -> /web-root/cms1/my-site-files-and-folders...

For an offline development site, I could create a sub domain of the usual 'localhost' address, but I usually just visit the site at http://localhost/cms1/ and take it from there.

Why is this way of doing things so much better?

Because if I want to have another installation of concrete5, I can put it alongside the existing site, rather than be forced to work within the folders of the existing site. If I create three more MySQL databases I can now have:

/web-root/cms1/my-site-files-and-folders...

/web-root/cms2/another-my-site-files-and-folders...

/web-root/cms3/and-another-my-site-files-and-folders...

/web-root/cms4/and-yet-another-my-site-files-and-folders...

The only difference between these sites is a sub-folder, so I never have to worry about moving or copying sites from a sub-folder to a root folder.

Lets take a step back to just the one installation of concrete5 and the domain that I started with:

www.mysite.com  -> /web-root/cms1/my-site-files-and-folders...

Now suppose there is an upgrade to concrete5. 99% of upgrades work flawlessly. But on the concrete5.org forums we have all read the disaster stories from the 1% of sites that don't. By working cleverly with sub-folders, you can make sure that never happens to you.

Use a cloned site for safe upgrades

Rather than run an upgrade on a live site, I can make a copy of the database and a copy of all the files, then use the host control panel to create a sub-domain to point to the clone:

www.mysite.com  -> /web-root/cms1/my-site-files-and-folders...

www.test.mysite.com  -> /web-root/cms2/copy-of-my-site-files-and-folders...

I can now run an upgrade and then test it on this cloned copy of the site. Whether it works or not, my live site is never at any risk. If it doesn't work, or I learn something and think I could do it better, I can repeat this process as many times as I want until the upgrade is perfect.

www.test-again.mysite.com  -> /web-root/cms3/another-copy-of-my-site-files-and-folders...

If the upgrade works and all tests pass, I can now simply use the host control panel to point my domain name at the upgraded site. The upgraded clone now becomes my live site.

www.mysite.com  -> /web-root/cms2/upgraded-my-site-files-and-folders...

Even then, should anything go wrong, I can always point the domain name back at the pre-upgrade site in /web-root/cms1/.

The complication of eCommerce sites

The whole process becomes a little more complicated for sites with user generated content such as forums, or eCommerce sites with orders busy taking place.

The difficulty now is that during the time it takes to make the upgrade, the original site in /web-root/cms1/ could diverge from the copy made in /web-root/cms2/. If I just made the clone live, any orders made since the clone was taken could be lost!

For these sites I like to plan from the start for at least one further clone. The first clone is always just for practice, as are any subsequent clones until I am 100% happy.

Once I have everything worked out and I am sure I can repeat the process reliably, I put the live site into maintenance mode. This prevents the content from diverging while I make a final clone. I then upgrade the clone and work through whatever I have learned with previous practice updates, then use the host control panel to point the domain to the upgraded site, making sure it is out of maintenance mode. The upgraded clone is now my live site.

www.mysite.com  -> /web-root/cms3/upgraded-my-site-files-and-folders...

While the live site may have been in maintenance mode for a while, it is never at risk from a failed upgrade. While it is in maintenance mode, no forum post have been made and no eCommerce orders taken, so they can't get lost when the domain name is pointed at the successful clone.

This process may seem long winded, but it has the big advantage of never risking a live site.

Finally, with an upgrade happily running, I make a full files and folders backup. I use my Backup Voodoo addon for both cloning and backing up. But that is not the only way, you can always use a combination of the built in concrete5 backup, your web host's control panel, the system console and FTP.

My host ties my domain name to my web root

Some web hosting services insist that the web root has a domain name pointing to it. If that is the case, how can you change the domain name mapping as recommended above?

One option is to map the domain name from the web root into a subdirectory using an .htaccess file in the web root. Hosting companies usually have some snippets of .htaccess directives in their help pages specially for such needs. This is in addition to the pretty url's .htaccess that lives in the site root of each concrete5 site within the web root. Its possible, but multiple levels of .htaccess soon get messy and confusing and, to be honest, I have yet to get all the kinks out of paths within a site using the .htaccess method.

A better option is to have a second domain name. A second domain name can then be set to point to a subdirectory of the web root rather than the web root itself. In practice it is usually best to make this second domain name the primary domain with your hosting company. That keeps the domain name you actually want to use free to point to a subdirectory.

www.myunwanteddomain.com  -> /web-root/index.html
www.mysite.com  -> /web-root/cms1/my-site-files-and-folders...

The second domain name can be anything you want because you will never actually use it. Its just there to satisfy your hosting company that you have a domain name for the web root. For safety and security, you can set the .htaccess in your web root to redirect to your real domain name or just put an index.html in the web-root with a link to your site in it.

Multiple sites

Running multiple sites or primary domains within a single hosting account or on a single development server is just a simple progression of the same technique, adding an intermediate folder for each site / primary domain.

www.mysite.com  -> /web-root/mysite/cms1/my-site-files-and-folders...
www.test.mysite.com  -> /web-root/mysite/cms2/copy-of-my-site...

www.anothersite.com  -> /web-root/anothersite/cms1/another-site-files-and-folders...
www.test.anothersite.com  -> /web-root/anothersite/cms2/copy-of-another-site...

Read more How-tos by JohntheFish.

More about Moving a Site.