Make WordPress Core

Updates from Mark Jaquith Toggle Comment Threads | Keyboard Shortcuts

  • Mark Jaquith 7:42 pm on January 7, 2013 Permalink
    Tags: ,   

    WordPress 3.6: Autosave and Post Locking 

    I want, as a major 3.6 bullet point, that we should never lose posts due to expired cookies, loss of connection, inadvertent navigation (even if AYS’d), plugin or core errors on save, browser crashes, OS crashes, cats walking on keyboards, children drooling in keyboards, etc. I want people to trust WordPress with their posts. They should never fear that something they’ve spent time creating or editing should go away due to their mistake or ours or that of a third party. Mistakes and errors should be recoverable. I can’t stress enough how important it is that people believe this and have good reason to believe it. If a post gets lost, there is a catastrophic loss of trust, that could take years to be regained (if indeed it ever is). This is people’s time and their creative output we’re talking about. If we’re not valuing those things above all else, then our priorities are seriously out of order. This is an all-hands-on-deck item for 3.6. Even if you’re not actively working on the code or the copy or the UI or the UX I want you to be thinking about ways in which WordPress could better treat your creative output as the valuable artifact it is.

    Things this will likely involve:

    • Local storage of post data while editing, in-between autosaves and manual saves.
    • More frequent “heartbeat” pings to the server (allowing data to hitch a ride at certain intervals, and also allowing us to quickly deliver messages back from the server about events).
    • Real and more granular post locking. Right now we just have a wimpy notice that isn’t a good deterrent against people simultaneously editing a post and overwriting each other’s changes.
    • Probably some interaction with the team working on improving Post Revisions.
    • UX work for making recovery from failure scenarios smooth, clear, and worry-free.

    @aaroncampbell and I have chosen @azaozz to lead this, as it will probably be very JavaScript-heavy. There are a lot of moving parts here, so please leave a comment if you’re interested in this important, heroic, virtuous endeavor. :-)

     

    • Mike Schinkel 7:43 pm on January 7, 2013 Permalink | Log in to Reply

      +1!

    • Jon Brown 7:46 pm on January 7, 2013 Permalink | Log in to Reply

      +1 – May I suggest that versioning and autosaving of metadata be included in this push. I’ve seen several people become reliant on the revisions and auto-save of the content (yay, they trust it!) and then be disappointed to discover their excerpt or content in a metabox isn’t given the same treatment.

      • Mark Jaquith 7:55 pm on January 7, 2013 Permalink | Log in to Reply

        There’s at least one ticket that touches on that http://core.trac.wordpress.org/ticket/20299

        But yeah, we need to start thinking about the fact that as more people use WP as a CMS, a lot of their important data resides outside of post_content.

        • Travis Northcutt 8:01 pm on January 7, 2013 Permalink | Log in to Reply

          Absolutely this. We make heavy use of post meta in sites we build for people, and storing revisions would be a huge plus. Does anyone know of additional tickets that address this? (The one Mark linked to is specifically focused on the fact that previewing changes to a post updates meta (silently), which isn’t expected behavior).

    • Pippin (mordauk) 7:55 pm on January 7, 2013 Permalink | Log in to Reply

      Huge +1.

    • goldenapples 7:58 pm on January 7, 2013 Permalink | Log in to Reply

      +1, I’m very interested in helping work on these features. I’ve worked with the authors on the site I manage to find workarounds for a number of related problems and have several ideas I’d like to test out:

      • visualizing revision history as a tree rather than just a list (I look at vim’s :Gundo plugin as a rough UI example)
      • post meta as mentioned above, although that needs a LOT of thought (lots of postmeta is never shown in a meta box, or is not meant to be edited by authors…)
      • doing more to enable inter-user messaging along with the “heartbeat” autosave calls. Its possible to do something with websockets for the maybe 2% of sites that have that enabled, but for most people, the regular admin-ajax calls could be used to pass messages back and forth about what other users are viewing, if one user requests a release of the lock, etc.

    • adamsilverstein 9:07 pm on January 7, 2013 Permalink | Log in to Reply

      i’m interested in helping if i can

    • John Saddington 9:19 pm on January 7, 2013 Permalink | Log in to Reply

      omg. yes.

    • Arnan de Gans 9:22 pm on January 7, 2013 Permalink | Log in to Reply

      And on top of that… While you guys are at it, make the dashboard, the whole of it, faster. Better loading, faster rendering (?) Whatever. Often on sites that have a bunch of plugins active it get’s really sluggish.

      • Aaron D. Campbell 10:13 pm on January 7, 2013 Permalink | Log in to Reply

        This is largely dependent on what they plugins you’re talking about do on the dashboard. Sounds like they’re likely doing something wrong if they’re slowing down the dashboard that much.

      • Aaron Brazell 12:04 am on January 9, 2013 Permalink | Log in to Reply

        Or nuke it altogether. I don’t have numbers but I’m guessing the majority of people spend 1% of their time in the Dashboard. I find it altogether useless, although I’m sure some would disagree with me.

        When I login to WP to produce content, the first thing I do is click on Add New in the posts menu. That’s a hover and a click more than I need to get into content production.

    • John Kleinschmidt 9:46 pm on January 7, 2013 Permalink | Log in to Reply

      I have been doing a decent amount of work around offline storage recently and would love to help contribute on the JS side of things.

    • Md Mahmudur Rahman 10:10 pm on January 7, 2013 Permalink | Log in to Reply

      Excellent.

    • Grant Norwood 11:59 pm on January 7, 2013 Permalink | Log in to Reply

      Thanks, Mark. This is a great goal, and worthy of the urgency you’ve expressed! Since you mentioned post revisions, I’d like to recommend that we think about how to better compare post/page/CPT revisions within the rich text editor. As it is currently implemented, non-technical users have difficulty comparing large amounts of plain-text and raw HTML, and often give up immediately when using the compare feature. Developers are accustomed to the unified diff format, but we’re the only ones.

      Could we take inspiration from the review/editing/comparison tools used in other popular copy-editing apps (i.e., MS Word) that would make a copywriter feel more at home when comparing content revisions?

    • Gabriel Koen 9:18 pm on January 9, 2013 Permalink | Log in to Reply

      I’d like to lend a hand with this, I can provide user insight (our dev team has been fielding issues regarding this topic for a few years from a large staff of writers) as well as do PHP and JS coding for it.

    • Mike Bijon 12:49 am on January 13, 2013 Permalink | Log in to Reply

      I’d like to help with this during this cycle too.

      Since I’m time-limited to being effective on only 1-2 tickets per cycle, I be happy to help with tests and testing if time there would be valuable.

  • Mark Jaquith 2:04 am on January 2, 2013 Permalink
    Tags: , ,   

    WordPress 3.6 Planning Session 

    I hope everyone enjoyed the holidays! We’re back to our regularly scheduled IRC meetings tomorrow, and are going to start by scoping and planning out the 3.6 cycle. Wednesday, Jan 2, 21:00 UTC. Please make every effort to attend! The theme I’m proposing for 3.6 is “Content Editing”, so especially start thinking about editing, editorial workflows, revisions, autosave, DFW, etc. Also be thinking about what you’d like to work on and how much time you can commit this cycle.

     

    • John Saddington 2:45 am on January 2, 2013 Permalink | Log in to Reply

      booya. this will be awesome. can’t wait to see what 3.6 brings in terms of content editing, especially for editors of blog and blog networks. bingo.

    • Japh 2:49 am on January 2, 2013 Permalink | Log in to Reply

      I plan to be there, Mark! Looking to be an excellent release. I like the proposed theme. Depending what it ends up looking like, I imagine features for this version will be very relevant for me.

    • nofearinc 8:49 am on January 2, 2013 Permalink | Log in to Reply

      this seems way more handy than the gallery functionality as it covers every single user and would lead to performance and UX improvement. Very exciting.

    • Sara Rosso 9:25 am on January 2, 2013 Permalink | Log in to Reply

      Exciting. I’m going to follow along closely on this one! :)

    • Ron Rennick 2:38 pm on January 2, 2013 Permalink | Log in to Reply

      I hope to attend but will miss the first of the meetup. After discussing the multisite roadmap at WPCS I went through most of the multisite tickets. For 3.6 I think it would be good if we went through and cleaned up some of the small enhancements and UX inconsistencies. I’ll have a few hours a week throughout most of the 3.6 cycle to work on those items.

    • David Tufts 3:53 pm on January 2, 2013 Permalink | Log in to Reply

      As far as the custom fields and custom meta boxes go, I would like to see extendable form elements in WordPress similar to the extendable widgets. There should be a base form element class that all other form elements can extend, allowing for all form elements in the custom meta boxes to be generated using built in WordPress elements like, date picker, color picker, editor, etc. This would include input validation and all the sql validation as well. I have added something similar to this in the KickPress plugin that is in the plugin repository. (http://plugins.svn.wordpress.org/kickpress/trunk/kickpress-form-elements.php)

    • mojowill 8:54 am on January 3, 2013 Permalink | Log in to Reply

      Interested to see where this goes!

    • AqoonKaal 3:37 am on January 5, 2013 Permalink | Log in to Reply

      Thanks Mark for your dedication. When you say “Content Editing” does that include looking into the_excerpt lenght . For example if the_excerpt could accept two variables, say the_excerpt ($length, $more) so that you can assign different lenght for different categories like so: the_excerpt (“50″, “more”), or the_excerpt (“25″ “read more”), etc. That may help CMS part of WP (like E-commerce, Newpaper themes etc).

  • Mark Jaquith 9:02 pm on December 19, 2012 Permalink
    Tags:   

    WordPress 3.6 Cycle 

    I’m going to be leading the WordPress 3.6 cycle. I’d personally like the focus of the release to be about content editing (revisions, autosave, workflow, editing modes, etc), but of couse that won’t be locked down until we have our IRC planning meeting in early January.

    What I need in the meantime is to pick a backup lead. Someone who will help me with the planning, execution, and delivery of the release, as well as be able to step in if for some reason I am unable to finish. If you think you’d be a good person for that job:

    Apply to be the WordPress 3.6 Backup Lead

     

    • Marko Heijnen 9:09 pm on December 19, 2012 Permalink

      I’m curious if there would also be a focus on bringing the open tickets down. Even this release there where more tickets opened then closed.

      • Andrew Nacin 9:11 pm on December 19, 2012 Permalink

        Yes. This is going to be a separate initiative from the release itself. More in a few weeks.

    • Nashwan Doaqan 8:04 pm on December 20, 2012 Permalink

      Good , Sure thing we should add more features to WordPress , I have some ideas and I will open some tickets soon , anyway I hope WordPress 3.6 be another success version :)

    • Tom Lynch 10:56 pm on December 20, 2012 Permalink

      @markjaquith is there not room to look at the Settings API which I and others have highlighted several times and keeps being passed over?

    • Erlend Sogge Heggen 2:58 am on December 21, 2012 Permalink

      Would this update to “content editing” include a re-evaluation of TinyMCE and its alternatives? (such as wysihtml5, Aloha Editor and CKEditor)

      Some relevant discussions:
      http://wpmu.org/why-you-hate-the-wordpress-text-editor/
      http://wpmu.org/what-i-would-do-to-improve-wordpress/
      http://wordpress.org/extend/ideas/topic/improved-visual-editor

      • Mark Jaquith 8:23 am on December 21, 2012 Permalink

        I’d like to make it easier to support other editors, for sure. As for looking at alternatives — we do that constantly. But we’re also trying to work more closely with the TinyMCE team. A switch would have high costs, and it would have to be worth it. It behooves us to try as hard as we can to improve TinyMCE first.

        • Vitor Carvalho 9:38 pm on December 22, 2012 Permalink

          Easier support for other editors would be nice, but is it actually achievable? I mean, there are a lot of new JS editors with different configurations…
          I like TinyMCE, in fact neither I nor my clients have anything to say about it.

        • Erlend Sogge Heggen 12:22 am on December 29, 2012 Permalink

          Very understandable, thanks for replying.

    • Mark Jaquith 7:52 am on December 21, 2012 Permalink

      There’s one improvement that I’d like to make, that’s pretty simple: built-in callbacks for some basic input types. Even just handling text input, checkbox, and textarea would cut down a lot on the slog. Happy to listen to other suggestions.

      • Vitor Carvalho 9:30 pm on December 22, 2012 Permalink

        It would be nice to have a WP_Form_UI class with some methods to handle form elements and merging it with Settings API for easier creation of pages and subpages in the admin. For example, one could create a page just extending a WP_Admin_Page class, as we already do with WP_List_table.

        • wycks 10:02 pm on December 30, 2012 Permalink

          This would be a massive benefit to developers and WordPress itself. Right now custom field wrappers are one of the most popular items on github for WordPress, making a more uniform API that covers those more constantly and integrates with internals would be very nice.

    • Ronald Huereca 12:55 pm on December 21, 2012 Permalink

      @markjaquith, would per-thumbnail editing (as defined in the theme add_image_size) ever be part of core? Right now it appears plugin territory (e.g., http://wordpress.org/extend/plugins/crop-thumbnails/), but would be nice if this were built into the new 3.5 image edit area.

      • Marko Heijnen 7:50 pm on December 27, 2012 Permalink

        I think for 3.6 this still would be plugin territory. There are some other things to address first to get to a per-thumbnail editing mode.

  • Mark Jaquith 9:32 pm on August 1, 2012 Permalink
    Tags: HiDPI,   

    How to Develop for HiDPI (“Retina”) without a Retina MacBook Pro

     

  • Mark Jaquith 3:31 am on July 11, 2012 Permalink
    Tags:   

    Recognition, and news about the 3.5 cycle 

    Before we kick off 3.5 development tomorrow with the scope session, there are a few quick announcements!

    Andrew Nacin’s prolific contributions, encyclopedic knowledge of the codebase, and his increasing development leadership have undoubtedly been known to you all. We’re now recognizing that leadership by promoting Nacin to a Lead Developer!

    Daryl Koopersmith has had temporary commit for the past few release cycles, and should be known to you for his work on nifty features such as the theme customizer, distraction-free writing, and our fast-fast-fast linking dialog. We want him to keep bringing it for many releases to come, so we’re dropping the “temporary” bit and letting him keep ongoing commit access.

    Next, Jon Cave (“duck_”) is having his temporary commit extended once again for the 3.5 cycle. Jon’s keen eye has been quite helpful, especially when it comes to improving WordPress security.

    Finally, we’re trying something a little bit different for the 3.5 cycle. We’re going to have a specific release leader — someone who has both primary authority and primary responsibility for the release. They’ll lead the scope discussion, they’ll coördinate the development process, they’ll crack the whip when people aren’t delivering on things they promised, and they’ll make the hard decisions about whether features stick or get punted. If this works, we can make this a rotating gig.

    For the 3.5 cycle, Andrew Nacin will take the lead, and Daryl Koopersmith will be his second-in-command. These are your point people for this release. I, for one, am excited to see what they (and you) can accomplish!

     

  • Mark Jaquith 1:26 pm on July 5, 2012 Permalink  

    Canonical redirects and IIS 

    Canonical redirects, which were disabled on IIS several releases ago, have ben reënabled for IIS. I’d like any issues with IIS redirects to get worked out in this cycle, and would appreciate thorough testing by everyone with access to various IIS environments. File new tickets for any issues you encounter.

     

  • Mark Jaquith 7:17 pm on February 1, 2012 Permalink
    Tags: ,   

    Team Update: Multisite (Wednesday) 

    I worked some more on the patch we had for #19810. The original patch had features that exceeded our original scope (namely: the ability to bulk-add users). I removed that, cleaned up the JS a bit, and we now have a patch that can probably go in and be iterated.

    http://core.trac.wordpress.org/attachment/ticket/19810/19810.5.patch

    Next up is making it work in the add-user-to-blog interface in the Network Admin.

     

    • Pete Mall 7:19 pm on February 1, 2012 Permalink | Log in to Reply

      I’m working on the patch for the add-user-to-blog screen in the Network Admin. Patch should be up on the ticket in the morning.

  • Mark Jaquith 8:04 pm on December 14, 2011 Permalink
    Tags: Core, ,   

    As the WordPress core team is in the middle of an in-person meetup, we’ll be skipping the IRC dev chat this week. We’ll be collecting our notes throughout each day of the meetup and posting a summary the following day.

     

  • Mark Jaquith 5:40 pm on March 18, 2011 Permalink
    Tags:   

    WordPress 3.2, the plan: faster, lighter 

    Timelines and assignments will be decided next week, but in the meantime, here’s what WordPress 3.2 is looking like:

    • Faster release cycle than 3.1 — more focused release. I’ll be taking point on this release, making sure people stay on target and making sure we don’t try to slip “one more thing” in. Don’t make me get mean. :-)
    • The theme is “faster, lighter.” We’re dropping support for outdated technologies. We’re looking at making things faster, and we’re looking at making the writing experience more lightweight and calming.
    • List Tables API improvements (Westi and Koop) — finalize the API for third party use and more flexibility.
    • List Table XHR loading — to be investigated only after List Table API has stabilized. Make sure it’s worth it before we burn time on it.
    • PHP 5.2 (5.2.4, specifically) to be required. Drop compat. But don’t go adding a bunch of PHP5 stuff. This release is about dropping the old, not adding the new. More red than green.
    • MySQL 5 to be required. This quite literally involves no work beyond changing the requirements. Do not change queries.
    • IE6 EOL for the admin. If BrowseHappy is updated in time, we can consider adding a “use a real browser” nag for IE6 users. We probably can’t drop much CSS, as IE7 shares a lot of the issues. This is mostly symbolic, and reduces the platform combos we need to test. This also means any security issues that are shown to only affect IE6 only can be lowered in priority.
    • Distraction Free Writing. This is our headline “ooh, shiny” user feature. Replace our current fullscreen implementation with something more beautiful, more useful (in terms of line-length and font size), and simpler (only limited RTE functionality). Look at WriteRoom, OmmWriter, http://www.quietwrite.com/ for inspiration. Koop is investigating this, and may crank out a quick plugin to jump-start development efforts
    • Upgrade improvements. Changed-files-only upgrades can be done with zero changes to core. For the first effort, let’s just do updates to the latest point-point from within the same major version. So, 3.2 to 3.2.2 and 3.2.1 to 3.2.2. Optionally consider scanning for changed core files and offering them a full upgrade to overwrite those changed files. Skip the wp-contents directory when upgrading (no more upgrading the default theme or bundled plugins).
    • Speed improvements. There are a bunch of little things we can do to make WordPress load or at least “feel” faster. Nacin is looking at PHP lazy loading. He also is working on a patch to make the admin menu load faster by doing the expansion in PHP. We can make the dashboard faster by not doing async requests for panes if the cache is hot. Dion has some FTP improvements that should make upgrades a lot faster for people using a certain FTP server. Everyone can get involved here. Pick sometime small and manageable that will make WordPress a little faster. Together, they’ll add up to a bullet point in the release post.
     

    • Mo Jangda 5:42 pm on March 18, 2011 Permalink | Log in to Reply

      > Distraction Free Writing

      http://wordpress.org/extend/plugins/zen/

      • Mark Jaquith 5:44 pm on March 18, 2011 Permalink | Log in to Reply

        Yep, we were looking at that too, for some inspiration.

      • vachi 4:35 am on March 19, 2011 Permalink | Log in to Reply

        its pretty cool, but i think they are giving too many options, something like informationarchitects.jp’s writer for the iPad, seems like a more metaphorically appropriate, smashing called it “effective”
        its comes down to being strict and deciding what is truly important for writing

        • Mark Jaquith 4:40 am on March 21, 2011 Permalink | Log in to Reply

          Agreed. And what limited UI there is should be out of mind (even fade away as you type).

        • Babs 6:54 am on March 26, 2011 Permalink | Log in to Reply

          Having downloaded and had a play with Zen – yes it is lovely but can be a distraction in itself, I feel. Agree with vachi that there are too many options. #justsaying

      • jkudish 3:55 pm on March 21, 2011 Permalink | Log in to Reply

        I think this is pretty neat, but should remain as a plugin, why bulkify the admin, when the whole premise of WordPress is it’s expandability via plugins?
        There’s also already a full-screen mode which comes pretty close to this.

      • Aziz Poonawalla 12:53 pm on March 22, 2011 Permalink | Log in to Reply

        Will Quickpress be a focus in 3.2? On the P2 dev forums there was discussion of adopting and extenduing quickpress for use with P2 and any other theme that wanted to use it.

        • Mark Jaquith 3:57 am on March 23, 2011 Permalink | Log in to Reply

          We’ve not discussed that. I’d rather be conservative in 3.2 and get us back on track with on-time, focused releases.

    • Vivek Parmar 6:03 pm on March 18, 2011 Permalink | Log in to Reply

      Waiting for it. WordPress changed my life

    • Babs 6:05 pm on March 18, 2011 Permalink | Log in to Reply

      You are spoiling us! Exciting stuff on its way – thank you all – we are not worthy. Now to go check that everyone has the required levels of PHP and MySQL.

    • Jess Planck 6:18 pm on March 18, 2011 Permalink | Log in to Reply

      Yay! Hopefully this help me put a final nail in the coffin for the one PHP4 server I am co-managing.

      • Joseph Scott 7:24 pm on March 18, 2011 Permalink | Log in to Reply

        You don’t need to wait for WordPress 3.2 to upgrade to PHP5. Releases of WordPress have worked just fine on PHP5 for quite some time.

        • Jess Planck 7:34 pm on March 18, 2011 Permalink | Log in to Reply

          I’m glad you made that comment, it could help others, but you miss understood. It’s not entirely my server, but an emergency server in a remote datacenter that we should have moved to more economical cloud hosting years ago.

    • demetris 6:28 pm on March 18, 2011 Permalink | Log in to Reply

      Is there a reason we don’t go a bit higher than 5.2.4 for PHP? The versions shipping in the most used server distros do allow us to go a bit higher:

      CentOS 5.5: PHP 5.1.6, MySQL 5.0.77
      Debian Etch: PHP 5.2.0, MySQL 5.0.32
      Debian Lenny: PHP 5.2.6, MySQL 5.0.51a
      Debian Squeeze: PHP 5.3.3, MySQL 5.1.49
      Red Hat 4.8: PHP 4.3.9, MySQL 4.1.22
      Red Hat 5.6: PHP 5.1.6, MySQL 5.0.77
      Red Hat 6.0: PHP 5.3.2, MySQL 5.1.47
      Ubuntu 10.04 LTS: PHP 5.3.2, MySQL 5.1.41

      • Mark Jaquith 6:43 pm on March 18, 2011 Permalink | Log in to Reply

        We settled for 5.2.4 based on usage. That’s where the huge PHP 5.x “break” happens. 5.3 is a no-go. It’s also what Drupal and Joomla require.

        • demetris 8:42 pm on March 18, 2011 Permalink | Log in to Reply

          Based on usage makes sense. Thanks for the answer.

        • GaryJ 11:51 am on March 22, 2011 Permalink | Log in to Reply

          Is there not a potential security issue, in that php.net do not support the 5.2 series any more?

          Is it forseeable that while WP 3.2 can move to PHP 5.2.4, WP 3.3 / 3.4 can be moved to PHP 5.3+ ?

        • GaryJ 8:40 am on March 23, 2011 Permalink | Log in to Reply

          Where is that 6% figure from? Some call-home feature from WP installs on update checks?

          If the problem is in fact the hosts themselves using unsupported version of PHP, do Matt’s / Automattic’s recent connections made through JetPack integration not have any influence in persuading the big hosts to bump their distributions up?

        • Rob 9:45 am on March 23, 2011 Permalink | Log in to Reply

          “the hosts themselves using unsupported version of PHP”

          That word “unsupported”. It does not mean what you think it means.

          Developers might follow the ivory tower pronouncements from php.net, but ops (for the most part) really only care about what their distribution vendor is doing. And it’s ops who by definition decide what is and isn’t supported.

          For example, Ubuntu 6.06 LTS is still supported by the vendor and contains both PHP 4.4.2 and PHP 5.1.2.

          RHEL 4 is still supported by the vendor (and will be for another year) and contains PHP 4.3.9 (and no PHP 5 at all).

        • Keith Casey 1:42 pm on March 23, 2011 Permalink | Log in to Reply

          @Rob – What does “supported” mean in this case? Have Canonical or Redhat backported PHP 5.x patches? Have they rolled their own release? Have they picked up core PHP development?

          One of the first rule of Ops is to update your software. PHP 4.x has been formally dead for nearly 3 years. If someone is still running it.. oh well. Odds are they’re still using WordPress 1.x and Windows 95 with IE6.

        • Rob 2:57 pm on March 23, 2011 Permalink | Log in to Reply

          “Have Canonical or Redhat backported PHP 5.x patches?”

          Where security- or stability-related, yes. This is what distributions do.

          “Have they rolled their own release?”

          Yes. This is what distributions do. Feel free to open up a .src.rpm and have a look. The CentOS mirror at http://mirror.centos.org/centos/4/updates/SRPMS/ would be a good start.

          “Have they picked up core PHP development?”

          No. This is not what distributions do.

          “One of the first rule of Ops is to update your software.”

          But not to keep blindly updating to the latest-and-greatest-and-possibly-broken-or-incompatible version. (Particularly for PHP which has a terrible track record of changing a few APIs for no apparent reason with every single patch release.)

          “PHP 4.x has been formally dead for nearly 3 years.”

          Ivory tower pronouncements from php.net are ivory tower pronouncements.

        • Andrew Nacin 5:14 pm on March 23, 2011 Permalink | Log in to Reply

          If there’s anyone to call out php.net for ivory tower pronouncements, it’d be Keith. Make a point about PHP 5.3, sure — but not PHP 4, that’s pretty ridiculous. You’re barking up the wrong tree, I think. :-)

        • GaryJ 8:41 pm on March 23, 2011 Permalink | Log in to Reply

          re RHEL4 / Ubuntu 6.06 – just because a product is supported, doesn’t mean they should continue to use it if newer (including LTS in the case of Ubuntu) versions are available, which, I assume, include newer versions of PHP.

          Clearly it’s a business decision for hosts – organising their clients such that those who want / need to stay on older versions can do, while taking on the cost of updating distributions on servers (or even possibly just PHP itself) and supporting their clients through the transition.

          Without incentives to update, it’s a catch-22 – popular projects won’t update without the usage existing, and hosts won’t feel the need to update for a competitive advantage in being able to host the popular projects that require 5.3, despite it being released 21 months ago.

          My query, was that if WP is powering ~10% of the world’s websites, the WP community (perhaps with the communities from Drupal, Joomla, and non-CMS projects like Zend Framework 2 and Doctrine 2 which already require PHP 5.3) to push the big hosts to make the jump to PHP 5.3, then all the communities would be able to make use of the technologies sooner, than if we sat back and were forced to support whatever legacy versions hosts and distrubution makers decided.

          If 6% is accurate, I agree that requiring 5.3 is ridiculous, but I’d like to see the WP community lead the way in pushing for increased uptake for it by hosts.

        • jkudish 8:44 pm on March 23, 2011 Permalink | Log in to Reply

          I would agree with the following:

          “If 6% is accurate, I agree that requiring 5.3 is ridiculous, but I’d like to see the WP community lead the way in pushing for increased uptake for it by hosts.”

        • Rob 11:34 am on March 24, 2011 Permalink | Log in to Reply

          “Make a point about PHP 5.3, sure — but not PHP 4, that’s pretty ridiculous.”

          Yeah. My point wasn’t so much that PHP 4 is alive and well (it is alive but certainly not very well), but that it isn’t php.net who get to decide what’s dead. If you feel uncomfortable with using PHP 4 as an example, feel free to pretend that I wrote PHP 5.1 (dropped by php.net, but will continue to be supported by RHEL 5 until 2014.)

          “just because a product is supported, doesn’t mean they should continue to use it if newer (including LTS in the case of Ubuntu) versions are available, which, I assume, include newer versions of PHP.”

          On the contrary, if a product is still supported, that is an extremely good reason to continue to use it, regardless of whether an upgrade is available. In large shops, systems are upgraded because it is necessary, not because it is possible. (Note: just because it is possible does not make it necessary.)

          Specifically with regard to PHP, consider how much custom code broke when magic_quotes started to default to off. (It could argued that code was broken, but that would be wrong. If the code always produced correct output for all possible input, then it worked. And the upgrade just broke it.)

          Also remember the PHP developers’ strange fondness for changing a few APIs for no apparent reason with every single patch patch release.

          Sure, these upgrades probably won’t break production code. But they very easily might. And the more custom code you have, the more likely it is that it will break, and the harder and more expensive it becomes and the longer it takes to fix.

          So if the upgrade isn’t actually required, why do it at all? There’s no upside, and a massive possible downside.

      • Keith Casey 7:26 pm on March 18, 2011 Permalink | Log in to Reply

        As of last November, the last of the major distros went to PHP 5.3.x as their base install. That should help adoption but it’s still nowhere close to mainstream. I’m guessing the 5.3 numbers will grow nicely this year and become common next year.

        • Rob 1:22 pm on March 22, 2011 Permalink | Log in to Reply

          “As of last November, the last of the major distros went to PHP 5.3.x as their base install.”

          Except CentOS. And not supporting CentOS would be a bit embarrassing.

      • Ramoonus 11:00 am on March 20, 2011 Permalink | Log in to Reply

        Not all providers always run the latest OS version

    • Erlend 6:30 pm on March 18, 2011 Permalink | Log in to Reply

      Great looking roadmap. I actually wouldn’t mind several more releases like this one to allow the smaller sister projects to catch up.

    • Ferrari 6:33 pm on March 18, 2011 Permalink | Log in to Reply

      It’s very existing to see WP keep working on performance and writing experience.

    • Devin Walker 6:37 pm on March 18, 2011 Permalink | Log in to Reply

      Looking forward to the release!

    • Michael Bastos 6:40 pm on March 18, 2011 Permalink | Log in to Reply

      Any changes planned for multisite? This seems like an off the wall question to ask but will there ever be any plans to add an optional python API stream for those of us running it along side php on our servers and looking to build plugins that take advantage of some of the newer Google API and cloud storage features. This plan looks great…

      • Mark Jaquith 4:37 am on March 21, 2011 Permalink | Log in to Reply

        Multisite enhancements and bugfixes will probably go in. Nothing planned as big as the Python API you mentioned!

        • Michael Bastos 3:02 pm on April 8, 2011 Permalink | Log in to Reply

          Thanks Mark, I’ve been wanting to create a Python Strings plugin that lets me call python function calls from the WordPress SQL DB but I wasn’t sure if this was something you guys already had planned, if I make something useful I’ll shoot it your way but I just wanted to make sure I wasn’t working on something you guys already had on the table.

    • Chip Bennett 7:28 pm on March 18, 2011 Permalink | Log in to Reply

      Activation/Deactivation/Install/Uninstall Hooks for Themes, as per their analogous Plugin hooks? (Pretty pretty please?!? :D )

      • scribu 9:17 pm on March 18, 2011 Permalink | Log in to Reply

        I’m pretty sure this would get in, if there was a patch for it.

        • Chip Bennett 9:20 pm on March 18, 2011 Permalink | Log in to Reply

          I can try; I’m not sure I have the chops for something like this.

        • scribu 9:22 pm on March 18, 2011 Permalink | Log in to Reply

          If you do come up with something, attach it to #14955

        • Chip Bennett 9:27 pm on March 18, 2011 Permalink | Log in to Reply

          Okay then; it’s a project for me, unless someone beats me to the punch!

        • vachi 4:37 am on March 19, 2011 Permalink | Log in to Reply

          i was working on his than dropped, will look for my code and share, thanks for reminding :)

        • Keith Casey 2:21 pm on March 19, 2011 Permalink | Log in to Reply

          @chip – First, start off by writing a short comment describing each and every step. Then don’t worry about the overall code, but just try to implement the individual lines. Even if you can’t do all of it, someone else will be able to follow your intent and more easily give you a hand.

          Or you may find out the little pieces are feasible. ;)

    • necenzurat 7:31 pm on March 18, 2011 Permalink | Log in to Reply

      can someone make JQuery default on Google CDN?

      • Mark Jaquith 4:39 am on March 21, 2011 Permalink | Log in to Reply

        There’s a plugin for that. Not considering it for WP core right now.

      • Chris Jean 9:20 pm on March 21, 2011 Permalink | Log in to Reply

        I’d like to mention that this is not a good idea and people having plugins or themes that do this is also not a good idea. Typically, there are slight issues with specific versions of jQuery. Sometimes these issues need to be worked around with specific changes to the JS code.

        As WordPress does things right now, a plugin or theme dev can look at the WordPress version, know the jQuery version (as long as no one else has changed it), and load the appropriate code to make sure that problems are avoided. If the jQuery version is out of sync with the WordPress version, this can no longer work and increases the likelihood of JS code breaking unexpectedly due to unknown jQuery versions being run.

    • Brian 7:31 pm on March 18, 2011 Permalink | Log in to Reply

      Is an overhaul of media handling in the works for 3.2, or is it going to be pushed a bit?
      http://codex.wordpress.org/GSoC2011.#Media_.280.29

    • Pepe 7:32 pm on March 18, 2011 Permalink | Log in to Reply

      Loving the EOL for IE 6… dieeee!!

    • Francisco 7:33 pm on March 18, 2011 Permalink | Log in to Reply

      What about new 2011 Theme ? Is that going to happend ?

    • Jeroen van Wissen 7:34 pm on March 18, 2011 Permalink | Log in to Reply

      And what about a complete new ‘Media Library’ with file browser and folder tree ;-) ?

    • Joe Flood 7:38 pm on March 18, 2011 Permalink | Log in to Reply

      Distraction-free writing. Can’t wait.

    • deanjrobinson 11:01 pm on March 18, 2011 Permalink | Log in to Reply

      I’m sure there are probably a dozen others out there too, but I added a “distraction free writing” feature to my Fluency Admin plugin that was updated a couple of weeks ago.
      eg. http://www.flickr.com/photos/deanjrobinson/5481489470/

      • Mark Jaquith 4:35 am on March 21, 2011 Permalink | Log in to Reply

        Thanks for sharing! We’re looking at a bunch of things for inspiration. Will play around with the latest Fluency.

    • arena 12:36 am on March 19, 2011 Permalink | Log in to Reply

      • List Tables API improvements : I am sure more improvements can be made if all this classes have the same name. In MailPress, my plugin manages 20 admin screen (lists like posts, taxonomies but also item screen (mail, user)) with 20 different files containing different classes with the same name : MP_AdminPage. This is made possible because there is only one admin screen (so only one MP_AdminPage class) at a time. Think about it !

      • scribu 2:14 pm on March 19, 2011 Permalink | Log in to Reply

        I think having different classes with the same name is a bad idea. Since the classes extend the same base class, you can assign different instances to the same variable and use it without worries.

      • scribu 2:17 pm on March 19, 2011 Permalink | Log in to Reply

        You would just loose flexibility and clarity, without gaining anything.

    • Chuck 1:17 am on March 19, 2011 Permalink | Log in to Reply

      ooh the changed-files-only upgrades would be awesome; wanting that for some time now. scanning would be cool too. Speed = yay, php5x = yay,

    • Luis 1:31 pm on March 19, 2011 Permalink | Log in to Reply

      My only wish is that the default theme is not updated when core is updated, since we have the ability to update themes separately, leave the theme alone and let us update it separately. Other than that, great job. I love WordPress.

    • dartiss 2:30 pm on March 19, 2011 Permalink | Log in to Reply

      I’m excited by this release… it’s good to have a pause every-so-often from throwing new features at a product and concentrate on speed improvements and having a general “housekeep”.

      I’d love there (soon) to be a “small niggles” release too – no big changes, but lots of bug fixes and general tidying up of minor issues.

    • scribu 3:24 pm on March 19, 2011 Permalink | Log in to Reply

      Just in case I don’t make it to the meeting on Wednesday, I would like to continue the work on advanced taxonomy and meta queries, specifically improving the SQL and fixing some API issues.

    • Travis 4:24 pm on March 19, 2011 Permalink | Log in to Reply

      Will dropping re-install of Akismet and Hello Dolly on core upgrade be included in 3.2?

    • Marger 4:47 pm on March 19, 2011 Permalink | Log in to Reply

      More speed is always a good thing. Will database calls and php performance be looked at? My web host tells me lots of database calls and the php system calls cause most of the system load in a shared hosting environment.

      At the moment front side performance seems ok with an optimized theme, but the admin side always feels kinda sluggish, even with different web hosts.

      • Mark Jaquith 4:32 am on March 21, 2011 Permalink | Log in to Reply

        PHP Performance is going to be looked at. We can probably do better at only loading the things that are needed for a specific admin page. And we’ll continue to identify admin screens that could be sped up or need help scaling.

    • Paul Hastings 9:55 pm on March 19, 2011 Permalink | Log in to Reply

      Sounds like awesome news!

    • Maor Barazany 1:06 am on March 20, 2011 Permalink | Log in to Reply

      Will the options API improvement will be part of 3.2?
      http://core.trac.wordpress.org/ticket/14365

      • Mark Jaquith 4:30 am on March 21, 2011 Permalink | Log in to Reply

        I’d be fine with that. Seems like a small enhancement. There will be enhancements and bug fixes not mentioned in this post. This post is about things that could be called features.

    • mjlodge 1:23 am on March 20, 2011 Permalink | Log in to Reply

      I like the focus. WordPress has gotten a bit bloaty over the years and I don’t use many of the newer features for a regular blog, so anything that increases speed and reduces size is welcome.

    • Ramoonus 11:00 am on March 20, 2011 Permalink | Log in to Reply

      This will also make life for plugin developers easier. since there is less PHP hassle to take care of

    • ashish 12:12 pm on March 20, 2011 Permalink | Log in to Reply

      Just wondering if implementing core plugins (like drupal) will help it become lighter…

    • tuxy1 3:19 am on March 21, 2011 Permalink | Log in to Reply

      Give us core plug-ins, finally! For more speed AND less server load!

    • SK 7:22 am on March 21, 2011 Permalink | Log in to Reply

      If you folks are working on the post editor, can you please please please fix the post editor warning screen when multiple users accidentally begin working on the same article. It’s been a bug since 3.0. – http://wordpress.org/support/topic/text-editor-warning-issue-with-wp-30?replies=6

    • Rakesh 12:24 pm on March 21, 2011 Permalink | Log in to Reply

      It was earlier told that removing the /blog slug on the main blog in WPMS would be addressed in a future release. Any plans in 3.2?

      • Andrew Nacin 2:27 am on March 22, 2011 Permalink | Log in to Reply

        Likely no. Nothing major for multisite is planned for 3.2, and global permalink detection would be a pretty big enhancement. (Needs a patch first before consideration.)

    • Frank 2:32 pm on March 21, 2011 Permalink | Log in to Reply

      Also my improvments or wishes?

      Exclude functions (example: revisons) to Core plugins
      Standardize how plugins deal with settings and navigation
      Better localization support, to many memory and use php-standard functions for localization (this reduce the memory with PHP5)
      Page speed optimizaton (filter rewrite rules)
      n to n relationship for attachments
      Make the admin more easily themable
      Move Akismet and Hello Dolly out of the core package; not only from upgrades
      Kill all inline-css-styles

    • Juan [PotterSys] 4:31 pm on March 21, 2011 Permalink | Log in to Reply

      Regarding IE6 EOL, Microsoft is on IE6 Countdown ( http://www.ie6countdown.com/ ). It _could_ be an option to BrowseHappy (it’s from Microsoft; but it cuts out other browsers)

      • Andrew Nacin 2:25 am on March 22, 2011 Permalink | Log in to Reply

        BrowseHappy.com is a WordPress (and Matt) creation, so the goal would be to update that. IE7 isn’t modern either.

      • Aziz Poonawalla 12:56 pm on March 22, 2011 Permalink | Log in to Reply

        China has 34% IE6 usage?!?! does this mean WP 3.2 will become closed to the Chinese internet userbase?

        • Mark Jaquith 3:55 am on March 23, 2011 Permalink | Log in to Reply

          Absolutely not. We’re not blocking IE6, we’re just not investing time in supporting it specifically. They already get a sub-par experience, so that won’t really be a change.

      • Mark Jaquith 4:06 am on March 23, 2011 Permalink | Log in to Reply

        I don’t want to send IE6 users to a site where Microsoft advocates IE8, a old and terrible browser. Yes, I said IE8. Windows XP users can’t run IE9. And even IE9 is about 2 years behind the latest stable versions of Chrome, Safari, Firefox, and Opera.

    • Rakesh 6:07 pm on March 21, 2011 Permalink | Log in to Reply

      “If your existing WordPress installation has been set up for more than a month, due to issues with existing permalinks. (This problem will be fixed in a future version. See Switching between subdomains and subfolders for more information.) ” http://codex.wordpress.org/Create_A_Network

      Is there a plan to take care of this in 3.2?

      • Andrew Nacin 2:24 am on March 22, 2011 Permalink | Log in to Reply

        Probably not — no major plans for changes to multisite in 3.2. This limitation is circumventable, but the point of the limitation is to avoid shooting oneself in the foot, as the main site’s links will break in a subfolder setup.

    • Terry Smith 2:41 am on March 22, 2011 Permalink | Log in to Reply

      Must try to get improved comment loading in as a patch.

    • Steve 7:44 am on March 22, 2011 Permalink | Log in to Reply

      I know this probably isn’t the right place to ask this but the current way Muttisite works (with a set of tables per blog) is horrible. I know that its down to how multisite was created and to avoid major changes in the WP core files but now they’ve been merged are there any plans to move away from a set of tables per blog and towards a blog_id column on a single set of tables? I appreciate that it would mean a large amount of scary work for people with large sites but from a DB point of view it would make more sense.

      • Mark Jaquith 4:01 am on March 23, 2011 Permalink | Log in to Reply

        No plans. Never, would be a safe bet. The sharded nature was by design. WordPress can host anywhere from one site to 18 million sites (WordPress.com). This wouldn’t be possible if not for sharding.

    • hakre 11:05 am on March 22, 2011 Permalink | Log in to Reply

      Oh please fix the memory issue we have, that memory is not configurable because of the 256MB limit in admin: #13847

    • Walter Jeffries 3:05 pm on March 22, 2011 Permalink | Log in to Reply

      I’m less interested in new features (e.g., editor) than in stability, stability, stability and speed of the engine. The improved update is good. Making sure plugins keep functioning is critical. Don’t break things. Every time there is a “drop of support” for PHP older versions, etc I worry because is my web host going to update in time? This slows down the updating cycle.

    • shawn 9:27 pm on March 26, 2011 Permalink | Log in to Reply

      Seriously depressed that once again the media manager is being pushed to the sidelines. It may just be me, but every time we have brought up this topic over the past 2 years, we are told to wait for the next release. In fact during the 3.1 discussion it was made very clear to everyone that 3.2 would focus on media….

      Sad day…

      • Joseph Scott 5:18 pm on March 28, 2011 Permalink | Log in to Reply

        If it something you want to tackle then starting with a plugin that would improve the media experience would be a good way to develop and test new approaches, especially if current core focus is else where.

    • graq 8:13 am on March 28, 2011 Permalink | Log in to Reply

      From the perspective of making things ‘faster and lighter’, it would be really good to have a nicer way of mapping multisite blogs into the blogs.dir directory, so that web servers can easily be configured to cache media files (rather than have to hit PHP every time). Or have I missed a trick?

    • Andrés Sanhueza 4:30 pm on March 30, 2011 Permalink | Log in to Reply

      If you are thinking in a better UI for writing, you can do something that hides or show the only relevant fields when choosing a given “post format”, with an API that can be used for other stuff.

    • Scott Kingsley Clark 6:20 pm on March 30, 2011 Permalink | Log in to Reply

      Will the upgrades improvements roll over to the way plugins / themes are upgraded too, or is this ONLY for when upgrading WP Core?

      • Dion Hulse (dd32) 12:13 am on March 31, 2011 Permalink | Log in to Reply

        In the case of the partial upgrades (Zip archive containing only changed files between versions) for now that’ll be limited to core, It may be offered in future for plugins but Core benefits from it much more as it’s a 3MB zip containing 99% unchanged files (in the case of .1-.2, .2-.3 etc) whereas most plugins will be sub-100K.

        The FTP optimizations will apply to all Upgrader actions (Core upgrades, Core Reinstalls, Theme/Plugin Upgrades & Installs).

        • Scott Kingsley Clark 12:59 am on March 31, 2011 Permalink | Log in to Reply

          Thanks for the clarification. Hopefully in the future offering that feature for plugins or making it hookable so it could be enabled by plugins would be beneficial for larger ones.

    • Jim Lynch 9:54 am on April 11, 2011 Permalink | Log in to Reply

      Distraction free writing? How is WordPress going to keep the kids quiet, the phone from ringing and the dogs from wanting to be walked? Looking forward to the release. Thanks to everyone who works so hard to make things so easy.

    • tux. 3:14 pm on April 16, 2011 Permalink | Log in to Reply

      Still waiting for core plugins.. nag, nag.

    • Andrés Sanhueza 11:45 pm on April 28, 2011 Permalink | Log in to Reply

      Make the API for adding fields to the Quick edit more intuitive. Related: http://core.trac.wordpress.org/ticket/16392

    • Johan 8:12 am on May 19, 2011 Permalink | Log in to Reply

      How do you actually measure “faster”? Is there some kind of benchmark suite or tests that verify this? I’m getting a bit tired of reading “it feels faster” and would prefer seing a profile output from xdebug or something. mutter mutter.

    • Tushar Agarwal 9:13 am on July 5, 2011 Permalink | Log in to Reply

      The new wordpress 3.2 is very improved and feels much faster than earlier. I simply love the new fullscreen mode / zen mode.

    • Thomas 7:55 pm on July 7, 2011 Permalink | Log in to Reply

      Great work on WP 3.2 the speed are UI changes are excellent.

  • Mark Jaquith 9:01 pm on February 8, 2011 Permalink  

    Hotfix 

    We done goofed. One of the security fixes for WordPress 3.0.5 was overzealous. It fixed the issue, but it also stripped advanced HTML (on display, not save, thankfully) from comments by people with the unfiltered_html capability. It’s sort of a rare bug — doesn’t apply to multisite installs, and not many people know that Editors and Administrators on single WP installs can use images etc in comments, so we don’t think it warrants another release. People have WordPress 3.0 fatigue already. And 3.1 is so close I can taste it (takes like pork BBQ, natch). But it is still annoying.

    As Nacin mentioned, a hotfix for this issue went into Akismet 2.5.3. Akismet is very popular, and just happened to be planning an update today. We figured that would be an easy way to fix the issue for some WordPress users today. The Akismet team at Automattic was kind enough to oblige.

    But this wasn’t the first non-critical-but-sort-of-annoying bug in WordPress, and it won’t be the last. So I created a plugin: Hotfix. It fixes the 3.0.5 bug, but I intend for it to fix selected future bugs as well. If we can get this installed on a bunch of sites, it could be a very handy way to push fixes out to people faster than we can with WordPress core releases.

     

    • Alex M. 9:06 pm on February 8, 2011 Permalink | Log in to Reply

      If we can get this installed on a bunch of sites, it could be a very handy way to push fixes out to people faster than we can with WordPress core releases.

      Bundle it and pre-activate it?

      • Ozh 10:27 pm on February 8, 2011 Permalink | Log in to Reply

        I think that would confuse the hell out of average joes. Hotfix vs update?? zomg!!1

    • Travis 9:09 pm on February 8, 2011 Permalink | Log in to Reply

      Bundling it seems reasonable, as long as it won’t be continually reinstalled (i.e. follows the behavior that Hello Dolly and Akismet will exhibit in the somewhat near future).

    • Brian Layman 9:12 pm on February 8, 2011 Permalink | Log in to Reply

      The Akismet avenue is very practical and is a nifty fix, but also it feels rather inappropriate. I’d rather have just seen the plugin made public for those few who need unfiltered html comments before 3.0.6 is released (if ever).

      Well really, me personally, I’d rather see Akismet 3.5.3 bundled with WordPress 3.0.6 because people are still trying to figure out how to update Akismet after these upgrades anyway. But I understand rapid fire updates are unpopular with people.

      • jb510 12:49 am on February 9, 2011 Permalink | Log in to Reply

        I’ve got to agree that it feels inappropriate and I just really hope that bundling fix’s with Akismet or Hello Dolly or whatever… never becomes normal practice. Don’t get me wrong, I love Akismet but like Hello Dolly it, IMHO, it shouldn’t be bundled with core updates.

        I am intrigued by Mark’s hotfix plug-in. It would seem, at least at first look, to make a lot of sense to build into core.

    • Edward Caissie 9:13 pm on February 8, 2011 Permalink | Log in to Reply

      Bundling it may be a solution to getting a “bunch of sites” to make use of the plugin as the average end-user may not be aware of its existence. I would think develoeprs, plugin authors and theme designers may follow the various social media outlets where this is being advertised but the average user tends to be of a “set-it-and-forget-it” mind-set … they are not going to know it’s broke so they are not going to think to fix it.

    • Matthew McGarity 9:19 pm on February 8, 2011 Permalink | Log in to Reply

      This is hot stuff for code n00bs like me — as I learn PHP and WordPress, I can now review future hotfixes as isolated in this plugin, rather than having to dig through core code/patch notes to see what was changed. Thanks for publishing1

    • Andrew Nacin 9:23 pm on February 8, 2011 Permalink | Log in to Reply

      As cool as the plugin is, I’d rather work to strengthen our own update procedures. That’s going to be a huge focus for 3.2.

      Brian, I’m not sure I know what you’re referring to. We decided early this morning that we were not going to go forth with a 3.0.6 release. But Akismet 2.5.3 was being released today anyway, and since it is installed on so many blogs, it is a convenient additional avenue through which a fix can be served. Also, this particular fix isn’t far from the realm of Akismet, seeing it had to do with comments. The Hotfix plugin means we now have a place we can point affected people.

      The Akismet update dance is annoying. We get that, but it’s not something we were going to fix for the 3.0 branch. 3.1 will ship with 2.5.3, and we’ll bump to additional 2.5.x releases as appropriate for 3.1.x. Come 3.2, this won’t be an issue, as one 3.2 goal is to stop updating over the wp-content directory.

      • Brian Layman 5:16 am on February 9, 2011 Permalink | Log in to Reply

        All’s good Nacin. I was just saying I wouldn’t have minded a 3.0.6 the next day if this was deemed an important issue. This obviously wasn’t. Lots of people get bent out of shape with quick releases. Yeah I don’t like bugs creeping in, but relatively painless upgrades are a better alternative than security holes. And this bug was minor and hard to catch. I’d bet through this bug more people will learn what they can do in comments than previously used the features.. But that’s also why I’m not sure it was important enough to fix through Akismet. That’s all I’m saying.

        One thing I would love to see is a consistent way to grab the latest release of any plugin via SVN or the repository. Then I could just request any plugin’s latest.zip or /tag/latest and I wouldn’t have to modify version numbers in scripts.

    • Michael Clark 10:45 pm on February 8, 2011 Permalink | Log in to Reply

      So now we have the equivalent of several versions of WP 3.0.5 out there: WP 3.0.5; WP 3.0.5 Akismet 2.4.0, WP 3.0.5 Akismet 2.5.3; WP 3.0.5, Akismet 2.4.0 HotFix 0.2; Wp 3.0.5 Akismet 2.5.3 HotFix 0.3, and I’m sure a few other combinations. I’m all for a rapid development cycle. But I think the safer (and saner) release strategy would be to push a 3.0.6 out with the new bug fixed. Or can you have Hotfix change the WordPress version number to 3.0.5.1?

      • Mark Jaquith 8:28 pm on February 9, 2011 Permalink | Log in to Reply

        We have an infinite number of versions of 3.0.5 out there, when you factor in all the plugins and the unbounded potential for custom functionality.

        • Michael Clark 3:40 pm on February 10, 2011 Permalink | Log in to Reply

          Granted. But how many plugins exist only to fix a bug, and then will be obsolete at the next WP revision? I feel that having three different official-ish versions of WP 3.0.5 out there is a problem. Is there a goal of having Hotfix version numbers reflect which version of WP they will work on?

          Also, aren’t you WP maintainers going to run into a situation where you have to maintain bugfixes is two places, WP and Hotfix? The Hotfix fix feels klunky.

        • Peter Westwood 3:42 pm on February 10, 2011 Permalink | Log in to Reply

          Also, aren’t you WP maintainers going to run into a situation where you have to maintain bugfixes is two places, WP and Hotfix? The Hotfix fix feels klunky.

          In general they are going to be the same fixes.

          This bug isn’t serious enough to demand a release straight away but for the people that is does affect the easiest solution is the hotfix.

          Simple to Install, No worry about it conflicting when they upgrade WordPress next etc.

    • James Collins 12:35 am on February 9, 2011 Permalink | Log in to Reply

      Just in case anyone missed it, the fix has also been applied to the 3.0 branch: http://core.trac.wordpress.org/changeset/17421/branches/3.0

      So if you’re using SVN to run your 3.0.5 site, svn switching from tags/3.0.5 to branches/3.0 fill also fix the problem.

    • Ryan Hellyer 4:39 am on February 9, 2011 Permalink | Log in to Reply

      The hotfix plugin a weird solution. I like it anyway since it could potentially reduce the number of WordPress updates required. I’m not seeing much point in bundling it into core though, as it isn’t any harder to update the whole of WordPress than it is a plugin. It seems to me that the plugin should be used as a way to point those who are having problems to a simple solution. Then WordPress double point updates could be used solely for security stuff.

    • Jon Brown 7:45 pm on February 10, 2011 Permalink | Log in to Reply

      The more I think about this the more it bugs me. I get just how minor this bug was but I still think it should have been made 3.0.5.1 or 3.0.6.

      #1 most user probably hadn’t updated to 3.0.5 yet. As easy as upgrades have become why make them upgrade, and install a plugin (akismet or hotfix). Why not let them just upgrade and skip a version?

      #2 This in theory is the last release of 3.0.x, and many user won’t be jumping on 3.1 immediately… meaning they’ll be using 3.0.5 for some time again meaning that the final release of 3.0.x should be as rock solid as possible.

      Maybe someone can explain why releasing 3.0.6 the day after 3.0.5 would have been so difficult, but this seems a case of serving the desires of the development community above the broader user community.

      • Mark Jaquith 7:48 pm on February 10, 2011 Permalink | Log in to Reply

        The bug isn not nearly severe enough or common enough to warrant a separate release. That was decided first. The plugin is just a bonus offering for people who are affected by the bug but aren’t comfortable pulling from SVN.

      • Matthew McGarity 8:02 pm on February 10, 2011 Permalink | Log in to Reply

        I suspect that the impact of the issue to the WordPress user base affect going this route — what Hotfix is meant to address are inconveniences to a small pool of users vs. an issue affecting *all* WordPress users (ex: security vulnerability). Based on that, a hotfix feels appropriate, especially considering that performing WordPress upgrades can be a time-consuming effort for end users, especially those with multiple sites to administer.

← Older posts

Newer posts →

c
compose new post
j
next post/next comment
k
previous post/previous comment
r
reply
e
edit
o
show/hide comments
t
go to top
l
go to login
h
show/hide help
shift + esc
cancel