Multisiting
Smereka is well armed to support multiple sites, but it requires to take some decisions on system configuration and then apply them.
Multisiting is the system, which operates with several [virtual] hosts and they are all serviced by one instance of a Smereka basic code.
Consider some configuration options.
One site – one directory – one database
This system is the simplest to configure. For each new virtual host one should create a personal root web documents folder, then copy the Smereka installation files into it, create a new database, make initial database records and change database connection parameters in customsettings.php file.
The advantage of this configuration is complete independence of one site from other sites. This can be very significant when the one need to provide global administrator rights to site owner (those rights have per-database scope).
Disadvantages of this configuration – the complexity of support: 1) update Smereka code often involves metainformation update in the database, so the upgrade should be done for each database in the system, 2), personal Smereka installation directory is about 1 Mb, and these files should be copied to every site personal directory (by the way, these sets of files can also occasionally updated) 3), personal directories and databases is particularly valuable resources, which number is limited by the hosting conditions.
Multiple sites – multiple directories – one database
With this configuration, all sites of this group using one database and, consequently, global administrators have equal access to them.
The advantage of this configuration is one instance of metainformation and possibility to administer multiple sites using one global administrator account.
The disadvantages of this configuration is the duplication of personal directories, which was discussed above.
Multiple sites – one directory – one database
With this configuration, all sites of this group using one database and a one personal directory, achieving maximum savings of valuable resources. Also eliminates duplication of standard sets of files in multiple personal directories.
The disadvantage of this configuration is that one must manually modify customsettings.phpfile, that acquires features virtual host descriptions in Apache. An example of such modifications might look like this:
switch ($_SERVER['HTTP_HOST']) { case 'example.com': case 'www.example.com': $HostName = 'example.com'; $Languages = array ('uk', 'ru', 'en'); $PostProcessing = 'custom / postproc.php'; break; case 'shop.biz': case 'www.shop.biz': $HostName = 'shop.biz'; $Languages = array ('en'); $PostProcessing =''; break; / * other sites as need… * / }
In this example provides multisiting for example.com and shop.biz sites. They have different sets of languages and different settings of post-processing. Of course, the list of these personal settings can be expanded.
Certain shortcomings of such a configuration is the need to discipline in the files catalog in a personal directory of sites. File name conflicts may occur in the standard Smereka directories (such as files/css).
The disadvantage is the possibility of each site of the family use (in its HTML source code) to any file, including the "alien" – is automatically derived from the use of a common document root of the site.