Weeknotes 72

Happy Mother’s Day! Or is that Mothering Sunday?
To celebrate, we made pizzas in our brand new Ooni Karu 12 pizza oven.

I used Ooni’s cold-proof pizza dough and pizza sauce recipe for our first bake after watching multiple videos reassuringly narrated with a lilting Scottish accent.

Despite the typical northern English drizzle, I’d say it was a success with even C happily working his way through an individual margherita.
What better way to chase a variety of pizzas fired in a 500 degree Celsius oven than with a slab of traditional Victoria sponge cake?
C’s enthusiasm for cars has reached a fever pitch with him insatiably demanding “more!” toy cars despite completely emptying my collection from when I were a lad.
I released version 1.3.0 of the re2 gem which makes it easier to install on Apple Silicon Macs using Homebrew.

As Homebrew installs re2 into /opt/homebrew on Apple Silicon, I added that to the default locations the gem searches when trying to find the underlying re2 library. Previously, you’d have to specify this yourself at install time, e.g.
```
$ gem install re2 -- --with-re2-dir=/opt/homebrew
```
But now the following should work instead:
```
$ gem install re2
```
I’ve been torn about how best to handle WordPress for a client.

At Altmetric, I had always hoped to migrate our self-hosted WordPress install away to a third party such as WP Engine, WP VIP or Pantheon. That way we could have pushed responsibility for keeping WordPress up, running and secure to someone else but still benefited from version control and continuous deployment across multiple environments.

However, such things do not come cheap unless you’re happy to let go of the continuous deployment side of things when something like WordPress.com seems hard to beat.

How then to balance the risk of hosting your own WordPress (with all its security implications) with trying to make it as cheap to maintain as possible? Especially considering that WordPress is decided non-Twelve-Factor, storing its configuration in files and relying on being able to write to disk (e.g. for both configuration and caching).

Given that one extreme is to use some sort of managed service and simply have access to the WordPress admin panel (e.g. WordPress.com), what is the other? Is it possible to make WordPress Twelve-Factor and not spend all your time fighting it in the process?

I spiked a project which used John P. Bloch’s fork of WordPress (which syncs with upstream every 15 minutes) and WordPress Packagist to install WordPress, a theme and its plugins via Composer, the dependency manager for PHP. There’s a whole project example of this by Andrey Savchenko for reference.

My composer.json looked like the following:
```
{
    "repositories": [
        {
            "type": "composer",
            "url": "https://wpackagist.org",
            "only": [
                "wpackagist-plugin/*",
                "wpackagist-theme/*"
            ]
        }
    ],
    "require": {
        "johnpbloch/wordpress": "^5.7",
        "wpackagist-theme/twentytwentyone": "^1.2",
        "wpackagist-plugin/akismet": "^4.1",
        "wpackagist-plugin/w3-total-cache": "^2.1",
        "wpackagist-plugin/amazon-s3-and-cloudfront": "^2.5"
    },
    "extra": {
        "installer-paths": {
            "public/app/plugins/{$name}/": [
                "type:wordpress-plugin"
            ],
            "public/app/themes/{$name}/": [
                "type:wordpress-theme"
            ]
        },
        "wordpress-install-dir": "public/wp"
    }
}
```
This installs WordPress into public/wp, plugins into public/app/plugins and a theme into public/app/themes. I then have my typical wp-config.php in public, pulling configuration from $_ENV and disabling all automatic updates and file editing/modification by WordPress and its plugins. We use W3 Total Cache to cache using Redis and WP Offload Media Lite to store any uploads in Amazon S3 (or an S3-compatible alternative). The goal here is to make WordPress as stateless as possible without doing anything too out of the ordinary.

That’s all well and good but what about the actual app servers, database and Redis? Well, what about Heroku’s PHP support? By adding the following dependencies to our composer.json, we can tell Heroku which version of PHP we want and exactly which extensions we need for WordPress:
```
"require": {
    "php": "^7.3.0",
    "ext-curl": "*",
    "ext-dom": "*",
    "ext-exif": "*",
    "ext-fileinfo": "*",
    "ext-hash": "*",
    "ext-json": "*",
    "ext-mbstring": "*",
    "ext-mysqli": "*",
    "ext-redis": "*",
    "ext-sodium": "*",
    "ext-openssl": "*",
    "ext-pcre": "*",
    "ext-imagick": "*",
    "ext-xml": "*",
    "ext-zip": "*"
}
```
Our Procfile instructs Apache to serve our application out of public, respecting the default WordPress .htaccess we have there:
```
web: vendor/bin/heroku-php-apache2 public/
```
As Heroku terminate SSL, we have to tell WordPress requests are using HTTPS based on the X-Forwarded-Proto header in wp-config.php, e.g.
```
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false) {
    $_SERVER['HTTPS'] = 'on';
}
```
While Heroku don’t provide their own MySQL, we can lean on Amazon RDS for MariaDB and connect to it from Heroku while using Heroku Redis for caching.

This way, we can benefit from Heroku’s pipelines and even review apps to spin up new WordPress environments and test changes as you would for a Rails or Node.js application.

Missing out on automatic updates is the big problem here but I wonder if leaning on something like GitHub Dependabot solves this as it does for other web applications, e.g. set aside time every Monday to review, test and deploy any updates to WordPress, your themes and any plugins.

I’m still not 100% decided (particularly as my client has a lot of existing content and uploads to migrate) but I’m tempted to try it.