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 `` 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 mv web/wp/files .``
Once the upgrade is complete, the folder can be moved back to its
normal location:
``sudo -u mv files web/wp/``
For all sites, the upgrade process itself can be performed by
running:
``sudo -u 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 `_.