Ready to get started?Download WordPress

Make WordPress Core

Updates from August, 2010 Toggle Comment Threads | Keyboard Shortcuts

  • Mike Schroder 8:23 am on March 5, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Last Week in WordPress Core 

    Howdy! This is Last Week in WordPress Core for the week of February 24—March 2! Lots of activity for the past week, which is great as we head into our last few days of alpha. Please join us for daily triage at 1900 UTC to help work through the remaining enhancements scheduled for 3.9.

    As a quick note, if you work with our tools in ‘develop’, and are receiving a SELF_SIGNED_CERT_IN_CHAIN error, you can resolve it by running npm config set ca="". For details, check out this npm blog post.

    If you want to skim, each section is roughly ordered by an important and/or interesting factor.


    • Add the ability to drag and drop files directly onto the editor. Upon drop, the media manager will open, and file will begin to upload. [27343] #19845
    • Throttle scrolling of the main window when the editor is active and is being scrolled with the mouse wheel or a trackpad. [27368]. Expect some major tweaks here, though; see #27013.


    • Introduce HTML5 gallery support. When a theme supports HTML5 galleries via add_theme_support( 'html5', 'gallery' ), figure, and figcaption will be used instead of definition list markup. [27302] #26697
    • Add a filter to remove or rename page templates for a theme. This does not yet handle adding page templates. [27297] #13265
    • Move comment-reply.js to the footer. While it can function before the page is loaded, it works by moving the comment form, which is usually toward the bottom of the page. Please report any contraindications on the ticket. [27303] #12641
    • Return 404 when querying author’s posts who is not a member and has no posts on the site. [27290] #20601
    • Make get_adjacent_post() wrap a new WP_Adjacent_Post object that uses WP_Query. [27285] [27286] #26937
    • Add exclude and include arguments to wp_list_authors(). [27274] #9902


    • Multisite: Introduce get_site_by_path() and further rewrite the site detection process for multisite. This makes it so that a sunrise plugin could do much of its work by adding filters, if those are even needed. [27359] #27003
    • Database: Use MySQLi for WordPress development versions, regardless of PHP version, to increase testing footprint. There’s also a constant for testing purposes. [27257] [27278] #21663
    • Plugin API: Introduce doing_filter() and doing_action() to identify hooks in progress. You can also use this with to identify a hook that has completed. For more, see [27294] #14994.
    • Formatting: Strip backslashes, not just forward slashes, from untrailingslashit(). trailingslashit() will now remove any forward or backslashes from the end of a string before appending a forward slash. [27344] #22267
    • Date/Time: Allow current_time() to accept a date format string, adding to timestamp and mysql. [27259] #21653
    • Updates: During core upgrade, copy wp-includes/version.php over last, to avoid an installation failing with the new version.php in place. [27336] #25860
    • Rewrite API: Allow rewrite endpoints to specify a query variable name. [27327] #20905
    • Cache API: Revert [27115] and let cache backends handle the stripping of spaces in cache keys as necessary. microtime() returns greater precision than microtime(true). [27300] #27000, #23448, #26903, #14485
    • Query: Add a $default argument to get_query_var() and WP_Query::get(). Helpful when working with endpoints. [27304] #16471
    • Comment Query: Allow user_id to be an array of IDs in WP_Comment_Query. [27258] #27064
    • Users: Make the user arguments for get_edit_profile_url() and get_dashboard_url() optional, defaulting to the current user. [27260] [27265] #16686

    External Libraries

    • Update the Masonry JavaScript library to version 3. [27271] #25351
      • The new script handle is masonry. The old jquery-masonry handle is the official shiv that sits on top of the v3 library to be backwards compatible with v2 usage. While v3 no longer depends on jQuery, a theme or plugin may have been implicitly loading jQuery though Masonry, rather than additionally declaring it as a dependency for themselves.
      • Themes should switch to masonry and declare jQuery as a dependency on their own if they need it.
      • Upgrade guide on Masonry’s site, with the exception that, for core, we continue to include imagesLoaded.
    • Upgrade Plupload to 2.x (2.1.1) [27316] #25663
    • Update the Root Certificate bundle used for SSL communication by WP_HTTP from the latest Mozilla release NSS. [27307] #27017

    Developer Tools

    • Add grunt-patch-wordpress for applying patches directly from Trac. Mapped to grunt patch, which declares usage. Requires npm install to install. [27299] #27023
    • Add JSHint to Travis CI config. [27267] #26446

    For the complete list of commits to trunk, check out the log on Trac. Interested in joining in? Write or test a patch for 3.9.

    Thanks to @adamsilverstein, @andy, @avryl, @bassgang, @bootsz, @chrisscott, @danielbachhuber, @DrewAPicture, @enej, @ericlewis, @ericmann, @ethitter, @evarlese, @garyc40, @GaryJ, @gcorne, @georgestephanis, @GregLone, @helen, @iamfriendly, @Ipstenu, @jackreichert, @jeremyfelt, @johnjamesjacoby, @jorbin, @knutsp, @kovshenin, @kpdesign, @leewillis77, @markjaquith, @mattheu, @mboynes, @mitchoyoshitaka, @mjbanks, @mordauk, @morganestes, @nacin, @nicolealleyinteractivecom, @obenland, @ocean90, @patricknami, @pento, @pross, @rickalee, @salcode, @scribu, @SergeyBiryukov, @shelob9, @siobhyb, @solarissmoke, @xsonic, @stephcook22, @theorboman, @tivnet, @TobiasBg, @willmot, @wonderboymusic, @xknown, and @yoavf for their help this week!

  • Andrew Nacin 9:01 pm on January 27, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Proposed Trac component reorganization 

    Warning, this long. tl;dr: I propose a reorganization of our Trac components. 34 top-level components with two dozen subcomponents. New tree at the bottom. First, an overview of some of our problems.
    (More …)

    • Helen Hou-Sandi 9:22 pm on January 27, 2014 Permalink | Log in to Reply

      I am particularly excited about how groups and maintainers will (hopefully) form around components and focuses. Anybody can comment on a Trac ticket or pitch an idea or create a potential roadmap, but there’s a real sense of empowerment when you really feel like you’ve got your head and hands wrapped around a specific area, and are perhaps even recognized for doing so.

      I know for me personally it’s been really gratifying to be entrusted to run with a particular area (what we can now define as the UI focus) and has made me feel more comfortable with interacting and pushing core forward. And not just when it comes to UI development and conception, but in other areas as well. I also might just dare hope that we can stop the worst of the ticket rot, with having both more bodies as well as a clearer idea for hopeful contributors as to where to go for more feedback or help.

    • nofearinc 9:23 pm on January 27, 2014 Permalink | Log in to Reply

      I’m curious about the Query branches of Comments and Users – too many tickets for these types of Queries or plans to extend a lot furthermore?

      Great list though, and the “hall of fame” with notes is awesome.

      • Andrew Nacin 9:28 pm on January 27, 2014 Permalink | Log in to Reply

        I don’t think either is necessarily the case. The idea was to create a specific subcomponent under Users that those focused on Query (in general) could also specifically follow. Same for Comments. So in this case, it’s about granularity, not necessarily roadmap or ticket counts. Query is goofy, as I mentioned in the post — it’s a cross-section that would normally be good as a focus, but it actually covers functional areas of core (there just happen to be a lot of areas).

    • StyledThemes 9:24 pm on January 27, 2014 Permalink | Log in to Reply

      Give me a BIG Pot of coffee and I will ready this shortly…however, I saw the part of Bootstrap which caught my eye as I build my themes with it (well, parts of it). But from what I see in the list, looks interesting overall.

      • Andrew Nacin 9:25 pm on January 27, 2014 Permalink | Log in to Reply

        Bootstrap is not Twitter Bootstrap, it’s the “loading” process of WordPress. I may rename this to Bootstrapping if it’s a problem.

        • StyledThemes 9:34 pm on January 27, 2014 Permalink | Log in to Reply

          ah… how about WordStrap :)

        • nofearinc 9:37 pm on January 27, 2014 Permalink | Log in to Reply

          That’s the initial association of many folks btw, even knowing what Bootstrapping is, the recent popularity of the Twitter’s thing is overlapping actively, just my 2¢

        • jack96161 10:26 pm on January 27, 2014 Permalink | Log in to Reply

          Agreed, Twitter commandeered “Bootstrap” for too many in the community these days — greybeards like me know what a real bootstrap is, but renaming it will eliminate more questions like this in the future. I always liked the “Progenitor Process”, we used in an early operating system at HP, but it will probably end up as something like “startup”, “init”, or other bland 2-syllable invention …

          • jack96161 10:34 pm on January 27, 2014 Permalink | Log in to Reply

            Just noticed on the 3.9 Trac pages that “Bootstrap/Load” is used as a component name — I’ll vote for that one and the Twitterites can just deal with it!

    • Aaron Jorbin 9:52 pm on January 27, 2014 Permalink | Log in to Reply

      One additional focus that may make sense is Unit-Tests. The use case I’m thinking of is a patch that just adds unit tests. It would go in the component that it most directly deals with as I think the test tools component is more focused on the tools of testing rather than the actual tests and receive the focus of Unit-Tests (and optionally the JavaScript focus if it is a javascript unit test)

      • Andrew Nacin 10:07 pm on January 27, 2014 Permalink | Log in to Reply

        Ah, yeah, I forgot to mention this. This is also on my list. I’m still trying to figure out how it overlaps with keywords (needs-unit-tests and has-unit-tests), so I saved it for later. Does needs-unit-tests and has-unit-tests simply trigger the unit-tests focus automatically? If a ticket is opened specifically to provide unit tests for something, is that more of a has-patch situation? etc.

        • Aaron Jorbin 11:27 pm on January 27, 2014 Permalink | Log in to Reply

          I think needs-unit-tests and has-unit-tests should trigger the unit tests focus.

          Has-patch makes sense in the just adding unit tests case since it is fixing the reported issue (not having unit tests) while I think needs-unit-tests and has-unit-tests is more workflow oriented.

    • Jon Brown 12:15 am on January 28, 2014 Permalink | Log in to Reply

      This looks great. You’ve done a great job of making the parents obvious (fwiw, I’d keep bootstrap as bootstrap).

      Two things seemed non-obvious to me, and maybe that’s just unfamiliarity on my part, but worth mentioning.
      First – Formatting-Shortcodes/Charset. This seems non-obvious to me but I’m guessing this is processing raw content, essentially wpautop, it’s brethren and associated filters. Formatting sounds more like CSS to me than filtering/processing content.
      Second – There are separate top level categories for HTTP API & XML-RPC. It seems to me this could be a single top level “Remote/External APIs” component with sub-components for HTTP, XML-RPC, JSON, etc… Maybe that’s makes no sense though though since code wise they’re entirely separate.

      Again, great work sifting all this into these components, these are just comments as I read through and understand what’s group where, why and what each component covers.

      • Andrew Nacin 7:01 pm on January 28, 2014 Permalink | Log in to Reply

        Formatting has been called Formatting, well, for as long as I’ve been around. It also centers around formatting.php. It might not be the best name, but yeah, it’s for processing raw content. We’ll make sure the description and search keywords for it are solid.

        For right now, HTTP and XML-RPC have pretty much zero overlap in form or function. We’ll need to revisit everything here anyway when the REST API comes into core. (Gut reaction would be a component for the server, and a focus to handle APIs specific to another component.)

    • Robert Dall 12:30 am on January 28, 2014 Permalink | Log in to Reply

      I am not sure if we want to confuse the themes & bundled theme anymore then they already are. When I gave a talk on trac and I explained why it is called bundled themes a couple light bulbs went off in the crowd. But yet they knew what default themes meant. It’s all semantics, but now that understand why themes and bundled themes are different.

      What I *REALLY* like is having a subcomponent for each theme in development. We could still use use the title to differentiate between Twenty-Thirteen and Twenty-Fourteen as is the current standard but having this and the easy of use sounds whole lot better and easier for query’s of trac etc…

      • Andrew Nacin 1:12 am on January 28, 2014 Permalink | Log in to Reply

        I’ve got no issue renaming Bundled Theme to Default Themes, and we can definitely nest individual components underneath it for each theme. The issue I see would be that if we added subcomponents for each default theme directly under the Themes component, where would a ticket go that affects more than one theme? (This isn’t entirely uncommon.)

        • Sam Sidler 4:19 pm on January 28, 2014 Permalink | Log in to Reply

          In the main Bundled/Default Theme component? I assume the components are still usable even when subcomponents exist.

          • Andrew Nacin 6:47 pm on January 28, 2014 Permalink | Log in to Reply

            Sorry, I should have been more specific. Option 1, which is totally fine;

            Default Themes

            • Twenty Ten
            • Twenty Eleven

            Option 2, which I’d prefer (and which I thought RDall was hinting at):


            • Appearance
            • Widgets
            • Nav Menus
            • Twenty Ten
            • Twenty Eleven

            My point was I’d like to merge “Bundled Theme” (or “Default Themes” or whatever) with “Themes” to make it even less confusing. But then I’m not sure where general default theme tickets (affecting multiple themes) would go — getting dumped in “Themes” means they may get lost.

        • Robert Dall 6:20 pm on January 28, 2014 Permalink | Log in to Reply

          Does it need a subcomponent if it effects all themes? Or are subcomponents required when they exist?

  • Andrew Nacin 2:26 am on July 28, 2013 Permalink
    Tags: post types, ,   

    Potential roadmap for taxonomy meta and post relationships 

    In the days before the WordPress Community Summit in October, a number of contributing developers huddled together to discuss a number of long-term architecture ideas. Among them were taxonomy meta and post relationships. (Ah, I see I now have your attention!) This post is more or less a proposed roadmap. It’s an ambitious plan that is designed to take place over perhaps five or more releases.

    (During WordCamp San Francisco’s keynote, @matt talked a little about a new aim to build teams of contributors and reviewers around individual core components. There will be a lot more on that in the coming days and weeks. For now, here’s a post that covers two components, post types and taxonomy.)

    The discussion included all core committers at the time — @ryan, @markjaquith, @westi, @azaozz, @nacin, @dd32, @koopersmith, and @duck_ — and a number of contributing developers, including @aaroncampbell, @dh-shredder, @helen, and @scribu.

    At the moment, terms are represented in WordPress using two different IDs: a term ID, and a term taxonomy ID. A term ID (and name and slug) can actually appear in multiple taxonomies, so to identify a particular term, you must have either the term ID and the corresponding taxonomy, or just the term taxonomy ID. This dates back to the original taxonomy schema in WordPress 2.3. At the time, the concept of “shared terms” seemed like it could be an important abstraction. Hindsight is 20/20, and shared terms are the bane of taxonomies in WordPress.

    So when we talk about term meta, we’re actually talking about term taxonomy meta – meta associated with a term taxonomy ID, not a term ID. The problem is, the public ID used in the API and elsewhere is the term ID (and, by necessity, a taxonomy is also passed). This confusion — and the need for there to be only one object identifier in our metadata API (term taxonomy ID, not two, as in term ID and taxonomy) — has long forced us to table the discussion of term metadata.

    (There are separate conceptual issues here — at what point does a term with metadata simply become a post-like object that can relate to other posts? And given post relationships, could terms and posts actually converge in their underlying schema? I’m not actually going to answer those questions in this post. Purely talking schema and architecture at this point.)

    At WordCamp San Francisco last year, four of us — me, Gary Pendergast (@pento), @scribu, and @koopersmith — came up with a rather crazy way to make major changes to our table schema while still being backwards compatible. In fact, we came up with two ways to do it. This was the plan everyone heard and discussed at the summit.

    It was clear that shared terms had to go. The first step is removing a UNIQUE index on the slug field in the wp_terms table. (This is dependent on #17689.) Then, we stop creating new shared terms. Step three, on an upgrade routine, we actively look for any existing shared terms and split them.

    These three initial steps must happen over two to three major releases, as we’re talking about a bug fix, a schema change, an API change, and an upgrade routine — in that order.

    Then comes the fun part, in yet another major release. With shared terms split, term ID and term taxonomy ID will be identical  on every install.  If we moved the slug and name fields from wp_terms to wp_term_taxonomy, we could actually drop wp_terms.

    How can we remove an entire table but still be backwards compatible? We came up with two solutions:

    1. Because all fields in wp_terms will exist in wp_term_taxonomy, wp_terms can be recreated as a MySQL view to be a read-only mirror of term data, thus being compatible with all existing queries.
    2. Because all fields in wp_terms will exist in wp_term_taxonomy, and because table aliases like `t`and `tt` are always used when joining these two tables, $wpdb->terms can simply be set to $wpdb->term_taxonomy. A query that previously joined wp_terms with wp_term_taxonomy would just join itself.

    In all: Using the second approach (yes, it works), it took about 20 lines of code to make WordPress run without a wp_terms table. Wow, right?

    So by this point, we would finally have a sane taxonomy schema. Less joins, a cleaner API (probably helped by a new WP_Term object to model WP_Post and WP_User), no more shared terms headaches, and a single, sane ID for a single taxonomy’s term.

    Once that is all finished, we can finally have term meta. Maybe. (Kidding. (Kind of.))

    Where do post relationships come in? The existing Posts 2 Posts plugin by @scribu is fantastic and serves the niche well. But we’re not really comfortable making any architecture or API changes along these lines while our taxonomy schema is still in a far from ideal state.

    The post relationships plugin supports posts to posts, and posts to users. Core taxonomy relationships supports posts to terms, but it can also be rigged to relate users to terms. (It also supported links to terms, yet another object type.) We didn’t fully iron out this idea yet, but one idea is to convert the current wp_term_relationships table to a more generic object relationships table, which can support posts to posts, posts to users, terms to users, and of course posts to terms (and, really, any arbitrary relationship).

    A disclaimer: This post doesn’t promise anything. Do not rely on the contents of this post for future projects.  It will take us some time to lay out the proper groundwork and make sure we get this right. Do not expect this to happen in WordPress 3.7, or even 3.8. (Actually, do not expect this to happen at all.)

    That said, I’m really glad to get this information out there and I’m excited to hear any feedback you may have. We are always thinking toward the future, and a lot of contributing developers have mile-long roadmaps in their heads — it’s long past time to get those on paper.

    • Scott Taylor 2:39 am on July 28, 2013 Permalink | Log in to Reply

      `WP_Term` should happen as soon as possible. Proper modeling, fix caching, etc

      • Andrew Nacin 6:26 am on July 29, 2013 Permalink | Log in to Reply

        Yes, but ideally we wait until we have a single ID to pass around. It really needs to be term_taxonomy_id, but we don’t pass it around anywhere else in the UI.

    • Jon Brown 2:44 am on July 28, 2013 Permalink | Log in to Reply

      Will this happen for 3.7? j/king… I read every beautiful word of this post including the disclaimer. This all sounds brilliant. TaxID/TermID confused the heck out of me for a LONG time as a new to WP developer.

    • Scott Kingsley Clark 4:06 am on July 28, 2013 Permalink | Log in to Reply

      Excited about all the above, will watch like a hawk at how things go and be available to test and implement changes in my own projects!

    • Manny Fleurmond 4:52 am on July 28, 2013 Permalink | Log in to Reply

      Keeping an eye out for developments. The things that could be possible with connecting posts, terms, users, etc in all types of relationships (one to one, one to many, many to many) is mind boggling. This would definitely help plugins like bbPress and cause an awesome boom of innovation in the WP plugin development community. I wait and watch with baited breath.

    • Grant Palin 5:14 am on July 28, 2013 Permalink | Log in to Reply

      The two terms tables have puzzled me for a while. Now I see it is due to the way core is set up. So it’s interesting that you are looking at correcting the core setup and simplifying things a bit. WP_Terms sounds good, and will help improve the image that WordPress has among some coders as being poorly coded. And not least, the possibility of having content type or term relationships in core would be excellent, and further the ability of WP to be a CMS out of the box.

    • Mike Schinkel 5:22 am on July 28, 2013 Permalink | Log in to Reply


    • Shane Pearlman 5:51 am on July 28, 2013 Permalink | Log in to Reply

      + yay

    • rfair404 7:01 am on July 28, 2013 Permalink | Log in to Reply

      Both are great ideas. I want to play.

    • Avryl 8:29 am on July 28, 2013 Permalink | Log in to Reply

      Awesome! :D

    • Hassan 9:42 am on July 28, 2013 Permalink | Log in to Reply

      For the past two weeks or so I was always thinking about taxonomy meta, whether WordPress will ever support it or should I just go with workarounds (e.g. wp_options). Then all of a sudden @nacin wrote this post! Yay!

      Even though it’s not here yet (hey come soon already!), I’m already planning for some projects! (Yeah, I read the disclaimer :))

    • Julien 10:13 am on July 28, 2013 Permalink | Log in to Reply

      Great news! The future is bright with WordPress. This will open up everything and Worpress will be seriously taken as à tool for web application! Can’t wait to see this released for Wp 3.9 (kidding;))

    • Mike Little 11:24 am on July 28, 2013 Permalink | Log in to Reply

      For those who need to work now with the idea of Term/Taxonomy metadata, there are some plugins already out there. I have successfully used “Taxonomy Metadata” (http://wordpress.org/plugins/taxonomy-metadata/) in a project; also “Meta for taxonomies” (http://wordpress.org/plugins/meta-for-taxonomies/) looks interesting.

      A question: the current system (sort of) supports synonyms/aliases for terms, which can be very useful: are there plans to retain this functionality?

      • Rahe 8:03 am on July 29, 2013 Permalink | Log in to Reply

        Meta for taxonomies is perfect, it uses the WordPress meta API and is only an API ( like the WordPress post_meta ).
        I use it very often, the only problem is there is no easy way like the posts meta box to display/edit the meta in the admin.

      • Andrew Nacin 8:13 am on July 29, 2013 Permalink | Log in to Reply

        I’ve almost never seen it used, but no plans to remove that functionality. This should continue to work just fine. Worth pointing out that any shared terms will be split which could possibly break aliases. Something to keep in mind.

    • aristath 12:30 pm on July 28, 2013 Permalink | Log in to Reply

      This conversation brings in mind what happened on Drupal 6 when it became Drupal 7. I know Drupal and WordPress are 2 completely different things, but bare with me.

      On Drupal 6, there were taxonomies and nodes. Something similar to out terms and posts… And the database structure was also similar to what we have now.
      On Drupal 7 however, they decided to make some radical changes. There were no longer nodes and taxonomies, everything was an “entity”. The database structure was significantly simplified and allowed it to move forward as a CMS.
      Ideally this is the direction I would love to see on WordPress… and this sounds like a first step to that direction.

      The proposed solutions are both viable, though I find the 2nd one more compelling.

      • Andrew Nacin 8:15 am on July 29, 2013 Permalink | Log in to Reply

        Yeah, we’re aware of this. It’s certainly something to at least think about. But I don’t think a generic “entity” makes sense for us.

        I’ll share that, according to folklore, the current taxonomy schema was actually inspired by Drupal’s own schema. And we know how that went. :-)

    • Charles Frees-Melvin 2:25 pm on July 28, 2013 Permalink | Log in to Reply

      What if there was a single meta table and a meta_type filed that has “posts”, “comments”, “users” in it. It would make meta more versatile to extend to taxonomies once taxonomies are ready for it. Kind of like we did to categories and link categories when we came up with the terms/taxonomies system.

    • Mike 2:47 pm on July 28, 2013 Permalink | Log in to Reply

      Does this mean I won’t be able to use one taxonomy term with two different taxonomies?
      Because I thought that was the perfect bug –>>feature scenario.

      • Matt Van Andel 11:57 pm on July 28, 2013 Permalink | Log in to Reply

        This wouldn’t affect that at all. Currently, taxonomy terms are an overly-normalized nightmare. If you create a Category called “Foo” and a Tag called “Foo”, only one term is added to wp_terms and then it is associated with the taxonomy in wp_term_taxonomy. The weird thing about this is that there is only entry in wp_term_taxonomy for each term, even though the normalized terms are listed in wp_terms. It is, frankly, really stupid… but as @Nacin said, hindsight is 20/20.

        What is being proposed is that those two tables are merged. You could still have identical terms in multiple taxonomies – but how they are identified in the database and by the API would change to something a little more sane.

        • Mike Schinkel 5:39 pm on July 29, 2013 Permalink | Log in to Reply

          taxonomy terms are an overly-normalized nightmare.

          Actually, if it had been normalized it would likely be much less of a nightmare. As-is the current schema causes E. F. Codd to turn over in his grave.

    • Robert Chapin 4:29 pm on July 28, 2013 Permalink | Log in to Reply

      Excellent direction.

    • Stephanie Leary 8:09 pm on July 28, 2013 Permalink | Log in to Reply

      I will now find @nacin and give him a hug.


    • portfola 8:43 pm on July 28, 2013 Permalink | Log in to Reply

      This is a welcome development, thank you!

    • Matt Van Andel 11:33 pm on July 28, 2013 Permalink | Log in to Reply

      Finally! These are all things that have driven me crazy for as long as I’ve been developing for WordPress.

      But over at *least* 5 major versions? Ugh. Post 2 Post is a decent bandaid, but that’s functionality that we need in core as of yesterday. What is the reasoning for spacing out the rollout that much? Is it just to minimize potentially breaking changes? Are there ways we can accelerate the process?

      • Japh 11:36 pm on July 28, 2013 Permalink | Log in to Reply

        If you have a listen to Matt’s State of the Word talk, you’ll note that the plan is to speed up update and release cycles generally. So this could happen over a shorter period of time than you might think, despite being over a number of cycles.

        In fact, I imagine it’s this type of thing that’s part of the reasoning behind speeding up the cycles: bigger changes can happen faster.

      • Andrew Nacin 10:43 am on July 29, 2013 Permalink | Log in to Reply

        As the post tried to carefully outline, this requires a significant number of schema, API, and architecture changes. Database upgrades can be very painful, especially with the very real potential of significant amounts of data to modify and migrate here — we need to make sure that we don’t try to bite off too much each release.

        There’s nothing wrong with Posts 2 Posts being in a plugin. You’ll note this post doesn’t actually promise post relationships — it’s entirely possible we leave it out of core for the long term. I’m not saying it’s likely, but my point is that not only is there not a way to accelerate this process, but that there isn’t a need for it either.

        • Taras Mankovski 5:28 pm on July 29, 2013 Permalink | Log in to Reply

          > There’s nothing wrong with Posts 2 Posts being in a plugin.

          This reads like a Jedi mind trick: “You don’t need this… Go back to work.”

          “I don’t need this… I’ll go back to work”

    • sboisvert 4:14 am on July 29, 2013 Permalink | Log in to Reply

      I’ve thought about this. And I’m happy smarter people have also thought about it and now have a good plan to fix it :)

    • Frank Bültge 10:04 am on July 29, 2013 Permalink | Log in to Reply

      @Nacin Thanks for the status. This are very nice news.

    • Michael Dance 5:00 pm on July 29, 2013 Permalink | Log in to Reply

      This sounds like a really, really sharp approach. Great job so far.

      As a heavy Posts 2 Posts user, I just want to mention that post relationships have pretty much eliminated my need for term meta.

      As a simple example: say you have a Journal Article post type and a Journal Issue taxonomy. Each term is a different journal issue, but for each one you’d want an image, a masthead — more than a term can provide. So that’s where term meta could help.

      But: with post relationships, you can just make Journals a post type and relate each journal to a bunch of articles that way. Suddenly journals have access to post meta, featured images, the works.

      I’m not saying I don’t want term meta at all, but there is a danger that it could open the door to terms and taxonomies being used way beyond the scope of what they’re meant to do and muddy the lines between term and post. And while post relationships can cover most of the use cases of term meta (if I’m wrong on this, I’d love to see some examples), the opposite is definitely not true, so to me, post relationships are the bigger priority.

      (All that said, I know that this is a long way off, and in the meantime I’m just as excited about getting rid of the shared term abstraction and creating WP_Term.)

    • Ben Huson 7:11 pm on July 29, 2013 Permalink | Log in to Reply

      Nice to see this on the roadmap – even if we should “not expect this to happen at all” :)

    • Marcus 12:46 pm on July 30, 2013 Permalink | Log in to Reply

      this will be awesome!

    • Allstar 9:14 pm on July 30, 2013 Permalink | Log in to Reply

      I’m all for progress…

      What about internationalisation?

      I’ve wanted for ages for the term_taxonomy tables description field to be moved into the terms table. Therefore all the language would be in one place and the data in another.
      So, you would only use the term_taxonomy_id as a primary for getting stuff BUT you could have multiple terms (in different languages) associated with it. You would not go to the terms table first to find something unless it was by text lookup.

      A WP_Term object is a big *like* from me but I’d l’d also like WP to be easier on the international side of things and my above comment on how to do international user entered terms would be a good step.

      Of course I’m no Core Developer big wig so I might’ve overlooked something but it’s at least worth mentioning in case the idea had been overlooked or I overlooked a way of doing it.

    • shawfactor 7:18 am on July 31, 2013 Permalink | Log in to Reply

      @nacin the speed and modelling improvements would be nice but the can you elaborate further on how you would extend the current taxonomies which are doubles into triples without having a redundant field on the doubles?

      Also I think Posts 2 Posts plugin by @scribu is nice but as I’ve argued: http://shawfactor.com/b/gaA

      post relationships need to be in the core and they nheed to be semantic.

    • Chris Lema 2:53 pm on July 31, 2013 Permalink | Log in to Reply

      +1 for doing it over several releases (even if it’s slow). Quick DB changes have tons of unintended consequences. Great write up.

    • AzzX 12:10 am on August 2, 2013 Permalink | Log in to Reply

      I have used CPTonomies and Posts to Posts to achieve more functionality though they are hacks and susceptible to being discontinued and breaking. This is where Drupal excels. If I want to have ratings and comments on a specific Taxonomy I can – without hacking the core.

    • grindcode 12:10 pm on August 2, 2013 Permalink | Log in to Reply

      This is the last milestone WP needs to approach any needs. Good stuff!

    • Chuck Reynolds 10:43 am on August 3, 2013 Permalink | Log in to Reply

      needs to happen.. might as well start the move and roll it out slow.

  • Jen Mylo 4:50 pm on December 24, 2012 Permalink

    Team Reps 

    Heya. Now that we know Mark will be the release lead for 3.6, on with team rep voting results. :)
    Part of why I wanted to wait was because the people with the most votes were Nacin and Jaquith, and I suspected Jaquith would be leading 3.6 (so he shouldn’t be team rep also, per earlier discussions).

    Core team reps: @nacin and @scribu. Woohoo!

    Term begins with the new year and goes through June.

  • Andrew Nacin 11:08 pm on August 29, 2012 Permalink
    Tags: ,   

    Minified versus development scripts and .min.js 

    For some time (since r10291), WordPress has shipped minified scripts and styles as .js and .css, with the non-minified, “development” versions at .dev.js and .dev.css.

    These weren’t great for discoverability and it has become clear that these are non-standard. So, we’ve moved to using .min.js and .min.css for minified files. You can now find the “development” versions at .js and .css. This also works nicely with tools like ack, which are coded to ignore .min.js.

    This was implemented in #21633. Now if only we can get TinyMCE to move away from _src.js. :-)

    A note, for some external libraries, we don’t include the un-minified versions. In this case, you can find them on their respective websites and also in the sources repository. (This is linked from wordpress.org, which in turn is referenced at the bottom of our license file.) @scribu and I were talking about writing a developer plugin to use un-minified versions of these libraries, which would be cool.

    More on external libraries in 3.5 here.

  • Jen Mylo 4:03 pm on March 7, 2011 Permalink

    I’d like this week’s dev chat to be a discussion about the 3.1 release cycle. We all know it came out around 2 months later than planned, but why? What went well, what could have gone better, and what should we learn from this release and try to improve with our processes for 3.2?

    • Erlend 5:20 pm on March 7, 2011 Permalink | Log in to Reply

      Definitely happy to see this topic — actually considering my recent comment at wordpress.tv the timing is uncanny ;)

      Was it just 2 months later than planned though? As I recall, the end-of-2010 deadline was itself a postponement of an even earlier date. I guess that was also a result of 3.0 being delayed, but that just makes it an integral part of this discussion.


      • Jane Wells 5:28 pm on March 7, 2011 Permalink | Log in to Reply

        Nope. It wasn’t a postponement of an earlier date at all. We decided to take two months off to focus on wordpress.org community infrastructure (the cycle we were calling 3.org), and that just didn’t have a place on the roadmap, so the roadmap was out of date, that’s all.

        • Erlend 5:36 pm on March 7, 2011 Permalink | Log in to Reply

          Oh right! My bad. Yeah I remember those two months, it was a very welcome move, and a bunch got done :)

    • Malcjohn 7:48 pm on March 7, 2011 Permalink | Log in to Reply

      Hi, what abou to make a banner, which says to help to WP community. Maybe we shall also think about how to make developers glad (money…………..VIP section) to make patch for us.

      By the Way : Glad to see you here back

    • Erlend 7:53 pm on March 7, 2011 Permalink | Log in to Reply

      Agreed, I made a couple suggestions along those lines back in the “What should 2011 hold ..” post – see “Acknowledge contributions”.

      Though, I think this is a somewhat different topic. Developer appraisal is quite s separate issue from “what can 3.2 learn from the 3.1 release cycle”.

      • Malcjohn 8:24 pm on March 7, 2011 Permalink | Log in to Reply

        of course you are right, BUT : if we want to change somethink ( read: “what can 3.2 learn from the 3.1 release cycle” ) we have to start to think what we already had made wrong.

        Examples are :
        1.Forget to write a roadmap with dates. Same like Blizzard does.
        2.Pay people, or don’t, if they finish their work or not. Exception for @Nacin a @scribu + some others


        • Erlend 8:51 pm on March 7, 2011 Permalink | Log in to Reply

          There are several reasons why Blizzard doesn’t publicize/use a roadmap, but hardly any of them apply to WordPress. Blizzard and WordPress (or Blizzard and Automattic for that matter) are largely dissimilar.

          Structurally speaking, WordPress is very similar to Ubuntu, which has got an exceptionally steady release cycle that has no doubt been in their favor.

          A successful release cycle is more about meeting expectations than it is about getting tons of stuff done. If you promise too many things, you trap yourself in a release cycle that’s based on work that needs to be done on time. If you promise only a few things, you’ll have a much higher chance of delivering on your promise, and you’ll probably get to surprise your users with a handful of bonus additions that made it in in time for release.

        • Matt 8:46 am on March 8, 2011 Permalink | Log in to Reply

          Very well put.

        • Erlend 1:58 pm on March 11, 2011 Permalink | Log in to Reply

          Thanks, I think. See, here’s an inherent problem of WordPress threaded comments:
          To not make a mess of threads (in this case we seem to have also reached the limit of threading) I usually reply in the same way, that is in this case, reply to Malcjohn in order to make my comment appear directly below yours. I’d like to think you meant to reply to me, however my e-mail notification said you were replying to Malcjohn.

          There logic of the commenting system is a tad flawed. Figured I might as well point that out here since the example use case is right under our noses.

    • arena 11:33 pm on March 7, 2011 Permalink | Log in to Reply

      3.2 > PHP5 > WordPress Object Oriented code

      will help for sure !

  • Andrew Nacin 10:16 pm on October 27, 2010 Permalink

    Plugin activation hooks no longer fire for updates 

    Following up on @scribu‘s post with further rationale and the 31compat tag.

    The many problems. When plugin upgrades were introduced in 2.8, the activation hook fired for them. The deactivation hook did not. This was inconsistency number one.

    When bulk plugin upgrades were introduced on the Tools > Updates screen in 2.9, the activation hook did not fire (during the bulk upgrade). This was inconsistency number two.

    Bulk plugin upgrades were given greater prominence in 3.0, with the Updates move to under Dashboard, and a new bulk action on the plugins screen. This made the second inconsistency far more prominent.

    Additionally, activation hooks could always fire on activation, because that has to be done through the admin, but updates don’t. Updates done manually (including SVN) was just one more instance where we may not have been firing updates. This was inconsistency number three.

    We felt that the proper fix was to prevent the activation hook from firing on any upgrades, bulk or not, as this was not intuitive. Sorry if your plugin relied on this undocumented behavior.

    The theory behind the right way to do this. The proper way to handle an upgrade path is to only run an upgrade procedure when you need to. Ideally, you would store a “version” in your plugin’s database option, and then a version in the code. If they do not match, you would fire your upgrade procedure, and then set the database option to equal the version in the code. This is how many plugins handle upgrades, and this is how core works as well.

    The right way to do this. I would do what many other plugins do and do the upgrade procedure as I described, and as Peter and Andy described in the previous post.

    Further reading. You can read more about this issue, on ticket #14915.

    • Michael Torbert 10:18 pm on October 27, 2010 Permalink | Log in to Reply

      Even though that’s certainly a way to accomplish the same thing, the logical solution would be to make another hook for activation.

      • Ryan Boren 10:20 pm on October 27, 2010 Permalink | Log in to Reply

        Which would not run for manually upgraded plugins. Hooks for upgrades is a non-starter. Plugins have to do it.

        • Michael Torbert 10:25 pm on October 27, 2010 Permalink | Log in to Reply

          I would guess that most plugins are automatically upgraded, making this a simple solution.

        • Ryan Boren 10:29 pm on October 27, 2010 Permalink | Log in to Reply

          Many people use git or svn, and relying on a hook is not multisite compatible.

    • Stephen Cronin 1:55 pm on October 28, 2010 Permalink | Log in to Reply

      Thanks for explaining that Nacin.

      I’m currently misusing the activation hook – my activation function includes all the update logic I need. I’m aware it doesn’t work for FTP updates, so my update instructions tell people to deactivate and then reactivate the plugin. Of course, that won’t work for SVN updates, which I hadn’t considered (although with due respect to Ryan, I’d argue that not many *average users* would update via SVN).

      If the logic needs to be handled via the plugins, that’s fine, I’ll update mine. In fac,t I used to handle it in the plugin but removed it because I figured that running something just on activation would be more efficient that checking the version number on every single page load. For one plugin, not much of a drama, but when you start having 30 plugins all checking their version number on every page load of the site… But if that’s what we have to do, then that’s what we have to do.

      • Andy Skelton 2:16 pm on October 28, 2010 Permalink | Log in to Reply

        It’s not inefficient for every plugin to store a small amount of data in the options table. They will all be automatically loaded with a single query. The overhead added by a single, small row is small enough to ignore.

        • Peter Westwood 2:19 pm on October 28, 2010 Permalink | Log in to Reply

          Also – you should try really hard to ensure your plugin still works even with the old settings until the upgrade had happened unless it can be done without user interaction.
          In most cases if you need user interaction you can trigger an admin_notice on the next page load after the update.
          If you have a update that takes a while consider using a wp-cron “job” to do the migration work.

        • Stephen Cronin 2:47 pm on October 28, 2010 Permalink | Log in to Reply

          Thanks for pointing that Andy.

          I was assuming a separate DB call for each plugin’s options entry. I knew the core options were bundled into a single DB call, but was under the impression (from heresay, not anything resembling facts) that non core options weren’t included and needed a separate DB call.

          And Peter, yes, you’re right of course, the plugin shouldn’t rely on something existing that may not be there. I code properly *most* of the time, but I guess I’ve leant on the activation hook crutch occasionally. I think I need to spend some time with my plugins and make sure I’m not making the problem I’m complaining about :)

        • Peter Westwood 2:49 pm on October 28, 2010 Permalink | Log in to Reply

          @Stephen: As long as you ask for your option to be autoloaded when registered it comes in one query with the rest of the autoloads

        • demetris 11:48 am on October 29, 2010 Permalink | Log in to Reply

          Just a note regarding autoloading of options:

          By default, autoload is set to yes for all options added via add_option. So, other than adding your option, there is nothing you need to specify if you want it to be autoloaded.

          More here: http://codex.wordpress.org/Function_Reference/add_option

    • Jarkko Laine 7:35 pm on April 12, 2011 Permalink | Log in to Reply

      Hi, just a quick note to point out that this documentation page is still giving wrong instructions for plugin developers: http://codex.wordpress.org/Creating_Tables_with_Plugins


    • Clint 2:54 am on May 15, 2012 Permalink | Log in to Reply

      I am VERY late to this party, but when I manually de-activate a plugin, and then reactivate it again manually, won’t fire the “acivation hook”? Seems a little stupid. Also makes testing my plugin a huge pain.

      • Andrew Nacin 8:40 pm on August 31, 2012 Permalink | Log in to Reply

        Even later to reply to you — If you manually de-activate and manually reactivate, yes, it fires the activation (and deactivation) hooks. This was only for core’s one-click updates — when we update a plugin, we do not fire an activation hook.

  • scribu 2:02 pm on October 27, 2010 Permalink  

    Plugin activation hooks 

    Attention all plugin authors:

    If you were using register_activation_hook() to also handle updates from older versions of your plugins, you will not be able to do so any more in WP 3.1: [16012]

    The activation hook is now fired only when the user activates the plugin and not when an automatic plugin update occurs. This is consistent with how the deactivation hook works.

    There is a proposal for a register_update_hook() instead: #14912

    Also, the callbacks for de/activation can now accept a network activation flag:


    • demetris 2:55 pm on October 27, 2010 Permalink

      Argh! I do not like this!

      I don’t have a good grasp of the issue, but I somehow feel we shouldn’t remove this feature, even with its current inconsistent behaviour, without having something to replace it first.

      Why not wait until we have an update hook?

      • scribu 3:24 pm on October 27, 2010 Permalink

        It’s not a feature, it’s a an inconsistency that leads to obscure bugs.

        As for the update hook, please lobby for it’s inclusion then.

      • Peter Westwood 3:29 pm on October 27, 2010 Permalink

        It is a bug pure and simple and this fixes it.

    • Rich Pedley 3:48 pm on October 27, 2010 Permalink

      argh. darn dagnabit. better change my update routine then. I’m so relieved I did some changes in preparation for this, it’s going to catch a lot of plugin authors out though.

      • Rich Pedley 3:51 pm on October 27, 2010 Permalink

        actually quick query, what is the best thing to hook onto for updates at the moment? init?

      • Peter Westwood 3:52 pm on October 27, 2010 Permalink

        That is what they get for holding it wrong.
        Relying on a hook for update detection is not a good ideatm as there are too many scenarios in which is won’t fire.
        Good plugins would use something similar to the $db_version that core uses itself.

        • Andy Skelton 3:58 pm on October 27, 2010 Permalink

          For ages I have used a constant and bumped it only when the updated plugin will need to run some upgrade code. I agree this is the way to go.

        • demetris 4:52 pm on October 27, 2010 Permalink

          “Good plugins would use something similar to the $db_version that core uses itself.”

          I would agree if you said “Perfect plugins”, because I know of good plugins that rely on this inconsistently fired hook to run their upgrade code. :-)

          I think the problem I see with this change is that we remove something people use without telling why it is removed and what should be used instead.

          If an update hook can never be reliable (because plugins are often updated through channels of which WP cannot be aware), then we should wontfix that ticket and tell people clearly that the only reliable method is what you and Andy describe.

        • scribu 5:11 pm on October 27, 2010 Permalink

          I think the problem I see with this change is that we remove something people use without telling why it is removed and what should be used instead.

          We announced it here and described the reasons for it.

          We also suggested a fix.

          If an update hook can never be reliable (because plugins are often updated through channels of which WP cannot be aware), then we should wontfix that ticket and tell people clearly that the only reliable method is what you and Andy describe.

          The register_update_hook() proposed is exactly what westi and Andy describe, so it is reliable.

          In conclusion, please check your facts first.

        • demetris 6:23 pm on October 27, 2010 Permalink


          If I understand correctly, the feature is removed because it cannot be relied upon: the hook is fired in some cases, but not in others. This announcement says nothing of the sort.

          The fix suggested is slated for a future release (and we are now into feature freeze). What are people to use for 3.1?

          About the way register_update_hook works, my apologies. I had not looked at the code and, going by the function’s name, I thought it was a hook. But it is not a hook. It is not hooked on to anything. It is a helper function that, as you said, does what Peter and Andy described and that runs everytime the admin is loaded.

          (Which does not provide for all scenarios: If I don’t update via the admin, the update code will not run until I visit the admin.)

        • scribu 6:32 pm on October 27, 2010 Permalink

          To clarify, the activation hook can’t be relied upon for updating. Makes sense?

          Furthermore, it’s not removed, just restricted to it’s intended purpose.

          Also, we still have a few days until feature freeze, so I’m hopeful.

          Anyway, register_update_hook() doesn’t require any other core modifications, so plugin authors can just drop it in their plugin, wrapped in an if ( !functions_exists() )

        • demetris 6:55 pm on October 27, 2010 Permalink

          According to the schedule, feature freeze was on the 15th of October:


          In any case, I think an extra post explaining all this would be useful:


          We don’t fire the activation hook anymore on plugin updates because it was not reliable for update detection:

          1. It did not work for bulk updates

          2. It did not work for network updates

          3. It did not help for updates not done via the admin


          The reliable method for update detection is [what Peter and Andy described].


          [What we say here depends on whether register_update_hook makes it into 3.1.]

        • scribu 7:45 pm on October 27, 2010 Permalink

          I meant to say primary code freeze.

          Anyway, nice summary.

        • Alex M. 8:51 pm on October 27, 2010 Permalink

          +1 to using a constant/variable. I’ve always stored a version number in my settings array and when I loaded the settings, I checked the version and did an upgrade if need be.

          Relying on a hook is poor form in general.

    • Will Anderson 11:31 pm on October 27, 2010 Permalink

      I’m thinking this should be a simple s/register_activation_hook/register_update_hook for 99% of plugins that will be broken, assuming register_update_hook makes it into 3.1

      • scribu 8:38 pm on October 28, 2010 Permalink

        Yeah, the only thing would be that register_update_hook() requires a version too.

    • Jeff 4:46 am on October 28, 2010 Permalink

      Reading this and Nacin’s post really helped clarify this. It does make sense to not expect activation hooks to handle upgrades. Especially if a plugin is not deactivated on upgrade (svn, ftp etc).

      Excuse me while I go make updates.

    • arena 12:28 pm on October 28, 2010 Permalink

      Is there a way to avoid an automatic plugin update ?

      • scribu 8:39 pm on October 28, 2010 Permalink

        Yes. There’s a plugin called something like “No Plugin Updates” that does this. You should check it out.

    • Cian Kinsella 4:21 pm on February 28, 2011 Permalink

      This really did catch us out, I’m sure we won’t be the last. Shouldn’t the automatic update process stop displaying misleading messages such as “Deactivating the plugin…, Removing the old version of the plugin…, Plugin updated successfully, Reactivating the plugin… :)

      • scribu 4:32 pm on February 28, 2011 Permalink

        It doesn’t say “Successfully fired activation hook”, so it’s not misleading. ;)

        • Cian Kinsella 5:33 pm on February 28, 2011 Permalink

          You are pulling my leg aren’t you?

        • scribu 5:39 pm on February 28, 2011 Permalink

          Only partly. Read the discussion again (including the one on trac).

    • face-gamers.com 10:43 am on March 8, 2011 Permalink

      We lost all of our comments by updating the plugin.

      How can we stop this happening in the future apart from not updating?

    • Steve 3:19 am on October 25, 2011 Permalink

      Had a question about testing my changes to my plugin’s upgrade routine once I’m done making those changes.
      I don’t want to push an update (the next higher svn tag) to my plugin’s SVN repo on WordPress just to test how an automatic update would behave. Do I simply just downgrade my live wordpress to the lower version of my plugin and then with filezilla ftp , just copy over the newer version of my plugin ?
      thanks for the info above

      • Steve 1:41 pm on October 25, 2011 Permalink

        You can ignore that. The obvious solution to testing the auto upgrade (without pushing a newer version that I didn’t want wp users to download) is to simply install a version going back to two versions to my WordPress blog, and then I can test what the auto update does after tweaking my current version a little.

    • Mika "Ipstenu" Epstein 1:07 pm on October 25, 2011 Permalink

      Steve – That’s not really a question for this post :) You could either post in the support forums: http://wordpress.org/support/ or email the hackers list: http://lists.automattic.com/mailman/listinfo/wp-hackers

      But basically if you wanted to test an upgrade, and knowing that the activation hook is called “when the user activates the plugin and not when an automatic plugin update occurs” then you really don’t even need to downgrade. I would upload the plugin as trunk and NOT make it the release version, then download the ‘development’ version from http://wordpress.org/extend/plugins/YOURPLUGIN/download/ and use the zip-uploader in WP to upgrade it.

      If you need more help on doing that, post on the forums or mail hackers, please :)

  • Jen Mylo 4:08 pm on September 3, 2010 Permalink  

    Process and Scope for 3.1, Part I 

    Last night’s dev chat was the first of two planning meetings for 3.1. The intention of this meeting was to remind everyone of the goals for 3.1, identify features that the lead team has prioritized, get an early sense of who’s willing to work on what, and to talk about the timeline. Much of what is written here is what was posted in the dev chat last night, to retain consistency.

    There were a lot of suggestions on the table. That said, quite a few suggestions fall outside the stated intentions of 3.1 (quick, fast dev cycle, no big huge projects). For anyone late to the party, here are the goals of 3.1: to have a very short dev cycle, a decent amount of testing time, and a release in mid-December. Low on new features, heavy on ui and code cleanup, and avoidance of schema changes. Save the big ideas for 3.2 where we’ll have the liberty to implement those ideas in PHP5. No schema changes and no big new APIs.

    This means stuff that got worked on over the summer or can be taken more or less wholesale from a plugin or patch has a better chance of being allowed into 3.1 than a brand new idea that doesn’t already have code written. In cases where we can do something small in 3.1 to pave the way for something bigger in 3.2, that will be the approach.

    To that end, the leads have identified some of the suggestions, both from the wpdevel and from other sources such as the ideas forum/WordCamp feedback/support forums, that would be appealing to include in 3.1. We’ve also identified some things that definitely do NOT fit into the scope of 3.1.

    An example of something that doesn’t fit:
    Media overhauls. We’re going to target 3.2 for a bunch of media fixes. The underlying code is too complex to do anything hardcore this fast. The only media things that would be acceptable in 3.1 would be small updates that don’t change the overall flow, such as the request to make the caption able to hold html to include links. If someone volunteered to code that, that addition would be acceptable in terms of scope. Other discrete things like this would work. Refactoring the way featured images work would be out of scope.

    Another thing that doesn’t fit is per-post/page/category widget selection. There are plugins that do this, and the code is nuts underneath. We want to stick to easy wins for 3.1.

    Now on to things that fit!


    Polishing features introduced in 3.0 can be one umbrella task. BUT — this means spit and polish ONLY, not adding features to features.

    New feature: Mark Jaquith is committed to getting in some advanced taxonomy queries stuff, which already has some movement in trac via scribu.

    Mark Jaquith also wanted to get down and dirty with roles/caps, but that’s just too big an undertaking for 3.1. Maybe in 3.1 we could do the get_users() and friends cleanup that scribu started on to pave the way for role cap cleanup next time around.

    In short? Mark Jaquith and scribu will be joined at the hip this cycle. :)

    New feature: Internal linking. This is my pet user feature for this release. It has been requested from users for years, got the most +1s on the wpdevel post last week, and is a missing piece of true CMS functionality. Since we likely won’t have Andrew Ozz for this release, Daryl Koopersmith is going to take a stab at this, with backup from Austin Matzko if needed.

    New feature: The ajaxified admin screens that scribu did for GSoC, with some UI cleanup applied. There was also a GSoC project by Matt H on comment moderation that needs to be reviewed for inclusion.

    New feature: Admin Bar. Connect the back end to the front end. Most useful for people on multisite installs, but still useful for single-site users in providing 1-click access to dashboard, new post form, etc. We’ll be looking at both the original Viper007Bond admin bar plugin and the wordpress.com revised admin bar recently done by Andy Peatling. Note: there was some resistance to this being in core rather than a plugin. A compromise of making it optional was discussed.

    Cleanup: UX/UI cleanup across the application, including multisite. This could turn into a ton of new dev, so we need to restrain ourselves. The UI group will do a review and come up with a list. Jane Wells and John O’Nolan will manage UI contributions from the group so that approved UI makes it into tickets.

    Ongoing maintenance: Bug fixes. Peter Westwood is all over bug fixes. Anyone and everyone invited to submit patches for known bugs.

    New feature: Separate network dashboard from the site dashboards (in multisite). Ryan started on this over the summer, and all agreed it would be great. Needs some UI love. Ryan also looked at doing a personal dashboard to replace the wonky global dashboard you get in multisite when someone has an account but no site. This might be a better 3.2 candidate, but we’ll see if we can get it to a reasonable place in time for 3.1.

    There are some small fixes to the custom post types API that ought to be made, while staying within the ‘no big API things’ guideline. Nacin is taking charge of this.

    I’d like to swipe the wordpress.com UI for searching/browsing installed themes, as it’s better than what we have in core (especially useful for multisite and sites with lots of installed themes, like those on shared hosting). I helped on the UI when John Godley made it last year, so I’d be comfortable with almost a straight swipe.

    New feature: Post templates/post styles. Ryan will be handling this one.

    New feature: Making QuickPress a template tag, so it can be used for front-end posting. Aaron Jorbin will be handling this.

    Other suggestions not on this list that fit into the 3.1 guidelines (no schema changes, no big new APIs, etc) will be considered until feature freeze if a well-tested patch has been posted by then. Well-tested means more than one person, so if you want your pet project to be considered for 3.1, publicize your patch and get people to test it and post their results to the trac ticket! If you do not take on this responsibility, please do not complain if your patch is not considered; tested patches will always get priority.


    We want to release mid-December, preferably no later than December 15, so that the holidays won’t interfere with the release. To that end, here is the current plan:

    September 9 – Confirm planned scope.

    October 15 – Feature freeze; no new features added after this point, so that testing can begin on a stable-ish product (including usabilty testing of new features).

    November 1 – Primary code freeze; any last adjustments based on testing after feature freeze should be finished by now and the focus shifts to fixing bugs to get to a stable beta.

    November 15 – Beta period beings; from this point on, no more enhancements, only bug fixes.

    December 1 – String freeze; translators rejoice.

    December 15 – Release WordPress 3.1

    So that’s the current thinking. The leads will be reviewing existing tickets and patches this week and working out the feasibility of including all the items outlined above. Next dev chat should see a conclusion to 3.1 scope planning, with some firm decisions on in/out and dates.

    • Melvin Ram 4:19 pm on September 3, 2010 Permalink | Log in to Reply

      I’d like to help with the UX/UI cleanup. Where will the UI group post this list once they do the review?

      • Jane Wells 4:52 pm on September 3, 2010 Permalink | Log in to Reply

        You will want to follow the UI blog at http://make.wordpress.org/ui and/or join the weekly IRC meetings in #wordpress-ui at irc.freenode.net.

        • Ozh 6:22 pm on September 3, 2010 Permalink | Log in to Reply

          Is anything planned regarding option pages? I find them quite dull and messy compared to other much more lively pages such as… all the others actually.

          • Jane Wells 6:47 pm on September 3, 2010 Permalink | Log in to Reply

            Agreed, and they’ll be included in ux/ui review, but whether or not/to what degree they will be touched will depend on how many people volunteer to write the patches once we have approved wireframes.

    • Carl Hancock 4:19 pm on September 3, 2010 Permalink | Log in to Reply

      “New feature: Post templates/post styles. Ryan will be handling this one.”

      What is this? Can someone provide more information on this new feature as it was discussed?

    • Kim 4:32 pm on September 3, 2010 Permalink | Log in to Reply

      “New feature: Admin Bar. Connect the back end to the front end. …. Note: there was some resistance to this being in core rather than a plugin. A compromise of making it optional was discussed.”

      Of the 2 possibilities, I prefer the current wordpress.com admin bar.

      Please make this optional, default is off. That way users that want it will have to enable it if they want it.

      • Mike Schinkel 5:27 pm on September 3, 2010 Permalink | Log in to Reply

        > Please make this optional, default is off. That way users that want it will have to enable it if they want it.


      • Alex M. 7:17 pm on September 3, 2010 Permalink | Log in to Reply

        I don’t think there’s anyone arguing that it shouldn’t be optional (i.e. you can’t turn it off).

        There might be some arguing that it should be on by default, but I personally think it should be off by default as well.

        As for in core vs a core plugin, I haven’t made my mind up about that one.

        • Alex M. 7:18 pm on September 3, 2010 Permalink | Log in to Reply

          Oh, and yes, I wouldn’t recommend using much of the code behind the scenes of my plugin. It’s rather dated and messy. It’d be much better to stick to stealing ideas and concepts from it rather than code implementations (giving it a code rewrite has been on my todo list for a while).

        • Mike Schinkel 8:39 pm on September 3, 2010 Permalink | Log in to Reply

          It would be really nice if it could be the plugin that finally kicks off the concept for core plugins that we’ve been waiting for since announced. :-)

        • Mark 5:10 pm on September 4, 2010 Permalink | Log in to Reply

          I’m sure there was a lot of discussion around the whole idea and that if it’s made it in, it’s made it in. Nevertheless I think the logic escapes me (even after a brief review of the irc chat) why an admin bar would be more functional to CMS usability than something such as, say, the front end editor.

          I’m sure I’m not an average test case but out of the last couple dozen WordPress powered sites I’ve set up, it has never once crossed my mind that a front end admin bar would be a snazzy addition. +1 to it being optional and turned off by default, +1 to it having an uninstall feature.

        • Matt 5:11 pm on September 4, 2010 Permalink | Log in to Reply

          Admin bar is first step toward a front-end editor — think long term.

        • Voyagerfan5761 6:20 pm on September 4, 2010 Permalink | Log in to Reply

          Front-end editor, did you say? It would be awesome to see functionality like this integrated into core at some time in the future. (Of course, it’s a scribu project. ;-)

      • Ryan McCue 1:07 am on September 4, 2010 Permalink | Log in to Reply

        Agreed, the WP.com admin bar seems to be the way to go, considering it was only recently rewritten as well (apparently).

        Definitely agreed on making it optional, and I think a core plugin is the best way to go on this.

        For the record, the bug for tracking this is #14772

    • Ozh 5:14 pm on September 3, 2010 Permalink | Log in to Reply

      What is the “internal linking” stuff about exactly?

    • Mike Schinkel 5:27 pm on September 3, 2010 Permalink | Log in to Reply

      Are there a trac tickets for “advanced taxonomy queries” and “small fixes to the custom post types API” that detail scope? Thanks in advance.

      • filosofo 5:58 pm on September 3, 2010 Permalink | Log in to Reply

        Start here for taxonomy queries, and post types API.

        • David Cowgill 10:47 pm on September 3, 2010 Permalink | Log in to Reply

          This is a great start! Would also love to see the sticky post option & custom permalink structures enabled for custom post types.

          Another one is adding a simple post type drop-down on post edit write panels. Basically bring in this plugin. http://wordpress.org/extend/plugins/post-type-switcher/

        • Andrew Nacin 5:42 pm on September 4, 2010 Permalink | Log in to Reply

          I’m going to be looking at the first two ideas for 3.1. But I don’t foresee a post type switcher ever making it into core. Not every post type is publicly consumable content that can easily be traded off. Some might rely on specific fields, values, meta, not to mention term/taxonomy relationships, and offering a UI for that can easily break things. Keep in mind there’s no UI for post types anywhere, nor are there any plans for that to occur. The UI (same goes for the user) makes no distinction among post, page, event, employee.

        • Mike Schinkel 6:57 pm on September 4, 2010 Permalink | Log in to Reply

          @Andrew: Point of note, non publicly consumable content will have their public argument set to false so it would be easy to exclude them from content switcher so I wouldn’t see that as a viable concern. Even better, “allow_type_switch” could be added to “supports” enabling only explicitly approved content to be switched. Posts and Pages could be set as such and then developers could choose which custom post types they wanted to enable switching. Such an approach would assure pretty much no breakage. And let me go on record to say that the team will eventually add UI features for post types because 80% of users will demand it (just sayin…)

        • David Cowgill 7:31 pm on September 4, 2010 Permalink | Log in to Reply

          @Andrew, great. Those features will be welcome additions. For the custom permalink structure I recommend it can either inherit the WP defined one or you can create a totally different structure.

          I see what you mean about breaking things with a post type switcher. Even though it’s complicated, I have to agree with Mike that eventually people will request it. Guess it will have to wait until then. :-)

    • Rich Pedley 6:19 pm on September 3, 2010 Permalink | Log in to Reply

      No mention of the accessibility that jorbin mentioned?

      Considering that Matt is a member of GAWDS (Guild of Accessible Web Designers) perhaps this should be a bit more prominent ;) I’m also surprised you haven’t contacted any of the GAWDS admins about accessibility, especially as one of the forum moderators, esmi, is a GAWDS admin….

      But if jorbin is reading, feel free to drop me an email as I have experience in reviewing sites for accessibility and could help out as well. I’m just not that ofay with trac/patches etc, but would be willing to work with someone who is to get the ball moving.

      • Jane Wells 6:49 pm on September 3, 2010 Permalink | Log in to Reply

        Accessibility isn’t a discrete new feature, which is why it isn’t called out separately but falls under the umbrella of ‘anything that can be written/tested/submitted before freeze.’ Accessibility patches will be reviewed and added anytime someone submits them (assuming they are up to par, of course). The problem is that very few people choose to submit accessibility patches. Accessibility patches welcome.

        • Rich Pedley 9:37 pm on September 3, 2010 Permalink | Log in to Reply

          bleh, that means I’ll have to learn how to do patches correctly ;) – well when needed anyway, accessibility usually involves a lot of discussion.

          As the accessibility list is dead I’ll ask here, which would you prefer I looked at first, the Twenty Ten theme, or just dive into the admin pages?

        • Andrew Nacin 11:50 pm on September 3, 2010 Permalink | Log in to Reply

          Jorbin and I met the other day with an accessibility expert who is local and we agreed that we should definitely try to audit what we can. It’s a very intensive task but patches are *always* welcome except really late in the cycle.

          I’d like to look at both. Having TT accessible will be nice, with the admin being higher priority (but more difficult).

        • Rich Pedley 7:34 am on September 4, 2010 Permalink | Log in to Reply

          Well I’ll start with Twenty Ten then ;) That’s actually more static than the evolving admin backend anyway. So should be slightly easier to assess. Well hopefully.

          I’d actually say the front end is more important than the back end, but with the number of different themes out there, it’s slightly skewed. It’s also a good way to test the water, see how changes are accepted etc.

          Also it has to be realised that different people will pick up on different things, accessibility isn’t as always a clear cut case.

          And yeah I saw that you’d had a meeting in the chat logs (see someone does read them).

          But remember the best way for accessibility auditing, is to use pan disability testing. I do know of a few but obviously their services, in the main, are not free.

        • Rich Pedley 2:46 pm on September 4, 2010 Permalink | Log in to Reply

          A big ‘doh’ from me re patches, let me never complain about them again.

          Made a start with Twenty Ten, just concentrating on links ‘mainly’, adding other bits if I come across them. Will submit a patch for CSS only when done.

        • Jane Wells 1:40 pm on September 5, 2010 Permalink | Log in to Reply

          @Rich: I would say look at the admin first, becaase Twenty Ten can be updated anytime, not tied to a release schedule. I will say that in previous releases we have had volunteer accessibility professionals review the admin through their systems once we get to the beta stage, and we fix anything they tell us is an issue. As you say though, different people will turn up different things.

    • arena 9:55 pm on September 3, 2010 Permalink | Log in to Reply

      as far as i see new “The ajaxified admin screens” will break a lot of plugins admin pages ( #14651, #14776 )

    • Scott 12:07 am on September 5, 2010 Permalink | Log in to Reply

      Might be too late to suggest this, or maybe the wrong place now that the dev chat and discussion already occurred, but:

      • Update core to the latest version of jQuery UI

      – Once that’s done, consider using the autocomplete that’s built into the latest version rather than suggest.js (http://core.trac.wordpress.org/ticket/12399)

      • Andrew Nacin 3:28 am on September 7, 2010 Permalink | Log in to Reply

        We’ll be updating jQuery UI, but no plans to utilize autocomplete. We don’t use it anywhere in core, and suggest.js has served us well. Seems like an unnecessary refactoring.

    • Knut Sparhell 1:04 am on September 5, 2010 Permalink | Log in to Reply

      No taxonomy meta table?

      There are a lot of fine work going on out there among plugin authors, using custom post types with custom taxonomies. These are grets features that developed WordPress into a completely new dimension.

      Bu we MUST have a way to store meta data about a taxonomy id, like contact info, price scheme, valid, periods of validity an so on foremver. Now every athors invents their own method of storiung this data.

      Couldn’t WordPress core just define and create a tax_meta table for 3.1. I mean, without doing anything with it, Just lket it exist there for plugins, at least until 3.2?

      Or could we have an “officially” proposed table name and layout for this, something that plugin authors could implement an create, if not already created?

      Having ten plugins that all impelement their own prorietary metadata table is not a good situation, at least not the day WordPress core wants to implement one, too.

      I would say tha ta taxonomy_meta has become a “core necessity” and it’s quite urgent.

      • Mike Schinkel 9:13 pm on September 6, 2010 Permalink | Log in to Reply

        +1 on a revisiting the idea of a taxonomy meta table here. Lots of requests here and almost all of the code needed is already in 3.0 so scope is very small. Doesn’t need a UI yet, just needs to be there for plugin and theme devs.

      • Andrew Nacin 3:24 am on September 7, 2010 Permalink | Log in to Reply

        Not for 3.1, but we’ve talked about publishing a “If we did it” post. So I’ll get going on that.

        • Justin Tadlock 12:28 pm on September 8, 2010 Permalink | Log in to Reply

          That post definitely needs to be written, and it needs to be “official.” I’ve gotten multiple questions relating to this on a weekly basis for over a year now from users. The only reason I haven’t implemented it myself is because I don’t want to deal with upgrade issues if core goes in a different direction in the future.

        • Andrew Nacin 12:44 pm on September 8, 2010 Permalink | Log in to Reply

          That’d be exactly the idea.

        • Mike Schinkel 6:26 pm on September 8, 2010 Permalink | Log in to Reply

          Just curious. If you can write an article about how you’d do it, why not just do it? From what I understand 90% of the code is already in core, right? (This is an honest question; I’m just trying to understand the need for delaying until after 3.1?)

    • Simon Wheatley 2:39 pm on September 6, 2010 Permalink | Log in to Reply

      Can I cheekily push forward this media suggestion (in the knowledge that full media overhauls are out of scope)… just *three* filters! http://core.trac.wordpress.org/ticket/13817

    • Brian Richards 6:47 pm on September 6, 2010 Permalink | Log in to Reply

      To clarify, is http://core.trac.wordpress.org/ticket/12877 making it into 3.1? (specifically, searching for page templates in sub-folders?

    • Paul Hastings 2:01 am on September 7, 2010 Permalink | Log in to Reply

      It’d be awesome to swipe the wordpress.com method for searching already installed themes. I run a WPMS install and right now it’s a pain to manually dig through 60+ themes.

    • Tracey 10:49 pm on September 8, 2010 Permalink | Log in to Reply

      Any chance of getting a simple ‘hide’ checkbox in the custom menu admin so that if you want to disable a menu item temporarily you don’t have to delete and add again. Reason I ask is that every time you do that it gives you a different css class which means, if you’re reliant on those classes for your styles you have to fix the css every time. Which also means that my clients are dependent on me to do this for them.

      • Jane Wells 2:56 pm on September 9, 2010 Permalink | Log in to Reply

        Probably not in 3.1. We’re pretty resolved to not touch the menu system until 3.2. You’d probably be better off writing a plugin for this right now, and if it becomes popular, we can consider the functionality for core in the future.

    • Avi 8:27 am on October 5, 2010 Permalink | Log in to Reply

      I am not clear with internal linking. What is it?

    • Gustavo S. Bordoni 3:55 am on November 4, 2010 Permalink | Log in to Reply

      I was developing something that required the query for multiple Custom Fields, and when I was reading this I thought that Is a old request (http://bit.ly/cuujoQ). And there is any chance that will be coming any time soon?

      Thanks alot,

  • Jen Mylo 10:34 am on August 9, 2010 Permalink

    Today in #wordpress-gsoc, it’s @nacin at 19:30 UTC (Theme revisions/editor project) and @scribu at 20:30 UTC (ajaxify admin). I will hopefully be there, but if my flight doesn’t land on time, go ahead without me and I’ll read the logs afterward.

    • Andrew Nacin 5:16 pm on August 9, 2010 Permalink | Log in to Reply

      Unfortunately to to some major, unexpected changes in my travel plans I cannot host today. Will talk with Jane once she’s grounded and will try to set up a time for Tuesday or Wednesday.

compose new post
next post/next comment
previous post/previous comment
show/hide comments
go to top
go to login
show/hide help
shift + esc