Sharing a single WordPress codebase for multiple multisite installations

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”

Saving MySQL access credentials for your Linux User

To keep entering your access credentials everytime you need to connect to your MySQL database, you can store them on your user folder. Just create a .my.cnf file such as:

[client]
 user=your_username_here
 password=your_user_password_here
 socket=/var/run/mysqld/mysqld.sock

You can chmod 0600 that file to keep other users from reading it.

Clonar un repositorio de Git a un directorio no vacío

Cuando estás clonando un repositorio de git, sólo tienes la posibilidad de hacerlo creando un nuevo directorio o bien hacerlo en un directorio vacía; sin embargo, en maś de una ocasión es posible que debas re-utilizar un directorio ya existente en el servidor pero que no puedes renombrar, sino solamente cambiar sus contenidos.

Una solución un poco artesanal, pero que funciona, es la siguiente:

https://gist.github.com/felipelavinz/8804767

… Y cuando estés absolutamente seguro de que no necesitarás ningún archivo de las copias de respaldo puedes borrarlas y listo.