I updated my Debian Testing system via
as one does during the normal course of running a Debian system.
The next time I went to a locally hosted website, I discovered PHP
didn't work. One of my websites gave an error, due to a directive
in .htaccess; another one presented pages that were full of PHP code
interspersed with the HTML of the page. Ick!
In theory, Debian updates aren't supposed to change configuration files without asking first, but in practice, silent and unexpected Apache bustage is fairly common. But for this one, I couldn't find anything in a web search, so maybe this will help.
The problem turned out to be that /etc/apache2/mods-available/ includes four files:
$ ls /etc/apache2/mods-available/*php* /etc/apache2/mods-available/php7.0.conf /etc/apache2/mods-available/php7.0.load /etc/apache2/mods-available/php7.2.conf /etc/apache2/mods-available/php7.2.load
The appropriate files are supposed to be linked from there into /etc/apache2/mods-enabled. Presumably, I previously had a link to ../mods-available/php7.0.* (or perhaps 7.1?); the upgrade to PHP 7.2 must have removed that existing link without replacing it with a link to the new ../mods-available/php7.2.*.
The solution is to restore those links, either with
or with the approved apache2 commands (as root, of course):
# a2enmod php7.2 # systemctl restart apache2
Whew! Easy fix, but it took a while to realize what was broken, and would have been nice if it didn't break in the first place. Why is the link version-specific anyway? Why isn't there a file called /etc/apache2/mods-available/php.* for the latest version? Does PHP really change enough between minor releases to break websites? Doesn't it break a website more to disable PHP entirely than to swap in a newer version of it?
[ 10:31 Mar 01, 2018 More linux | permalink to this entry | comments ]