A Programmer's Comparison of CMS: Multi-site

on
In the last segment of this comparison we looked at configuration. We continue in configuration on to multi-site. Multi-site is the use a single installation to power a network or hub of  websites.

A reminder of the points the comparison will cover  while going through the article series. It will be a guide for developer's going from installation to the creation of  "Hello World" extensions  for the top three CMS systems and compare them to the Content Connection Kit.
The points covered will be:


  • Configuration.
  • multi-site
  • template
  • extending
  • database structure and use
  • documenting

In this section of the comparison  I'll have to get some help from around the web.  This is because while the idea of multi-site is simple the information about the different implementations for the big three CMS are too complex for a single blog page. I know this from experience and so I will avoid getting side-tracked with the issue. I will however give some of the basics for comparison. If you find that you need details and you are up for the challenge then read the material provided in the links. This makes for easier reading and referencing.

I have tried to find and provide the actual controlling code blocks for each CMS though there is not much.  Because though I have tried to do this comparison from a programmers perspective the fact is that the software being compared is CMS. This means wandering into the territory of site building using the user interface functions of some.

I leave in the reference and research links for those coming to this from a search engine looking for information on completing a multi-site task.


Pros

The pros for creating a multi-site installation are not many for the typical user. But for a business the important ones are:

  • A single point of  maintenance and security  while giving individual site properties each.
  • The ability to create a network of websites that keep branding but are based on different content or user groups. 

Cons


User management is hard:

  • Logged in users are logged in for all sites
  • User profiles are the same for all sites
  • Access control levels become inflexible
  • MultiSite doesn’t let you let your users install themes and plugins
  • Restricting plugins to certain sites is tough

Distribution of server resources

Server load can be problem for the big three even for single sites of moderate size. Adding in multi-site worsens the problem of traffic:

"The most obvious problem of running a lot of sites on one codebase is that any one of them could face a traffic spike, and negatively impact all the others. If you're looking to serve a large volume of sites, the risk becomes non-trivial that one site's "best day ever" is the other 99's worst."


The development process

There's the problem of one mistake cascading across the sites:

"One syntax error, and all the sites go down."

Content Connection Kit

Decide on the network domain names  for the sites based on your needs. The CCK architecture allows for multiple fully qualified domain names and subdomains. You can even designate sub-installations in directories under the domain

  • example.com
  • newsite.com
  • cck.fhqk.com
  • blogsite.com
  • blogsite.com/subinstallation
  • localhost
Once you Copying  the  configuration  directory with a name of the domain or sub-domain:

_configuration
 cck.fhqk.loc
  config.inc
  index.html
 cck.fhqk.com
  config.inc
  index.html
 universal.fhqk.com
  config.inc
  index.html
 default
  config.inc
  index.html


Copying the database or create a datasource for the domain that matches the connection information in the configuration file. In the corresponding config file give the datasource particulars.

//datasource_default
$settings['connections']['datasource_default']['resource'] = "cck.sqlite";
$settings['connections']['datasource_default']['hostname'] = "C:\\Users\\carl\\PhpstormProjects\\fhqk\\informationtechnology\\cck\\_db\\";
$settings['connections']['datasource_default']['username'] = "cck";
$settings['connections']['datasource_default']['pwd'] = "administrator";
$settings['connections']['datasource_default']['type'] = "sqlite3";
//end datasource_default
 
It's as simple as that. Okay, let's move on and see how the others compare in ease and if they are as understandable.

Wordpress


Once the feature is activated on your website, multiple websites can be created from the same WordPress installation. Essentially, one set of WordPress core files powers many websites. Plugins and themes are also shared, however each website has unique directories for media uploads. The same database is also used for all websites, however separate tables are created for each website.

WordPress Multisites (previously referred to as WordPress Multi-User, WordPress MU, or WPMU) was a fork of WordPress created to allow multiple blogs to exist within one installation but is able to be administered by a centralized maintainer. WordPress MU makes it possible for those with websites to host their own blogging communities, as well as control and moderate all the blogs from a single dashboard. WordPress MS adds eight new data tables for each blog. As of the release of WordPress 3, WordPress MU has merged with WordPress. -- Wikipedia

Bear in mind, however, that sites can only be located at one domain, or on subdomains of your main domain. You cannot use different domain names for network sites. It all has to be located at one domain.


/* Multisite */

