WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 3 years ago

#15044 closed defect (bug) (worksforme)

apache_mod_loaded fails due to ob_get_clean behavior on some servers

Reported by: hamfastgamgee Owned by:
Milestone: Priority: normal
Severity: major Version: 3.0.1
Component: General Keywords:
Focuses: Cc:

Description

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.

Attachments (1)

phpinfo output.txt (23.7 KB) - added by hamfastgamgee 3 years ago.
phpinfo for the site in question, copied/pasted from an output plugin

Download all attachments as: .zip

Change History (11)

comment:1 hamfastgamgee4 years ago

(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.)

comment:2 demetris4 years ago

@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

comment:3 follow-up: nacin4 years ago

  • Keywords reporter-feedback added

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?

comment:4 in reply to: ↑ 3 hamfastgamgee4 years ago

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. :)

comment:5 nacin3 years ago

PHP 5.3.2 -> #15237

comment:6 nacin3 years ago

Cross-referencing #15038.

hamfastgamgee3 years ago

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

comment:7 follow-up: markjaquith3 years ago

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.

comment:8 in reply to: ↑ 7 hamfastgamgee3 years ago

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. :)

comment:9 hamfastgamgee3 years ago

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.

comment:10 SergeyBiryukov3 years ago

  • Keywords reporter-feedback removed
  • Milestone Awaiting Review deleted
  • Resolution set to worksforme
  • Status changed from new to closed
Note: See TracTickets for help on using tickets.