apache_mod_loaded fails due to ob_get_clean behavior on some servers

[hamfastgamgee]

On some servers, including Wordpress installs hosted by Green Geeks (PHP 5.2.9: see ​http://www.greengeeks.com/phpinfo.php), apache_mod_loaded will actually fail in such a way that pages will cease to render, which affects both the Permalinks page and the Media uploader if running on a Mac. (There are possibly other side effects that I am unaware of, but these are the two major side effects I've seen.)

The problem appears to be localized around the use of ob_get_clean in the definition of apache_mod_loaded in the branch that has to parse phpinfo. Replacing ob_get_clean with ob_get_contents and ob_end_clean fixes the problem entirely on the site I'm currently working on. I realize ob_get_clean is supposed to be equivalent to ob_get_contents + ob_end_clean, but in this case at least, it seems to be significant. I don't know why this is the case, but since it seems to be fixed and I have seen a number of support forum topics regarding the Media upload form with a Mac that suggested just commenting out the code that uses apache_mod_loaded to test for Mac + mod_security, I strongly suggest making this minor edit for the good of all users.

[hamfastgamgee]

(I would add a Diff with the exact fix to wp-includes/functions.php, but given the number of steps involved to successfully create a patch according to the documentation, I don't have the time to do that right now. Hopefully my description above is enough to quickly identify where I'm referring to.)

[demetris]

@hamfastgamgee:

If you have some familiarity with Subversion, and once you have found some solution that works, making and submitting a patch is only four straightforward steps: :-)

1. Check out trunk with a Subversion client from ​http://core.svn.wordpress.org/trunk
2. Hack the file with a text editor
3. Create a patch with the Subversion client
4. Upload the patch here with a web browser

[nacin]

We use ob_get_clean() in more than a half-dozen places in core. So I'm willing to guess it isn't that. That also tells me that we wouldn't make this change without sound reasoning and a way to reproduce the issue, otherwise we may just end up using ob_get_clean() back again at a later time.

The PHP 5.2.10 release announcement lists a memory leak in ob_get_clean() as a fix. I don't have 5.2.9 to test on at the moment, but I can try to get it fired up, maybe that is the issue (but doubtful). Can you test ob_get_clean() on a regular PHP file on that server and see what is up?

[hamfastgamgee]

Replying to nacin:

We use ob_get_clean() in more than a half-dozen places in core. So I'm willing to guess it isn't that. That also tells me that we wouldn't make this change without sound reasoning and a way to reproduce the issue, otherwise we may just end up using ob_get_clean() back again at a later time.

The PHP 5.2.10 release announcement lists a memory leak in ob_get_clean() as a fix. I don't have 5.2.9 to test on at the moment, but I can try to get it fired up, maybe that is the issue (but doubtful). Can you test ob_get_clean() on a regular PHP file on that server and see what is up?

Well, the WP System Health plugin actually says I'm running on 5.2.14, despite what Green Geeks phpinfo says, so maybe their hosted sites get a newer version of PHP than their main site uses? :) That would seem to rule out 5.2.9 as a direct problem.

Anyway, yes, I would definitely agree with the assessment that since ob_get_clean is used elsewhere for areas that are not failing that something else is likely going on, or maybe there's a circumstance to the phpinfo parsing that causes this to fail in this particular code. However, I know for a fact that using ob_get_contents and ob_end_clean instead of ob_get_clean in this one location does in fact solve the problem, even though those statements are, according to PHP, supposed to be more or less identical.

Here are some support forum links for exactly the same problem as I am describing:
​http://wordpress.org/support/topic/permalink-settings-page-is-blank-wp-292
​http://wordpress.org/support/topic/blank-media-window-mac-upload ​http://wordpress.org/support/topic/permalinks-settings-page-is-blank
​http://wordpress.org/support/topic/mac-osx-amp-php-532-uploading-images

Some of those pages suggested that 5.2.13 was fine and 5.3.2 was broken. No idea what kind of bearing that has on 5.2.14.

I'm not much of a PHP hacker (I'm a professional software developer but not experienced in PHP), so I'm not sure how to proceed to actually debug the real failure. (A friend of mine who is a PHP hacker for his day job hypothesized that multiple headers were getting sent and somehow this caused ob_get_clean to not properly close the output buffer.) I just know I fixed it on my server by the change indicated, but I don't want to hand the site over to the non-technical maintainers without some hope that future upgrades to Wordpress will just re-break their site. :)

[nacin]

PHP 5.3.2 -> #15237

[nacin]

Cross-referencing #15038.

[hamfastgamgee]

phpinfo for the site in question, copied/pasted from an output plugin

[markjaquith]

I realize ob_get_clean is supposed to be equivalent to ob_get_contents + ob_end_clean, but in this case at least, it seems to be significant.

I looked at the PHP source code... They are functionally equivalent.

[hamfastgamgee]

Replying to markjaquith:

I realize ob_get_clean is supposed to be equivalent to ob_get_contents + ob_end_clean, but in this case at least, it seems to be significant.

I looked at the PHP source code... They are functionally equivalent.

I have no doubt of that. I can only believe what I saw with my own eyes, which was that switching from ob_get_clean to ob_get_contents + ob_end_clean in that one spot in the source code fixed the problem. I haven't the foggiest idea how, mind you. :)

[hamfastgamgee]

Okay, interesting. I just upgraded that site to 3.1.1 tonight (from 3.0.1), and now the Permalinks page and the Media Uploader (when used on a Mac) work fine. I have no idea if maybe GreenGeeks changed something that fixed this on their end, although the PHP information returned from WP System Health still says 5.2.14. I did not check to see if the pages still worked before running the upgrade (we passed this site off to the client 6 months ago), but they seem to work fine now. I have no explanation for what happened, because clearly the ob_get_clean call returned with the upgrade.

I'm not sure whether an underlying problem is fixed in Wordpress magically or if there was something in PHP that was OS-implementation specific and maybe GreenGeeks upgraded their OS.

So I guess this is "fixed" for me, but I don't know if it's fixed for everyone else with a similar problem like in the cross-referenced notes.