WordPress.org

Make WordPress Core

Updates from July, 2015 Toggle Comment Threads | Keyboard Shortcuts

  • George Stephanis 12:09 pm on July 24, 2015 Permalink |
    Tags:   

    Two Factor Meeting Recap 

    Next week’s meeting will be on July 30th, 2015 at 17:00 ET — two hours later than this week’s meeting, to try and not drop it at 4am for some of our people.

    Log: https://wordpress.slack.com/archives/core-passwords/p1437678027000327

    Folks in attendance:

    @georgestephanis
    @bjornjohansen
    @swissspidy
    @stevenkword
    @aaroncampbell
    @jeffmatson
    @extendwings
    @cconover
    @julien731
    @deltafactory
    @tomdxw
    @valendesigns

    Reviewed rough plans with authentication provider classes and who is working on each. @julien731 has a wealth of experience with TOTP and @extendwings with U2F, and will likely be helping with each respectively.

    I’m expecting to have the fallback methods branch finished and merged in by EOD today or tomorrow. At that point, it will likely need some design love, as it will need to account for three different things — what the user’s primary provider is, what providers the user has enabled, and configuring providers. For the moment we’re going for functionality over design, so it’ll just be checkboxes for available, radio button for primary, and letting each provider handle configuration.

    Added @valendesigns and @stevenkword as committers on the repo.

     
    • CotswoldPhoto 6:39 pm on July 24, 2015 Permalink | Log in to Reply

      I am hoping to use the Google one (I currently use the one written by Henrick Schack together with the Per User Prompt written by Ian Dunn), so I hope it has a lazy code option (allow codes +/- time error) as the time window on the standard version is too tight for many servers to be accurate to. Also, for security reasons, I hope the system uses a per user prompt; the standard WP login box at first, if user and pw are correct, a new box appears to prompt for the 2FA code. Errors returned (to hacking bots) do not reveal that 2FA is active for that user.

  • Scott Taylor 8:55 pm on January 28, 2015 Permalink  

    Trac Tickets – the band’s taking requests 

    At the beginning of the past few releases or so, we’ve put a call out for community priority tickets. There are over 3000 tickets in Trac. If there’s a ticket you feel is neglected or should have light shined upon it: leave a comment here with a link so we can triage it. Help us help you.

     
  • Pascal Birchler 8:21 pm on October 29, 2014 Permalink
    Tags: ,   

    WordPress Core Weekly 

    Hi everyone!

    It’s this time of the week again: WordPress Core Weekly is here. This updates covers all commits since last week up to to today, October 29th.

    In case you missed it, the new default theme, Twenty Fifteen, is coming along very well, the feature plugins planned for 4.1 are being tested extensively and the Customizer JavaScript API is getting more and more complete.

    But there are many more things going on behind the scenes and Core has even passed revision [30,000]! Let’s have a look at this week:

    Admin

    • Add labels to the Personal Options input fields on the user profile editing screen. [30027] #30101
    • Editor: Use <button> instead of <a> for the Visual/Text buttons, make them focusable. [30002] #27553
    • Customizer: Add the ability for a customizer control to render its controls via a JavaScript template. Switches the default color picker control to a JavaScript template. [30014] #29572

    Themes

    • Twenty Fifteen: If the sidebar is taller than the viewport scroll it with the content, if it’s shorter keep it fixed. [30025] #29979
    • Introduce a new means of outputting a <title> tag in the theme head. Requires a theme to add support by calling add_theme_support( 'title-tag' ). [30074] #18548
    • Introduce some new template functions for navigation [30065] #29808
      • get_the_post_navigation() and the_post_navigation() for navigation to the next and previous post.
      • get_the_posts_navigation() and the_posts_navigation() for navigation to the next and previous page of posts.
      • get_the_pagination() and the_pagination() for paginated navigation between pages of posts.
      • Uses paginate_links(). This reduces the need for themes to define their own sets of navigation functions.

    Internals

    • Deprecate admin_created_user_subject() [30005] #29915
    • Introduce an edit_form_before_permalink action which gets fired after the title field but before the permalink fields. [30028] #29691
    • In wp_link_pages(), only output link separators between actual pagination links. [30030] #24940
    • Rename _wp_password_hint() to _wp_get_password_hint() to bring it inline with core terminology. [30033] #21243
    • Don’t add sticky class in get_post_class() if ignore_sticky_posts query var is set. [30036] #18035
    • Don’t display Standard post format twice in the meta box if the theme unnecessarily mentions it in the add_theme_support() call. [30038] #16555
    • Add comment_reply_link_args filter for get_comment_reply_link() arguments. [30039] #10569
    • Allow slug param of get_terms() to accept an array. [30042] #23636
    • Introduce orderby=include support for get_terms(). [30052] #23261
    • Remove UNIQUE key from slug column of terms table. [30056] #22023
    • Add wp_json_encode(), a wrapper for json_encode() that ensures everything is converted to UTF-8. Change all core calls from json_encode() to wp_json_encode(). [30055] #28786
    • Introduce wp_is_trusted_network(). A first step to establish concepts around trusted and untrusted networks. [30071] #30145
    • Don’t hardcode height for videos – this was a workaround for MediaElement internals causing problems. Responsive videos now work properly and don’t cause extra whitespace. [30082] #30078
    • Introduce some actions and filters which aid plugins in revisioning post meta. [30091] #20564

    Queries

    • Allow ORDER BY in WP_Comment_Query::query() to be disabled. [30004] #29902 DisableORDER BY by passing boolean false, an empty array, or the string none to the orderbyparameter. This mirrors the behavior of WP_Query.
    • Accept orderby=include in WP_User_Query. [30016] #30064 This lets the results of a user query be sorted manually by the value of the include param.
    • Fix count in WP_Comment_Query when using meta_query. [30026] #23369
    • Optimize site query when performing network database upgrades [30029] #30097
    • Improve WP_Tax_Query param sanitization for empty strings. [30031] #30117
    • Support multiple status values in WP_Comment_Query. [30084] #29612

    Thanks to @peterwilsoncc, @iamtakashi, @nacin, @mnelson4, @afercia, @psycleuk, @rianrietveld, @davidakennedy, @celloexpressions, @DrewAPicture, @jipmoors, @ipm-frommen, @mattwiebe, @avryl, @heshiming, @desaiuditd, @ankit-k-gupta, @captaintheme, @marcosf, @obenland, @tmtrademark, @briandichiara, @tareq1988, @jakub.tyrcha, @johneckman, @kosvrouvas, @ptahdunbar, @nacin, @pushplaybang, @joedolson, @aaroncampbell, @jfarthing84, @dlh, @danielbachhuber, @wpsmith, @hotchkissconsulting, @JustinSainton, @jwenerd, @wonderboymusic, @tollmanz, @chrisbliss18, @joostdevalk, @TobiasBg, @nofearinc, @karpstrucking, @ebinnion, @boonebgorges, @mattheu, @adamsilverstein, @momo360modena, @tareq1988 for their core contributions!

    Revisions covered: [29995] to [30093]. 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.1.

     
  • Mike Schroder 6:03 am on June 19, 2014 Permalink
    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.

     
  • Helen Hou-Sandi 2:48 am on May 9, 2014 Permalink
    Tags: ,   

    Summary of 5/7 dev chat (IRC log):

    Proposed 4.0 ideas

    • Multisite enhancements: SSL, get site creation/editing UIs in line with the arbitrary domain/path support. Planning on weekly office hours.
    • Mobile experience: media modal and upload flow, Press This feature plugin.
    • oEmbed discoverability, usability, and caching improvements.
    • Widgets: JS API (#28093)
    • Taxonomy roadmap, part one.
    • Background images in the customizer.
    • Plugin installer improvements: better search and more information (needs .org API support), upgrading a plugin or theme via zip upload (#19641)
    • Export API improvements/overhaul (#22435)
    • Post meta: support for revisions (#20564)
    • APIs for posts/comment types/statuses. Ping @nacin if interested in collaborating (#12706).
    • Continuous a11y enhancements, particularly in the media modal.
    • Texturize patches, continuing on performance enhancements and bugfixes in 3.9.

    If you are interested in any of the above, sound off in the comments below.

    Potential themes for the release:

    • More visual cues in the admin for user tasks, as has been done for themes.
    • Continuing to improve the editing and media experiences.
    • Lots of under the hood things and API attention to make devs happy.

    Feature Plugins

    • Front-end Editor looks like it’ll continue past 4.0, as enabled by being a feature as a plugin, but we should continuously keep an eye on it and see what improvements can be brought into core sooner.
    • Media Grid View and Press This are under way.
    • WP API continues to move forward.

    Patches needing early dev attention

    • #17689: Terms should not be sanitized inside term_exists(). This is the first step in moving along with the taxonomy roadmap, so please look here if this has been of interest to you. Potentially needs more unit tests. Thanks to @aaroncampbell for the latest patch.
    • #14759: Improve the way oEmbed deals with caching (patch from @markjaquith).

    And finally, 3.9.1 is out now, if you haven’t already updated or been updated.

     
    • Schwarttzy 5:21 am on May 9, 2014 Permalink | Log in to Reply

      How about featured background images?

    • Florian Girardey 7:51 am on May 9, 2014 Permalink | Log in to Reply

      How about better UI for Header images ?

    • helgatheviking 7:55 am on May 9, 2014 Permalink | Log in to Reply

      More admin filter/hooks everywhere! And love for the quick edit.

    • RicaNeaga 9:49 am on May 9, 2014 Permalink | Log in to Reply

      Here’s what the roadmap looks like for Cpanel, from here… http://features.cpanel.net/responses/as-a-server-administrator-i-want-mariadb-support-so-that-i-can-accomodate-both-innodb-and-noninnodb-users

      ”1. We introduce MariaDB 10 with cPanel & WHM version 11.50

      2. In version 11.50 both MariaDB and MySQL are provided, and wholly supported, by cPanel

      3. With version 11.52 we announce that MySQL is considered deprecated, and will be removed in version 11.54

      4. With version 11.54 we no longer provide the MySQL RPMs.”

      So in ~ a year from now a major web hosting control panel is going to ship without any trace of MySQL. Then why not fully supporting MariaDB (10) in the next major release, 4.0, and include MariaDB (10) as an alternative for MySQL in the requirements page? https://wordpress.org/about/requirements/

      • Andrew Nacin 3:03 pm on May 9, 2014 Permalink | Log in to Reply

        WordPress already supports MariaDB, and has for a long time, since MariaDB is a compatible replacement for MySQL. We could put it in the requirements somewhere but it’s still pretty esoteric at this time.

        • RicaNeaga 5:33 pm on May 9, 2014 Permalink | Log in to Reply

          Thanks for the answer and info. MariaDB 10 however is a combination of MySQL 5.5 and 5.6, and with features of its own, it won’t be a 100% drop-in replacement for either of them (MySQL 5.5 or 5.6).

          So maybe it’s a good idea to make sure everything it’s ok, and put it in the requiremets after that. The sooner the better I think, it would make a statement that the wordpress project is also supporting MariaDB in the long run, alongside Google, CPanel, Plesk, RHEL and other major Linux distros.

          Right now I’m annoyed since I’d like to buy a managed server from Germany, and their control panel supports by default only MySQL and PostgreSQL. ”Spreading the word” about MariaDB hopefully would make others ”embrace the future” sooner :)

    • Jon Brown 4:55 am on May 10, 2014 Permalink | Log in to Reply

      I’m assuming the Metadata API/UI is still too far out to be considered for 4.0, but I’m going to cross my fingers and hope for it anyway: https://github.com/wordpress-metadata/metadata-ui-api/

      • Helen Hou-Sandi 6:39 pm on May 10, 2014 Permalink | Log in to Reply

        I would think of this as more of a working group that also happens to have a particular end goal in mind, and improvements can (and should be) ongoing. That end goal does not seem likely for 4.0 though, no.

    • Robert Chapin 4:03 pm on May 10, 2014 Permalink | Log in to Reply

      #10041 needs early dev attention. Come on guys. If we don’t do this now, the patch will go stale.

    • rajlaksh 7:25 am on May 13, 2014 Permalink | Log in to Reply

      what about categories like tags in new post page? so u have to enter category name then auto complete search :)

      Easy then scrolling 500+ categories.

  • Andrew Nacin 9:26 pm on December 31, 2013 Permalink
    Tags: ,   

    Commit announcements for 3.9 

    Lots of news to share! First: Helen Hou-Sandí has had guest commit for the past three release cycles. She’s been spending the last year reviewing contributions, mentoring contributors, and working on some of our larger UI projects. I’m proud to announce @helen is now a permanent committer to WordPress!

    We’ve invited John Blackbourn (@johnbillion) to be a committer for the 3.9 cycle. His strong, consistent contributions have been backed by excellent judgment and temperament.

    Matt Thomas, who led the dashboard redesign in 3.8 (and 3.2, and 2.7, etc.), will keep his commit to continue to maintain and improve WordPress UI. He’s been a great mentor to many contributing designers and his long-term impact is indelible.

    For the last few years, we’ve been granting commit access on per-cycle basis, sometimes for a particular component, feature, etc. Generally, after about a year, a guest committer can be considered for permanent commit access. Dominik Schilling, Sergey Biryukov, Drew Jaynes, and Scott Taylor have all had their commit extended for 3.9.

    Drew (@DrewAPicture) was given temporary commit for inline documentation starting with 3.7. He’s been heading up the long-running initiative to document every hook in WordPress. Scott (@wonderboymusic) also started committing during 3.7, and has a particular penchant for digging deep into the query and taxonomy APIs. And Sergey (@SergeyBiryukov) and Dominik (@ocean90), well, they are forces of nature.

    (@aaroncampbell was also given guest commit in 3.7, but he ended up not having much time to use it.)

    Here’s a full list of those with permanent commit: @markjaquith, @ryan, @westi, @matt, @azaozz, @dd32, @koopersmith, @duck_, @helen, and me (@nacin); @lancewillett for bundled themes; @iammattthomas for UI. You might have also seen commits before from @josephscott (XML-RPC), @nbachiyski (internationalization), and @mdawaffe (secret weapon for really tricky problems).

    Next weekly meeting is January 8. Happy new year, everyone. Here’s to a great 2014.

     
  • Aaron Jorbin 9:10 pm on September 13, 2013 Permalink
    Tags: ,   

    JavaScript Unit Tests for Core 

    Recently WordPress added QUnit as a JavaScript unit testing framework and added its first JavaScript unit tests. I thought I would walk through how to run the tests and how to write tests so that we can increase our JavaScript test coverage. All of these are based upon using the develop.svn.wordpress.org checkout which is where the JS unit tests live.
    (More …)

     
    • Ryan McCue 1:37 am on September 14, 2013 Permalink | Log in to Reply

      For anyone who’s wondering what the hell is going on on Windows: You have to run grunt via the Windows command line, and you cannot run it via Cygwin. If you do run it via Cygwin, you’ll see random inexplicable errors and missing output. It’s pretty annoying (in fact, it stops me from using Grunt), but you can’t really do anything about it.

    • adamsilverstein 6:17 pm on September 14, 2013 Permalink | Log in to Reply

      Great post, thanks for keeping this moving!

    • K.Adam White 5:50 pm on September 16, 2013 Permalink | Log in to Reply

      For those on Windows, the “msys” shell that installs as “Git Bash” when you download the official Windows build of Git should work fine once you install the Windows build of Node.

  • Alex 6:00 pm on August 21, 2013 Permalink
    Tags: ,   

    Code Revisions: Week 9 

    Version 0.7 is tagged and I am planning to submit it to the WordPress.org plugin directory later today or tomorrow.

    code-revisions

    Viewing code revisions now feels much more native: By default WordPress makes use of normalize_whitespace() before comparing two posts to one another. This results in loss of blank lines and missing multi-space indention as often seen in css files. I fixed this by plugging into the wp_text_diff() function (#302). Further more you now get the correct menu item expanded when viewing code revisions (#316).

    Besides those I am still struggeling with syntax checking (#335). Looks like I will be settling for just using ‘php -l’ if available. Problem there is I am still not able to get a reliable path to the php binary. Since PHP 5.4 there is the PHP_BINARY constant, so I need a way to get it manually in PHP versions lower than 5.4..

     
    • Aaron D. Campbell 6:20 pm on August 21, 2013 Permalink | Log in to Reply

      You might be able to try PHP_BINDIR and use the most common bin name (php or php.exe). If you really want to go out of your way, you could check the whole path for the binary using something like https://gist.github.com/aaroncampbell/6294506 but I don’t really think that’s necessary assuming that PHP_BINDIR is pretty common. Past that, just fail gracefully

    • Bryan Petty 6:36 pm on August 21, 2013 Permalink | Log in to Reply

      Yeah, I tend to agree with @aaroncampbell. Not so much worried about automatically finding it as much as just making it possible to manually define it within wp-config.php if necessary.

    • Andrew Nacin 6:48 pm on August 21, 2013 Permalink | Log in to Reply

      We seem to do okay without using the binary in terms of sandboxing plugins and showing any syntax errors.

  • 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! 😀

    • 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” (https://wordpress.org/plugins/taxonomy-metadata/) in a project; also “Meta for taxonomies” (https://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.

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

    WordPress 3.6: Autosave and Post Locking 

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

    Things this will likely involve:

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

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

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

      +1!

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

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

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

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

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

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

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

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

      Huge +1.

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

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

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

      i’m interested in helping if i can

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

      omg. yes.

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

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

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

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

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

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

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

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

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

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

      Excellent.

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

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

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

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

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

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

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

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

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
Skip to toolbar