WordPress, suExec, and internal server errors

(This post is mainly to document an annoying problem I encountered, and is undeniably geeky…)

While upgrading my WordPress installation from 3.0.1 to 3.0.2, I encountered what appeared to be a rather odd problem.  The automatic upgrade seemed to complete, but then trying to access any of the Dashboard/admin pages just resulted in an “Internal Server Error” page.  Examining the Apache error log file to try to get more information showed that Apache was getting a “Premature end of script headers” error when loading any page, but nothing more that that appeared in the log.

Cue much Googling and posting on the WordPress forums in search of a solution, with various things tried, including removing the .htaccess files, downloading a fresh copy of WordPress and reinstalling (none of which made the slightest bit of difference) I realised the cause of the problem:  My hosting provider use Apache’s suExec function, and for suExec to work, PHP has to be run as a CGI script (not via mod-php.)  And for CGI to work, the PHP files have to have the executable permission bit set (i.e. chmod a+x filename.php.)  But when the WordPress automatic updater runs, it overwrites the updated files and in the process resets the permissions and, crucially, unsets the executable bit.  Which means the PHP files can’t be run as CGI scripts, and so we get the Internal Server Errors, with “Premature end of script headers” in the log file.  In the end, the fix was to reset the permissions on the PHP files to make the executable again.

Short version: If you’re using WordPress with PHP running as suExec’ed CGI scripts (rather than via mod-php), after upgrading WordPress you may encounter Internal Server Errors until you reset the permissions on the PHP files to makes them executable.  If you have shell access to your web server then the following commands, run in the directory where WordPress resides, will do the trick:

find . -name "*.php" -exec chmod 755 '{}' \;
chmod 600 wp-config.php

(This may be overkill – includes shouldn’t need to be executable (I think) – but it does the job.)

Update (16 May): It’s been pointed out to me (thanks Dougie) that running the above command as I originally posted it will result in the wp-config.php file being readable by anyone with access to the server you’re running on e.g. other users in a shared hosting setup.  This is a Bad Thing™, since it potentially exposes details such as your database password to others.  The second command I’ve added above will restrict access to wp-config.php to your own user account.  (Some hosting setups may need the config file to be group-readable, in which case replace the 600 with 640.)