Narrowly Escaping WordPress 3.0.6

WordPress 3.0.5 was released the other day to address a couple of issues dealing with security and untrusted user accounts. While those issues were addressed, it was soon discovered that one of the security fixes for 3.0.5 created another problem of stripping HTML on display from people with the unfiltered_html capability. Instead of fixing that minor problem and releasing 3.0.6 which would have been embarrassing to say the least, a hot fix was applied to the latest version of Akismet which was also due for an upgrade. This solved the problem for at least a few users but not everyone.

Mark Jaquith then created a plug in which contains the hot-fix but also mentioned that the plug in could be used in the future to fix selected bugs as well. If a number of WordPress powered sites would have this plug in installed, it would be a handy way of pushing out fixes.

I’m not quite sure I understand the reasoning behind this. 3.1 is right around the corner and that branch already has the fix applied while those who know how can simply update their sites via SVN through the nightly builds. In the comments, Ozh also raises a good point in that how do you explain the difference between a hot fix versus an update for WordPress? It’s an unnecessary process that I don’t want to go through. There was also the suggestion of perhaps bundling the Hotfix plug in with WordPress like Hello Dolly or Akismet which is a bad idea. There is a strong contingent of people (I’m one of them) working hard to try and de-couple Hello Dolly and Akismet from the core package of WordPress and the last thing we need is yet another bundled plug in with core.

The best recommendation came from Andrew Nacin in the comments of strengthening the update procedures of WordPress. By the way, one tidbit of information to keep in mind throughout all of this is that somewhere around WordPress 3.2, the goal is to stop updating over the wp-content directory which I know will make some people happy.

15 Comments


  1. Most of us :)

    While I like that Akismet is bundled with WordPress, and I totally understand the necessity of bundling a theme, the number of ‘OMG! WordPress core update undid my theme!’ posts makes me bang my head against the wall. A lot. Unbundling them with the updates won’t solve everything, this is true, and may make it a rarer (and thus less understood) problem, but it’s a good call.

    Report


  2. @Ipstenu – I think WordPress definitely needs to ship with a default theme but in reality, no plug-ins need to be bundled with WordPress to have it function well out of the box as in a new install. Thankfully, at some point in the future, I think Akismet will not be bundled with WordPress. As for Hello Dolly, I think it’s going to take pulling more teeth to get that out of the core package despite the plug-in not really causing any technical issues. It’s just an annoyance more than anything.

    Report


  3. The decision to forego a WordPress 3.0.6 came before the idea of hotfixing it via plugins. We’re not letting the solution change how we think about and define releases. Rather, it was very quickly decided that the bug was too much of an edge case. But, the plugin is a convenient way to offer the fix to the few who were affected.

    Report


  4. @Jeffro – Due to WordPress’s lack of built in spam protection, AND given that a ‘sample’ functional plugin is helpful for noobs, I think Akismet should stay in the initial build but NOT updates.

    I was taking bets on why Nacin and Jane were swearing the other morning.

    Report


  5. RE: bundled extensions – isn’t the issue not that Akismet and TwentyTen are bundled with the default download, but rather that they are bundled as part of the core.svn.wordpress.org repository?

    WordPress could come bundled with any number of arbitrary Plugins and/or Themes, and none of them would be over-written upon WordPress core update if none of those Plugins/Themes is part of the core repository.

    Whether bundled with the default download or not, Akismet, Hello Dolly, and TwentyTen (or any future iterations of the default Theme) need to be moved out of core.svn and moved into plugins.svn and/or themes.svn – voila: no more problems with the Akismet update dance, or overwriting modified TwentyTen (though I have little – nay, no – compassion for anyone who modifies TwentyTen directly, instead of using a Child Theme).

    Report


  6. We’re going to avoid updating wp-content on update. The exception is if an update crosses a version that introduced a new default theme, it will be copied over.

    Initially, we’re not unbundling anything. (And keep in mind Akismet is already an external to plugins.svn.)

    The plan will be easy to implement and it’s going to be really effective. No more Akismet dances, and themes won’t get overridden in a core update.

    Report


  7. @Andrew Nacin

    But why even have Akismet bundled in core.svn, even as an external?
    Why not put TwentyTen in themes.svn?
    (I won’t even get into Hello Dolly… :) )

    I’m really trying to understand the thinking. Is there some huge disadvantage to going this route? Does it make it more difficult to package up a default download file (i.e. wordpress.zip)?

    Report


  8. By the way, Jeff: “Narrowly Escaping“? Was that an intended pun, given the nature of the bug being fixed? ;)

    Report


  9. @Chip Bennett – No, I’m not even aware of the specifics regarding the code to fix the bug but did it have to do with character escaping? If it did, it was a hidden pun that I didn’t know about lol.

    Report


  10. I guess Hello Dolly is a plugin for newbies?

    I love akismet, it should stay. I think it should be sucked up into core wordpress. I don’t like the fact that I need a key for it.

    I like 2010, I am not the best with themes but I am practicing with it.

    It helps newbies ( you were all newbies at one time) to learn. I prefer to screw up and learn from mistakes over reading a book or take classes at a community centre/college.

    Report


  11. one of the security fixes for 3.0.5 created another problem of stripping HTML on display from people with the unfiltered_html capability

    It’s much, much more specific than that. It only affects advanced HTML (like image tags, which are normally forbidden) in comments made by Editors or Administrators on single-site WordPress installs. So it makes them behave like multisite installs, which forbid everyone from posting advanced HTML in comments. And it only does it on display, so there is no data corruption.

    Most people don’t even know that Editors and Administrators can post images etc into comments. It’s not a frequently used thing. We decided that although it was frustrating that the bug slipped in, it was not severe enough to warrant another release. The Akismet team was planning a release that day anyway, so we asked them if they’d be willing to incorporate a quick hotfix into the new version. But I also wanted to offer a standalone solution for the minority of installs affected that didn’t require activating Akismet. So, as I’ve done in the past, I created a Hotfix plugin. Except this time, instead of targeting the entire plugin to a specific release, I made it generic, so that it can push other “not worthy of a release by themselves” fixes to people sooner than they’re otherwise get them. It’s opt-in. It doesn’t change our release decisions. It’s just a more attractive solution than “use subversion” for people who are affected by the bug.

    I don’t want to bundle any new plugins with WordPress. Quite the opposite. Plugins have their own update procedures and release schedules and I think that plugins should be omitted from core updates. Maybe even from the package (note: just my opinion, there). We’re going to be discussing that (and many other things related to updates) in the 3.2 cycle.

    Report


  12. I don’t like using Akismet to patch WordPress. Akismet costs money to run, especially for large Network installations. Also, some site do not allow comments and do not need or run Akismet.

    Glad to see the standalone version from Mark Jaquith.

    Report



  13. @Ipstenu – I agree. Imagine all the new WP users that wouldn’t install a spam protection plugin FIRST THING if one were not bundled.

    I’m also agreed that the sample plugin must remain in order to promote future plugin developers.

    On the flipside I haven’t read any articles on why these shouldn’t be included. Going to have a look now…

    Report

Comments are closed.