Admin tables empty when installed on *nix with Apache 2.x, PHP 5.3 running as CGI with wrapper script

[magdude]

• Wordpress 3.2.1
• Apache 2.2.3
• PHP 5.3.5

When running with suexec through a wrapper script such as set up by Webmin, the PHP_SELF variable is "fixed" by PHP to point to the wrapper instead of the actual script. This in turn kills some of the admin lists (posts are empty) along with problems setting theme (Thematic) options.

To recreate, adjust httpd.conf vhost to:

<VirtualHost *:80>
  SuexecUserGroup "#1111" "#2222"
  ServerName example.com
  DocumentRoot /home/example.com/www
  ErrorLog /home/example.com/logs/error_log
  CustomLog /home/example.com/logs/access_log combined
  ScriptAlias /cgi-bin/ /home/example.com/cgi-bin/
  <Directory /home/example.com/www>
    Options Indexes IncludesNOEXEC FollowSymLinks
    allow from all
    AllowOverride All
    Action application/x-httpd-php5 /cgi-bin/php5.cgi
    AddType application/x-httpd-php5 .php5
    AddType application/x-httpd-php5 .php
  </Directory>
  <Directory /home/example.com/cgi-bin>
    allow from all
  </Directory>
  RemoveHandler .php
  RemoveHandler .php5
</VirtualHost>

Add the following shell script /cgi-bin/php5.cgi

#!/bin/bash
PHPRC=$DOCUMENT_ROOT/../etc/php.ini
export PHPRC
umask 022
SCRIPT_FILENAME=$PATH_TRANSLATED
export SCRIPT_FILENAME
exec /usr/bin/php-cgi

Copy the php.ini file to /home/example.com/etc/

The problem is temporarily solved by setting the following PHP option in php.ini:

cgi.fix_pathinfo = 0

Which tell PHP not to do a path gawk. I think what should be done is Wordpress should not use PHP_SELF or at least prefer using ORIG_PHP_SELF if it exists, possibly resetting PHP_SELF for downstream functions.

I'm not able to recreate this with 3.3-trunk using the configuration you've provided. Can you recreate this with 3.3? If not, can you provide more information about your setup, perhaps screen shots / logs / etc about what's breaking?

No longer require cgi.fix_pathinfo = 1

@magdude, I managed to get my setup to match yours and was able to reproduce this. I've attached 18165.patch​, which has resolved things on my end. Please report back with your test results.

If this is a good fix, we should see if we can speed this up by avoiding regular expressions.

What does SCRIPT_FILENAME, SCRIPT_NAME, and PHP_SELF look like in this setup?

No cgi.fix_pathinfo = 1 and no regex