WordPress versus FreeBSD

I recently migrated my web site to a new FreeBSD install, configured so I could use ZFS boot environments. This upgrade crossed FreeBSD versions (10.0->10.1), filesystems (UFS -> ZFS), and PHP versions (5.5 -> 5.6).

And my WordPress pointy-clicky upgrades stopped working. Every time I ran an upgrade, the web gui hung with:

Updating Plugin Honketyblatt (1/1)

The web site would site there, forever. Enabling WP debugging gave me no error messages.

If I had the job of running WordPress sites, I would have an automatic tool that processed the upgrades for me. It’s not, so I don’t.

I use the FreeBSD WordPress package to get all of the dependencies, but manage my actual WordPress sites in a separate directory. It turns out that the FreeBSD WordPress package doesn’t list all of the modules that you need for a self-maintaining WordPress install. My old server had a few packages that the new one didn’t.

If you want to use WordPress’ self-updating features, be sure to install the following packages in addition to the FreeBSD-recommended defaults.

php56-tokenizer
php56-zlib
php56-zip

I installed these packages, and everything started working.

Stalk me on social media

5 Replies to “WordPress versus FreeBSD”

  1. DAMN YOU LUCUS!

    It’s because of you that I have now enabled updates. All I did was chown -R www:wheel of the directory, added in zlib and zip (I already had tokenizer), and restarted Apache.

    This will save me much time, given I have four WordPress installations…

    Thank you.

  2. My day job is developing WordPress themes & plugins, and while the auto-upgrade feature was developed with the best of intentions, it’s not something I recommend that clients keep on. Instead, it’s wiser to check that the version upgrade works on a local development machine before upgrading the production site, as past auto upgrades have broken sites (https://wordpress.org/support/topic/automatic-update-to-382-broke-my-site).

    This is more of a problem with the themes & plugins you have installed already, than a problem with the core WordPress install.

    The 4.2 release of WordPress also has with it a poorly documented MySQL version requirement, as it uses a character encoding type that MySQL only supports as of 5.5: utf8mb4.

Comments are closed.