Whitehouse.gov Chooses WordPress, Again

WordPress is definitely the Jenkins of the CMS world. Easy for a desktop user to set up, absolutely trash for literally every best practice, but nobody's made anything better [for free] yet.

If you are trying to deploy WordPress today with DevOps best practices (version control/12 factor app/etc): set it up with Bedrock (https://roots.io/bedrock/), manage dependencies with Composer, and use environment variables for the runtime configuration. Then use Phinx (https://phinx.org/) to do database migrations. A custom db migration script will be needed to change database settings based on the environment you're deploying to.

Containerization is pretty annoying, because apparently php-fpm will not serve non-PHP content (without creating security concerns). So you need a web server to serve all the static content that comes with Wordpress/Plugins/etc, and php-fpm to serve the PHP. This means you have to either 1) duplicate the static content between two different containers, 2) duplicate the static content into some other storage medium (S3?) and serve it using some web server, or 3) create a frankenstein's monster container of both php-fpm and a web server, and pick your poison on how to make that suck as little as possible.

I have opted for #3 as operationally it's the simplest. You build one container with all the dependencies, static content, and sql migrations, and deployments therefore become just a single container with a single port (http/https) and passing in the env vars. I'll probably upload it somewhere if somebody wants it. It's a docker-compose configuration, plus the Frankentainer, and some scripts, and it all fits into a Bedrock install. I haven't hooked migrations up to it yet, but once that's done, it will actually not suck very much to maintain a WordPress install.

There is nothing wrong with Wordpress and the LAMP stack. It’s fine for many great use cases. It powers, and will continue to power many of the biggest sites in the world.

Static sites are a tradeoff, and you’re often dealing with other messes especially with non-technical users.

Evaluating WordPress without its plugin ecosystem is like evaluating Linux or github or node.js without its developer ecosystem. Of course the bare platform will be worth a lot less without the social networking effect and the diverse applications it supports.

I think if WP ever finds a way to do two things:

- continuously serialize WP to static files

- Make it easier to work with Wordpress as a CRM (No Code or at the very least don't force developers to touch PHP)

JAM stack would near instantly cease to make any business sense (though developers would still love using it of course).

A lot of the issues with Wordpress are sort of long-tail -- combinations of plugins exposing leaks in the abstractions, etc.

BTW, if anyone is working on solving this, I'd love to know about it.

So much this. It's been a bit over five years since I had to run it, but this is what I remember.

If you run multiple webservers, upgrading is extra fun, because when you upgrade, it assumes it can update the mysql schema (which is pretty much totally insane; a www-user writable php script shouldn't be able to create/remove/alter tables). The best way I found was to make a copy of the database, install the new version of Wordpress pointing at the new DB, thoroughly test, and then deploy new version pointing to new DB; then kill the old DB.

And woe is you if your webservers are geographically distant, because there's no way to send reads to a nearby DB mirror; and there's no way to run in read-only, because pingbacks still write to the DB even when they're disabled.

One of the best weeks of my last job was when I was able to finally convince my boss to replace Wordpress for our static company blog with a series of Makefiles and simple PHP to smoosh in all the translations.