Fixing WordPress Secure Admin and PHP 5.2.1
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.
April 16th, 2007 at 11:23 pm
Hi Adrian,
I’ve recently fixed the issue with PHP 5.2.1 and the download file is now version 02(59).
I’ve written a few comments on the problem here:
http://haris.tv/2007/01/11/wordpress-ssl-plugin-secure-admin-patched-and-working/#comment-2726
PS. I’ve tried to access the php file and text file but am receiving errors on the links above
PPS. I was chuckling when I read …’very much untested and could destroy everything …try it on a friends blog first.’ LOL!
Haris
April 17th, 2007 at 8:57 pm
Hi Haris,
Good to see you’ve fixed it, the links above work for me, so I’m not sure what’s going on at your end - hopefully it’s intermittent, otherwise I can email you the files if you’re interested in them. It’s a very different approach to your original plugin, but I’m finding it extremely useful since it handles URLs generated by plugins as well.
April 17th, 2007 at 9:59 pm
I’ve just realized that I can access the files if I omit the https:// in the links.
Otherwise I get a certificate verification warning (which I temporarily accept) that then throws an error code of -12227?
I’ll take a look at the files, thanks.
Haris
April 18th, 2007 at 7:19 am
Sounds like we've found the first bug. The plugin manager is using HTTPS urls to uploaded files instead of HTTP. The HTTPS server here requires a client SSL certificate which is why you get the -12227 error. I'll have to look into that but I'm not quite sure what can be done about it.
April 18th, 2007 at 8:51 pm
Hope you spot the problem, I’m caught up with other commitments at the mo otherwise I’d have a look myself. Let us know how you get on.
April 19th, 2007 at 5:52 am
Have you thought about submitting these changes back upstream to Ryan’s original code in the repository?
http://wordpress.org/extend/plugins/secure-admin/
April 19th, 2007 at 6:42 am
Anyone is more than welcome to take and use these changes, but the bug will the upload manager using HTTPS may not be fixable with my approach (doesn’t apply to Haris’ approach though). The right way to do all of this is to have a separate setting for the admin URL and use that for things that are being included in the admin page, these plugins are really just clever but nasty hacks around a limitation in WordPress.
April 19th, 2007 at 6:58 am
Well we used the secure-admin plugin for almost a year on WordPress.com and I think we worked out nearly all the bugs, but if you file a patch at http://dev.wp-plugins.org/ I’ll ping Ryan to take it upstream.