Managing WordPress sites

We currently manage three websites through WordPress:

• the LSE Cities website
• the Urban Governance survey website
• the Executive Masters in City website

These sites are all hosted on the main virtual machine (wp1.nodes.lsecities.net), using the Apache web server and the PHP5 FPM module.

Rather than using the stock WordPress distribution from https://wordpress.org, we use Bedrock, which allows to manage WordPress sites easily, securely and reliably via Composer and wp-cli.

Until September 2015 we used to manage all our WordPress sites via a plain WordPress package configured as a WordPress network. The only real benefit was that we could share the same user accounts across sites, but maintenance and security were way more complicated than they could be, and the risk of breaking one or more sites at the same time in case of problems when updating the whole network made this setup not suitable for our setup.

Upgrading WordPress

With Bedrock, upgrades are not applied automatically nor can be done via the WordPress web UI: instead, the composer.json file in each project’s root folder needs to be updated.

Both WordPress core (johnpbloch/wordpress), themes, plugins and translations are listed as Composer dependencies. Latest versions of Composer packages for any of these dependencies can be checked on https://wpackagist.org/.

Once the composer.json file has been updated, we are ready to perform the actual upgrade.

As each Bedrock project/WordPress site uses a different system user, all the upgrade commands need to be executed as the appropriate user, e.g. by using sudo -u <user> for each of the following commands.

All the commands need to be run from the project’s root folder (i.e. where the .env file is located).

Important: due to the specific way in which the files uploads folder was managed when the lsecities.net website was part of the legacy WordPress network, in combination with the W3 Total Cache plugin and our use of a CDN for uploaded files, the location of the uploads folder is not compatible with the directory layout expected by Bedrock. When performing any upgrade (via composer update) on lsecities.net, it is imperative to first move the web/wp/files folder outside of the web folder; leaving the folder there will either break the upgrade or (if the upgrade commands are accidentally run as a wrong user) delete the whole uploads folder (Bedrock expects to be able to delete the whole web/wp folder and replace it with the contents of the WordPress version being installed).

In practice, when upgrading lsecities.net it is necessary to first move the uploads folder, for example to the project’s root folder:

sudo -u <user> mv web/wp/files .

Once the upgrade is complete, the folder can be moved back to its normal location:

sudo -u <user> mv files web/wp/

For all sites, the upgrade process itself can be performed by running:

sudo -u <user> composer update

Enabling uploads of larger files

As we occasionally need to upload large files to the WordPress media library, the configured maximum file size is fairly large; if this needs to be changed, this can be done via the

• php_admin_value[upload_max_filesize]
• php_admin_value[post_max_size]

settings in the /etc/php/7.0/fpm/pool.d/www.conf file.

Enabling uploads of specific file types

Any file type that is allowed into WordPress Media Library needs to be explicitly whitelisted - WordPress will otherwise refuse the upload for security reasons.

To add file types beyond those enabled by default in WordPress, these need to be whitelisted in a plugin (or theme, if applicable) via the upload_mimes filter.