server admin

How to fix: upgrading Apache to 2.4 / PHP 7 breaks WordPress

WordPress had a critical update recently, and I got tonnes of emails (one from each blog I run) demanding I upgrade NOW. So I did, and upgraded Apache to latest while I was at it.

Oh dear. All sites offline. First:

Unable to connect

…then, when I fixed Apache, I got:

“Your PHP installation appears to be missing the MySQL extension which is required by WordPress.”

What happened, and how do I fix it?

Apache 2.4 upgrade is a bit dodgy in Debian

The Powers That Be decided to mess around with core parts of the config files. The right thing to do would have been to add some interactive part in the upgrade script that said: “By the way, I’ve made all your websites broken and inaccessible, because they need to be in a new subfolder. Shall I move them for you?”

Here’s the reason and the quick-fix too

Apache 2.4 brings in PHP 7.0, replacing PHP 5

PHP 5 is old, very old. Historically, PHP has also been managed in a fairly shoddy manner, very cavalier with regards to upgrades, compatibility, safety, security.

So … the standard way to run PHP is to have a separate folder on your server for each “version” of PHP. Everyone does this; PHP is so crappy that you have little alternative.

But this also means that when Debian “upgrades” to PHP7, there is no warning that the new config file – speciic to PHP7 – has been created and ignores the existing config file

This is wrong in all ways, but it’s forced upon linux user by the crapness of PHP. If PHP weren’t so crap, we’d have a single global PHP config file – /etc/php/config.ini – and maybe small override files per version. But nooooooo – can’t do that! PHP is far too crap.

(did I say PHP is crap yet? Decent language, great for what it was meant for – but the (mis)management over the years is truckloads of #facepalm)

So, instead, you need to copy your PHP5 ini over the top of your PHP 7 ini – or at least “diff” them, find the things that are “off by default” in PHP 7 but must be “on” … e.g. MySQL!

Enable them, e.g. change this:


to this:


…and restart Apache. Suddenly WordPress is back online!

/etc/init.d/apache2 restart