define( 'WP_ALLOW_MULTISITE', true );
  • WordPress will add the necessary multisite tables to your WordPress database.
  • You will then be taken to the next part of the installation. In this step, you will be required to add a piece of code to your wp-config.php file and your .htaccess file.

 wp-config file:

define('MULTISITE', true);

define('SUBDOMAIN_INSTALL', false);

define('DOMAIN_CURRENT_SITE', 'mydomain.com');

define('PATH_CURRENT_SITE', '/wordpress/');

define('SITE_ID_CURRENT_SITE', 1);

define('BLOG_ID_CURRENT_SITE', 1);

.htaccess:

RewriteEngine On

RewriteBase /wordpress/

RewriteRule ^index\.php$ - [L]

# add a trailing slash to /wp-admin

RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin$ $1wp-admin/ [R=301,L]

RewriteCond %{REQUEST_FILENAME} -f [OR]

RewriteCond %{REQUEST_FILENAME} -d

RewriteRule ^ - [L]

RewriteRule ^([_0-9a-zA-Z-]+/)?(wp-(content|admin|includes).*) $2 [L]

RewriteRule ^([_0-9a-zA-Z-]+/)?(.*\.php)$ $2 [L]

RewriteRule . index.php [L]

Quick summary of steps


  • 1. Add define( ‘WP_ALLOW_MULTISITE’, true );
    to your wp-config.php file
  • 2 (a). Visit the network setup page
  • 2 (b). Choose either a subdomain or sub directory structure
  • 2 (c). Enter your network name
  • 2 (d). Enter your admin email
  • 3. Update your wp-config.php file with the code provided
  • 4. Update your .htaccess file with the code provided
  • 5. Log back in to your website
http://www.elegantthemes.com/blog/resources/the-complete-guide-to-creating-a-wordpress-multisite-installation

Drupal

To create a new site using a shared Drupal code base you must complete the following steps:
  1. Create a new database for the site (if there is already an existing database you can also use this by defining a prefix in the installation procedure).
  2. Create a new subdirectory of the 'sites' directory with the name of your new site (see below for information on how to name the subdirectory).
  3. Copy the file sites/default/default.settings.php into the subdirectory you created in the previous step. Rename the new file to settings.php. 
  4. Adjust the permissions of the new site directory, and grant write permissions on the configuration file (sites/default/default.settings.php).
  5. Make symbolic links if you are using a subdirectory such as example.com/subdir and not a subdomain such as subd.example.com (see the subdirectory multi-site section below for details).
  6. In a Web browser, navigate to the URL of the new site and continue with the standard Drupal installation procedure (if you get an infinite redirection loop, check if the file install.php exists the document root).

Site-specific modules and themes

Each site configuration can have its own site-specific modules and themes in addition to those installed in the standard 'modules' and 'themes' directories. To use site-specific modules or themes, simply create a 'modules' or 'themes' directory within the site configuration directory. For example, if sub.example.com has a custom theme and a custom module that should not be accessible to other sites, the setup would look like this: 

sites/sub.example.com/settings.php 
sites/sub.example.com/themes/custom_theme 
sites/sub.example.com/modules/custom_module


https://www.drupal.org/documentation/install/multi-site

Joomla!



Although it's a best-practice to give every Website its own domain, Joomla! installation and database there can be special conditions in which a multi-site solution under a single Joomla! install is warranted.


Does not come with the core installation but it can be done.


  • We copy the all the tables, and then we duplicate them in the same database with a different alias, for example, we use jos2_ instead of jos_ as the table alias for the new tables.
    • - We modify a few Joomla settings in the database (in the new created tables) based on the client’s request (for example, changing the title of the website, etc…)
  • We duplicate the configuration file. The new configuration file will be an exact copy of the original configuration.php file but with the small difference that instead of using jos_ as a table prefix it will be using jos2_ as the table prefix. We also modify the $sitename parameter, and optionally the $log_path and the $tmp_path parameters.
  • We get the current website using the $_SERVER['HTTP_HOST'] defined variable.
  • We modify the file /includes/framework.php and /administrator/includes/framework.php to point to the right configuration file based on the current website.
 After completing those tasks then you'll have make the new sites accessible through the browser.

Adding a Redirect

 Joomla!  will need the help of a re-direct system to find the correct url to access the sites in the network. Here are some of the options that can be used.

Option #1: Create an .htaccess (Apache) redirect

Note: Enable SEF URLs in Joomla! First

