After seeing that many were having trouble understanding how they could use a single core Concrete5 installation to run multiple sites, I thought I would write this post to provide a strawman to help facilitate the discussion of how this can be done.
I run a server in the cloud using Amazon’s EC2 service and utilise an Ubuntu server with the usual LAMP setup.
Core Installation Preparation
To start, I have my core Concrete5 installation files in my default web site folder:
/var/www/default/concrete5.4.0.5 I keep the version number as this allows for the many different sites to use different cores if you wish. How this is achieved will become clear later on in the post.
This basic setup of copying files is covered on the concrete5 site here so I’m not going to repeat that here but it is important to say just copy the files for now.
N.B. Don’t go to the installed location in a browser yet – just copy the files.
Set up the domain that you want to host
This means that you can set up a separate virtual host in Apache or however which way you’d like to. A search (http://bag.gs/heaC2L) will surely find you some assistance here.
The end result will be a virtual host that corresponds to your domain (e.g. www.exampledomain.com) and a separate directory from which that site is served on your server. In my case, this directory is:
/var/www/example.com N.B. I’m assuming that you’ve purchased your domain and have all the right DNS entries set to point to your server.
Set up site specific structure
This step is reasonably simple. We are going to copy the entire contents of the core installation folder (concrete5.4.0.5 in my case) over to the new site directory so that we have the following:
/var/www/example.com/blocks /var/www/example.com/concrete /var/www/example.com/config ... /var/www/example.com/updates This copies what are in the most part empty directories and the inner concrete. The root index.php is important as well as the couple of files in the config directory so make sure you take those across.
As concrete5 is well designed, the guys who have created the product have nicely permitted the extension of almost everything through utilising the directory hierarchy. This means that as site developers, we should never touch the content of the internal concrete directory. In the above case, the /var/www/example.com/concrete directory. Consider it sacred!
If we obey this principle of not messing with anything in the core concrete folder, which helps us all upgrade, then you would notice that there is no value in that the …/example.com/concrete folder being a copy of the …/default/concrete5.4.0.5/concrete folder and you’d be correct.
Therefore, we are going to delete the /var/www/example.com/concrete directory and replace it with a symbolic link. It is the symbolic link that allows us to point to different cores for different sites.
The syntax for the symbolic link when in the /var/www/example.com directory is:
...:/var/www/example.com$ ln -s ../default/concrete5.4.0.5/concrete concrete
Your Done!
Seriously, that’s all. You can then pick up the basic setup (http://bag.gs/hEWOT9) at the point where you navigate to the new site, enter the site name, URL, and Database settings and away you go.
This small amount of preparation allows you to scale a single core instance of Concrete5 through using separate databases.
It would be great to get people’s views on this as I’m sure there are areas to improve or things that I’ve not considered. Therefore, please leave a comment with your feedback.