WordPress errors on Apache 2.4.26 with PHP-FPM

I was recently surprised to discover that I could no longer manage my posts (invalid post type) or modify any of my installed plugins (sorry, you are not allowed to access this page). I’ve been exposed to these kind of problems before, both through database corruption and by my own hand so to speak. However, this time around everything checked out so I enabled debugging to track down the error.

The only issue reported was this innocent looking notice:

PHP Notice: Undefined offset: 1 in vars.php on line 34

The following code in /wp-includes/vars.php will determine the current page in WordPress.

wp-includes/vars.php

The preg_match pattern expects to get a relative path from the $_SERVER[‘PHP_SELF’] variable, but on Apache/2.4.26 with PHP-FPM it does not. Subsequently, there won’t be a match and $_pagenow gets stuck with index.php since $self_matches[1] is empty.

What does $_SERVER[‘PHP_SELF’] return for the following url: https://blog.paranoidpenguin.net/wp-admin/edit.php

  • Apache/2.4.25 with PHP-FPM will return /wp-admin/edit.php
  • Apache/2.4.26 with PHP-FPM will return /edit.php (whoops!)

My temporary fix has been to add the following code to vars.php to reintroduce the expected behavior.

$_SERVER['PHP_SELF'] = preg_replace('/(\?.*)?$/', '', $_SERVER['REQUEST_URI']);

Interestingly enough this bug only affects Apache with PHP-FPM. The PHP Apache module will return the expected value forPHP_SELF. Tested on Arch Linux and Slackware ARM 14.2.

Click this link to watch a video of the issue as experienced on my Arch workstation.

Update:
In the last few days I’ve gotten a couple of messages informing me that the new Apache directive ProxyFCGIBackendType can be applied to rectify this issue. Setting the backend type to “GENERIC” will reintroduce the old functionality. Thanks!

Update 2:
The issue has been resolved upstream with Apache/2.4.27.

Related