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.
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.
The down side of not having a traditional day job? I miss people cursing at me for being right. Thank you, Dan.
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.