Fixing WordPress Secure Admin and PHP 5.2.1
By Adrian Sutton
If you’ve recently upgraded to PHP 5.2.1 (which is included in an upgrade to Debian Etch, the new Debian stable distribution), use WordPress, use the secure admin plugin and are now just seeing a blank page when you view your blog, I have a solution.
Quick Fix
For those who don’t care why this is broken and what I’ve done to fix it, you probably just want to download the updated plugin which works on my server, with my very brief testing. If you see any problems let me know, but be warned that it is very much untested and could destroy everything – make sure you have a good backup and try it on a friends blog first. I strongly suggest you wait until Haris takes a look at this and comments on whether it covers all the original functionality or not – I could easily have missed something critical. I’m also not sure if this works on versions of WordPress before 2.1.3.
Technical Details
The root of the problem is that 5.2.1 somehow broke the ob_start(callback) function – it looks as if when the callback function is called, global variables aren’t available. For the secure admin plugin, this means that nearly all the wordpress libraries and functionality aren’t available to the callback function. Lacking those supporting libraries the callback function generates an error, but the error message is lost along with the rest of the content when the function terminates so there’s error messages shown anywhere.
Given that I don’t understand the ob_start functions, what they used to do, what they do now and was driven mad by not having error messages logged – I looked for an alternate solution to the problem that doesn’t use ob_start at all.
It turns out that at least for my blog, if the get_option(‘siteurl’) method returned https URLs instead of http URLs, everything would point to HTTPS and I wouldn’t get any warnings about part of the content being unencrypted. As best I can tell, that’s all the ob_start stuff did, though it appears to be more selective about which URLs it filters (which I should note, means it doesn’t cover plugins like my EditLive! plugin which the new version does). You can conditionally filter the siteurl value using the standard filter hooks for options and if the current request for the page used HTTPS, convert to using HTTPS, otherwise pass it through unchanged. There may be other options that need to be filtered, but siteurl is all that I’ve found so far.
Since I haven’t added a check for whether or not we’re actually on an admin page, the filter may actually “fix” the URLs for the actual blog itself if it can be accessed over either HTTP or HTTPS. I’m not sure about that though, because my current server setup doesn’t serve the entire blog over HTTPS.
For those that want to see the exact changes, you can grab the patch against the latest version (0.2 (24)) of secure admin from Haris.tv.
I’d love to hear any and all feedback, particularly if I’ve missed something.