Month: February 2014

Ok; the title seems a tongue-twister, but the situation it’s:

• One of our clients, a rather large university, needed to create independent sites for each of its faculties aaaand we love WordPress, so it was clear that we were going to use it as their CMS
• Each of these faculties had to be able to create and manage sites for their pregrad careers, postgrads and research centers, so instead of  separate installations for every site or just one huge multisite setup, we chose to set a multisite network for each of the faculties, where they could add and manage their sub-sites as needed
• The codebase for all the sites it’s the same; they’re all part of the same project and all features are shared. Each faculty has a default theme (which it’s a child theme from a shared parent) and they all use the same plugins
• Every faculty lives on a different subdomain, which we could use as a unique identifier for every site, so all sites had URLs like:
  • http://subdomain.somesite.com
  • http://othersubdomain.somesite.com
  • http://anothersubdomain.somesite.com

At one moment we had separate WordPress installs for each faculty, but sharing a single installation (multi tenancy) has some benefits, such as:

• On the previous setup, we needed to update various directories from an SVN repo; if something went wrong updating one of these (because someone f*cked up the permissions or something like that) we would end up with different versions on the different sites
• Keeping a single set of WordPress files should improve performance for an opcode cache such as APC or the built-in Zend Optimizer in PHP 5.5
• Well… it just makes sense, doesn’t it?

So, how to do it?

First, you’ll need to tweak your wp-config.php file just a little bit. What’s important here it’s:

• Getting the subdomain for the site that the user it’s viewing, which we’ll use as a unique identifier for connecting to the database and configuring the uploads directory
• Set wp-config to use wp-content/sunrise.php, where we can identify the blog (sub-site) that the visitor requested, and map that to the correct uploads directory
• Define the database connection constants used by WordPress for the requested site. Since all of us in the development team had local copies and slightly different setups, we did this on a local config called local-config.php

Of course, this assumes that you need to follow some sort of convention for the names of the databases and the uploads directories, and all canonical URLs for the sites are set to the subdomain that you’ll use as your id.

Both the wp-config.php and wp-content/sunrise.php were included on the project repository, along with a local-config-sample.php that should be used to define everything that was specific to the local enviroment.

The local-config.php that’s included defines:

• DB_NAME, DB_USER, DB_PASSWORD, DB_HOST
• DOMAIN_CURRENT_SITE which it’s needed by WordPress on Multisite setup
• Also, it could be used to define other constants such as WP_DEBUG and related

The wp-content/sunrise.php we used was very similar to the one used by the WordPress MU Domain Mapping plugin, but with one important difference: we needed to define BLOGUPLOADDIR for getting the uploads from the correct site and subsite.


You can check these snippets on GitHub for a working example:

Continue reading “Sharing a single WordPress codebase for multiple multisite installations”