A variant to using Kirby for multiple sites
An alternative approach for running multiple sites from the same Kirby installation.
In this recipe a scenario for running multiple sites via the same Kirby setup has been presented. The proposed setup makes use of the fact that you need only one
/kirby folder where the heart of Kirby is beating. However, it is also based on the assumption that you have only one virtual (or even real) webserver host from where your various sites will be served. The
index.php at the root of your installation in this scenario works like a dispatcher and therefore needs some modification.
Even though the proposed setup is easy to accomplish, some might dislike the fact of running multiple websites from one webserver host - amongst others. Instead, one might prefer one virtual host per site, which has the advantage that - from a webservers perspective - you have clearly seperated installations and configurations for each site. Moreover it provides the ability to extend the capabilities of single hosts while narrowing down others, depending on your needs. Last not least you can enable or disable single hosts without affecting the others.
Hence, here is an alternative approach of a multisite Kirby installation, which provides several additional advantages.
The following setup was tested on Linux OS (Ubuntu 18.04 and Debian 9) together with Apache HTTP Server 2.4.
The proposed filesystem layout in the above mentioned recipe looks like this:
Looking at it from a higher directory level, it could be seen as follows…
…where the webserver's virtual or real host's document root points to
docroot, which could be anywhere in your filesystem.
Let's change that to a setup in which every website is served by a dedicated webserver host. The filesystem would then look like this:
Fellow Kirby administrators will notice nothing new besides two Kirby installations side-by-side.
However, we can move the
/kirby folder to a location outside of all document roots and replace it with a symbolic link which points to the moved
The symbolic links are created like this:
user@host:/srv/www/my-site.com $ ln -s /srv/www/kirby kirby user@host:/srv/www/my-shop.com $ ln -s /srv/www/kirby kirby
PHP can follow the symlinked
/kirby directory like any other. However, since the root to
kirby/config/roots.php is set up like this…
…we need to slightly modify the
index.php in all of our document roots:
That's it! Now all our Kirby sites will be served from a common
So far, the new solution provides nothing new compared to the old solution, despite the fact that we are running a webserver host for every Kirby site with all the advantages mentioned above.
What's more, we can now switch between different versions of Kirby with a few keystrokes.
Let's suppose that we want to run
my-site.com with Kirby 3.3.1, but
my-shop.com with Kirby 3.3.2. All we need to do is put the
/kirby folder of every version into a folder of its own, and point the
/kirby symlinks to the respective folder:
These symbolic links are created like this:
user@host:/srv/www/my-site.com $ ln -s /srv/www/kirby-3.3.1 kirby user@host:/srv/www/my-shop.com $ ln -s /srv/www/kirby-3.3.2 kirby
Now, when we want to upgrade
my-site.com from Kirby 3.3.1 to Kirby 3.3.2, all we need to do is to change the symlink in
my-site.com - actually without even stopping and starting the webserver:
user@host:/srv/www/my-site.com $ rm kirby user@host:/srv/www/my-site.com $ ln -s /srv/www/kirby-3.3.2 kirby
And we are done!
Want to switch
my-site.com back to Kirby 3.3.1? You know how easy this is by your own now.
Of course, like explained in this recipe, you need a license for each of your sites.
This cookbook recipe was written by Uwe Gehring.