One option is to use .htaccess (Apache) to redirect inquiries to a given domain to a specific Joomla! page.

Our goal is to redirect any inquries to the Red Candy domain name to a given page on the Joomla! site. In this example, we redirect any inquiries to www.redjohnsoncandy.com to a category-blog page. You would have previously assigned the 'red candy' template to this menu item, to create the illusion of a separate site.

#The following rule works, but it changes which domain name displays.
RewriteCond %{HTTP_HOST} ^(www\.)?redjohnsoncandy\.com$
RewriteRule (.*) http://www.yellowjohnsoncandy.com/index.php?option=com_content&view=category&layout=blog&id=3&Itemid=12 [R=301,L]


Well, that works - but you can see the drawback immediately. Although the user is successfully viewing the Red Candy site, they will still see the Yellow Candy domain name. Unfortunately, if you are using both .htaccess and domain-parking (technically a redirect) - this is necessary in order to avoid creating a LOOP.

Option #2: Create a PHP Header Redirect

This solution has the benefit of keeping the illusion of separate domains/web sites apparent to the visitor. Instead of using .htaccess (Apache) for our redirect, we use one of the templates on the site.

In this example, the base domain is www.redjohnsoncandy.com. You have created a template for that area named Red Template. The trick is to open 'Red Template's' index.php file and add the following AS THE VERY FIRST LINES of the install's primary index.php.


$domain = $_SERVER["HTTP_HOST"];
$uri = $_SERVER["REQUEST_URI"];
$url = $domain . $uri;
 
if (($url == "redjohnsoncandy.com/") ||
   ($url == "www.redjohnsoncandy.com/")) { 
   header("Status: 301 Moved Permanently");
   header("Location: http://www.redjohnsoncandy.com/index.php?option=com_content&view=category&layout=blog&id=3&Itemid=12"); 
}


Here's the benefit: The visitor will now be redirected to the appropriate Red Site page, that has the Red Template assigned to it only in the case where they have arrived at the 'red site' domain name. Otherwise, the conditional PHP rule is ignored, and the Yellow Site loads.


It is important to remember to request also de URI (url that follows the pure domain) so that you can make redirections to the same domain. When the URI is invisible in the url the variable becomes a "/" sign. That is why you have to compare your pure url with a "/" sign at the end. This way you´ll be able to make 301 redirects in the same domain. Otherwise you´ll create an infinite loop in the redirection process.

Option #3: Create a PHP Header Redirect, for multiple domains with specific domain redirects for custom templates

Solution for single webspace, with different domains, one Joomla install and depending on the user landing domain, redirects to a different default page. Paste following PHP code AS THE VERY FIRST THING in the install's primary index.php file. To assign another domain, just copy/past the "if" function and edit it with the values of the other domain in the same fashion. Further to setup the template views, you will have to assign different module item/link alias and setup template views within the Joomla! template manager. The alias setting is needed when you use SEF settings.

$domain = $_SERVER["SERVER_NAME"];
$requri = $_SERVER['REQUEST_URI'];
if (($domain == "www.example.de" && $requri == "/" || 
   $domain == "example.de"))  { 
   header("Status: 301 Moved Permanently");
   header("Location: http://www.example.de/index.php?option=com_content&view=article&id=6"); 
}


The pain  lack of built in support for multisite  is eased by the  number of extensions available.

http://extensions.joomla.org/tags/multiple-sites


https://docs.joomla.org/Multiple_Domains_and_Web_Sites_in_a_single_Joomla!_installation


Judging

I am finding the judging of multi-site with the big three is something made difficult . So picking a best of category is actually picking one that sucks the least. CCK is easiest as it does not  involve code changes and web server configuration. But Drupal and CCK are very close to it in terms of versatility and understandable configuration.  The fact that CCK does not need a .htaccess file is not enough of a difference I think. So I'll call it a draw.




As a side note I  find it interesting though that because of the implementation of multisite early on in the projects life. Drupal has a considerable lead over Joomla! and Wordpress, CCK being the youngest also has ample flexibility in it's architecture. The  strict architecture of Wordpress and the lack of support in Joomla! makes for a painful changeover to multisite.

Comments

  1. AnonymousSeptember 17, 2015 at 11:32 PM

    No love for TYPO3 it is build for Multilanguage-Multisite-Setups. Have a look at typo3.org

    ReplyDelete

Post a Comment