Just wanted to update you on a few developments with the back-porting of Wordpress 2.5.x security improvements to version 2.3.3.
First, I want to emphasize that I did this largely to show that it was possible, and that Wordpress (Automattic) should consider rolling out such security fixes for older versions as patches rather than forcing "upgrades" to entirely new iterations of Wordpress with many feature changes mixed in with such fixes.
First, I did move the "Retro-fit" to this production blog of mine that is running a customized version of 2.3.3, and things have been going fine, for the most part.
Here is a screen-shot of the "no frills" login screen that is now missing the formatting that changed with 2.5.1 (as mentioned in the prior post). Since I have the user registration turned off, this is a non-issue for me, I can easily deal with not having a "pretty" login screen.
The only other thing that I found to not work was the AJAXed post/page/comment deletion sequence. There must be a part on the JavaScript of the sequence that blocks the "delete" action, returning
"You don't have permission to do that."
OK, no problem. I tracked down the JavaScript function that throws the error in a few admin files that have delete links on their screens,
onclick='return deleteSomething(... );'
but the AJAX code that it calls is too labyrinthine to mess with, so I left it alone. Instead I replaced it with a simple
onClick='return(confirm("Really Delete?"));'
which fixed it, but also turned off the AJAX effect of the red-then-disappearing post/page/comment. In case you’re "married" to that one, this wouldn’t be for you. Personally, I can easily live without it, since the only thing that might get deleted regularly are spammy comments.
The files that needed this change were
/wp-admin/edit.php /wp-admin/edit-post-rows.php /wp-admin/edit-pages.php /wp-admin/edit-comments.php /wp-admin/includes/template.php
Now, again, I want you to keep in mind that I embarked on this adventure mostly to prove a point about the possibility of having targeted security patches for past versions supplied by Wordpress.org (even though I also did get a nice security upgrade for my highly customized 2.3.3 install out of it). Obviously if they were to supply it, it should be safer/more targeted, and a hick-up such as the delete function thing would be avoided as part of the patch.
Whoever their AJAX specialist is could have likely changed just 1 or 2 lines in the AJAX code itself and solved the problem for all files/screens calling it. I simply don’t have enough experience with AJAX or the overall application logic in this case to know what to change to work the improved user authentication security from 2.5.x into it.
Incidentally, I was playing with a 2.5.1 install to collect and make more specific my thoughts on what I feel are things wrong with 2.5.x. More on that in the next post. But what I did find is that 2.5.x abandoned the delete confirmation pop-up entirely in the new admin interface, so that once you click the delete button at the top, if any posts/pages/comments have their checkbox checked, there is no going back!
Not what I consider a safe design. In all likelihood, you can add the above simple "onClick" JavaScript I devised to the button input element, though I haven’t tried it yet. I am simply unsure what their design goals were with this new admin interface. Now we have something against a pop-up preventing a possibly unwanted deletion?
Given that the post list might display well below the fold, it is in theory possible that someone accidentally checks one of these posts along with another desired check, then hits ‘Delete’ with a post that wasn’t even "in sight" now being deleted. Not good.
UPDATE:
I found one more issue that was created by the back-porting, and this one was actually a bit more of a problem: The whole-sale updating of
/wp-includes/functions.php
to the 2.5.x version actually caused the blog’s feed to fail. Took me a few days to figure this out, actually found it while adding a feed button in my categories.php and search.php templates.
The do_feed() call in the funtions.php file in 2.5.x actually calls a whole new function
get_default_feed()
that wasn’t there in 2.3.3 and throws the error. I first tried to update all of the feed[...].php files in /wp-includes, but that just produced more errors. Instead, the solution was to replace the 6 feed related functions
do_feed_...()
in /wp-includes/functions.php with the 2.3.3 versions. Then things were back to normal.
By now you are probably getting the idea that this back-porting business is NOT for the casual user of Wordpress. It should be noted however that I could have been more careful in porting only those exact changes from 2.5 that had to do with the security fixes, rather than replacing whole files and hoping for the best.
As it turned out, it mostly worked out OK, except for the issues addressed above.
And of course, it still proves that it should be easy for Wordpress.org to make the security fixes ONLY available as a small patch file package, a "Service Pack" of sorts to keep the older versions running as far as security.
Notice that this is the option chosen by many Open Source projects such as the venerable Apache server that powers most of the world’s Web servers. They still support version 1.7 with critical security updates, even though they are up to version 2.2 by now.
Why? Because they understand that there can be significant pain associated with a forced upgrades due to security issues, especially for admins that are dealing with a large installed base.
Maybe Wordpress/Automattic could choose to see this as well, and head in this direction. What’s considered reasonable at Apache.org might be worth considering for them too. We don’t necessarily always need the latest "code poetry"… but we do need critical security.
Food for thought.
