WordPress.org

Ready to get started?Download WordPress

Make WordPress Core

Updates from June, 2014 Toggle Comment Threads | Keyboard Shortcuts

  • Mike Schroder 6:03 am on June 19, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    Last Week(s) in WordPress Core 

    Hi Everyone! It’s time for another update. This edition covers through Sunday, June 15th, and has taken a while due to travel, but @swissspidy & @designsimply have joined the team, helping to gather the information to bring us up to date. Hopefully this will help these updates be a bit more sustainable over time. If you’re interested in pitching in with these updates as well, please let me know in the comments below!

    Especially of note are the first pass of the grid view for the media library, several SSL and oEmbed updates, and a new ‘Beta Testing’ tab on the Plugins screen.

    Admin

    • Plugins Screen: Add a new ‘Beta Testing’ tab on the plugin installation screen, for features as plugins such as Press This. [28749] #28513
    • Media Library: Grid view for the media library, first pass. This is alpha; expect imperfection to start. [28682] #24716

    SSL

    • Forcing SSL logins now forces SSL for the entire admin. [28609] #10267
    • Force SSL on the frontend when the home URL uses HTTPS. [28610] #27954
    • Force SSL admin when siteurl is explicitly configured with HTTPS. [28674] #27954
    • Use a secure logged_in_cookie when the home URL is forced HTTPS. [28627] #15330
    • Deprecate url_is_accessable_via_ssl(). [28709] #19555

    Embeds

    Themes and Templates

    • Add a filter to human_time_diff() to allow more detailed depictions of time differences. [28670] #27271
    • Allow simple modification of sections of the title by adding a wp_title_parts filter to wp_title(). [28669] #17877
    • Add CSS rules to ensure that videos will be responsive, regardless of theme. [28650] #28414
    • Replace TEMPLATEPATH and STYLESHEETPATH with get_template_directory() and get_stylesheet_directory(). These constants are now deprecated [28563] #18298
    • Update Twenty Thirteen and Twenty Fourteen to Genericons 3.0.3. [28692] [28693]

    Accessibility

    • Improve keyboard accessibility for the media modal. [28607] #23560
    • Add screen reader labels to the date inputs on the post editing screen. [28730] #25461

    WP_Query

    • When parsing the main query, if s is set to empty: ?s= and $this->is_main_query() && array_key_exists( 's', $this->query ) – kill the query instead of loading the homepage. This will load the search page with no results. [28612] #11330
    • Kill queries that explicitly pass empty arrays to category__in, tag__in, tag_slug__in, and author__in to WP_Query. [28664] #28099
    • Fix SQL generation when meta_query has an 'relation' => 'OR' for its queries and wants to 'orderby' => 'meta_value'. [28659] #25538
    • Allow users to sort posts by type in WP_Query. [28605] #28214
    • Add access modifiers to WP_User_Query Add magic methods for BC: get(), set(), isset(), unset(), and call(). [28528] #27881, #22234

    Internals

    • Wide-reaching changes to do away with many instances of variable-variables. See #27881 for full list of changes.
    • Eliminate use of extract() within WordPress. #22400
    • Fix curly quotes around numbers when applicable. [28721] #8775
    • Only include relevant post authors in WXR exports. [28731] #20206
    • Append the date to $wp_version in the build output, for nightly packages. [28611] #26751.
    • Update wp_insert_comment() and wp_new_comment() with a check for successful database insert. [28672] #28254
    • Use get_pages() instead of a raw SQL query in get_body_class(). [28696] #28159
    • Pre-populate the selected URL or mailto:<email-address> when “Insert/edit link” is clicked. [28705] #19992
    • Live update the menu item title when the user is editing the “Navigation Label” field. [28707] #23076
    • Deprecate get_all_category_ids(). Suggest get_terms() as a replacement. [28679] #21200
    • Deprecate like_escape() and replace with $wpdb->esc_like(). [28711] #10041
    • Redirect edit.php?post_type=attachment to upload.php to avoid an empty list table. [28729] #27951

    Formatting

    TinyMCE:

    • Update TinyMCE to 4.0.28. [28606] #28391, #27941
    • In iOS, fix placing the caret at the bottom of longer posts when the keyboard is open and disable resizing on switching editors and on show/hide of the kitchen sink row. [28626] #28242
    • Fix problems with undo/redo after resizing an image several times. [28614] #28389
    • Fix saving the editor content on switching from Visual to Text. [28576] #28353

    Thanks to @aaroncampbell, @adamsilverstein, @alexander.rohmann, @aliso, @atimmer, @avryl, @azaozz, @boonebgorges, @bramd, @celloexpressions, @clifgriffin, @coffee2code, @danielhuesken, @DavidTheMachine, @DeBAAT, @donncha, @DrewAPicture, @eddiemoya, @edwin-at-studiojoyo.com, @ericlewis, @filosofo, @frank-klein, @Funkatronic, @garhdez, @gauravmittal1995, @gcorne, @georgestephanis, @ghost1227, @grahamarmfield, @harrym, @helen, @iamtakashi, @iljoja, @issuu, @ixkaito, @jackreichert, @JanHenkG, @Jayjdk, @jdgrimes, @jeffstieler, @jeremyfelt, @jesin, @jgadbois, @jjeaton, @jkudish, @joedolson, @johnbillion, @johnjamesjacoby, @johnzanussi, @jtsternberg, @kitchin, @knutsp, @kovshenin, @kpdesign, @kraftbj, @kurtpayne, @kwight, @lancewillett, @lessbloat, @markoheijnen, @mdbitz, @MikeHansenMe, @mikemanger, @miqrogroove, @mrmist, @MuViMoTV, @nabil_kadimi, @nacin, @nd987, @Nessworthy, @netweb, @niallkennedy, @ocean90, @obenland, @pdclark, @pento, @purzlbaum, @rclations, @redsweater, @ruudjoyo, @schoenwaldnils, @scribu, @senlin, @SergeyBiryukov, @sharonaustin, @shaunandrews, @simonwheatley, @sixhours, @slimndap, @solarissmoke, @tar.gz, @tillkruess, @topher1kenobe, @torresga, @UmeshSingla, @winterDev, @wonderboymusic, @wpsmith, @zamfeer, and @duck_ for their core contributions!

    Thanks to @swissspidy & @designsimply for their help with compiling this post.
    Revisions covered: [28528] to [28757]. For the complete list of commits to trunk, check out the log on Trac.

    Interested in joining in? Write or test a patch for 4.0.

     
  • Simon Wheatley 2:04 pm on June 12, 2014 Permalink | Log in to leave a Comment
    Tags: ,   

    In yesterday’s Weekly Developer Chat, various minor schema change tickets were discussed. We would want to address any changes in as efficient a fashion as possible, and have discussed using the pre_schema_upgrade() function rather than dbDelta(), so we can control the queries more precisely.

    Below is a list of the tickets discussed yesterday, along with which tables they affect. Please add any questions, concerns, additional tickets, or +1’s for this work in the comments.

    wp_comments

    • comment_author_email #21435 – “wp-includes/comment.php line85 causes slow query due to the non-indexed column” raised by @matsubobo (proposes adding an index to comment_author_email)
    • multiple-column indexes #15499 – “Add an index for get_lastpostmodified query” raised by @simonwheatley (proposes adding an index on post_type, post_status, post_date_gmt and another on post_type, post_status, post_modified_gmt)

    wp_options

    • option_name #13310 – “Extend option_name to varchar(255)” raised by @scribu

    wp_posts

    • post_name #10483 – Increase field length from 200 to 400. #21212 – Reduce index length to 191 for InnoDB.
    • guid #18315 – “Add an index to the GUID column in the posts table” raised by @alexkingorg
    • post_password – #881 – “Lengthen password field for protected posts” raised by @ScytheBlade1

    wp_terms

    • slug #22023 – “Remove UNIQUE for slug in wp_terms” raised by @nacin (related). #16230 – Increase field length from 200 to 400. #21212 – Reduce index length to 191 for InnoDB

    wp_term_taxonomy

    • modify existing index #5034 – “Impossible to have duplicate category slugs with different parents” raised by @snakefoot (proposes adding an index on term_id, taxonomy, parent)
     
  • Mike Schroder 8:23 am on March 5, 2014 Permalink
    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.

    Editor

    • 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.

    Templating

    • 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

    Internals

    • 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
    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):

            Themes

            • 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

      Finally.

    • 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.

      (+1)

    • 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
    Tags:   

    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
    Tags:   

    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.

      http://replay.waybackmachine.org/20100527203256/http://wordpress.org/about/roadmap/

      • 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
    Tags:   

    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

          Agreed.
          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

      Cheers,
      Jarkko

    • 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:

    http://core.trac.wordpress.org/ticket/14170#comment:30

     
    • 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

          @scribu:

          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:

          http://wpdevel.wordpress.com/version-3-1-project-schedule/

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

          A.

          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

          B.

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

          C.

          [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

      Hello,
      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

      • 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 :)

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