Week in Core, August 9 – 16, 2016

Welcome back the latest issue of Week in Core, covering changes [38239-38274]. Here are the highlights:

  • 35 commits
  • 38 contributors
  • 73 tickets created
  • 7 tickets reopened
  • 52 tickets closed
  • WordPress 4.6 released 🎉

Ticket numbers based on trac timeline for the period above. The following is a summary of commits, organized by component.

Code Changes

Bootstrap/Load

Build/Test Tools

  • Build/Test Tools: Ensure PHP 7.1 is tested on Travis.[38273] #37625

Export

External Libraries

General

Help/About

Import

  • Update/Install error messages: do not escape from the template, escape the error message string before inserting it. [38240] [38241] #37623
  • Correct the documentation for the get_sample_permalink filter, and improve the documentation for the get_sample_permalink() function. [38272] #37682

Post Thumbnails,Post Thumbnails,Post Thumbnails

Script Loader

  • Fix protocol-relative URLs for the preconnect relation type. Props azaozz for review. [38255] #37652

Upgrade/Install

Users

Thanks to @afragen, @azaozz, @azaozz for testing and second sign off, @Clorith, @dd32, @dd32 for review, @dimadin, @DrewAPicture, @DrewAPicture for review, @flixos90, @helen, @hugobaeta, @Ipstenu, @ipstenu for research, @jeremyfelt, @jerrysarcastic, @JerrySarcastic, @joemcgill, @johnbillion, @johnpgreen, @jorbin, @macmanx, @MattyRob, @ocean90, @pento for review, @peterwilsoncc, @petya, @Presskopp, @RoseAppleMedia, @rosso99, @sebastian.pisula for the original patc, @SergeyBiryukov, @stephenharris, @swissspidy, @theMikeD for the initial patch, @voldemortensen, @westi for investigation, and @wonderboymusic for their contributions!

#4-6, #week-in-core

Week in Core, Jan. 19-26 2016

Welcome back to the latest issue of Week in Core, covering changes from January 19th – January 26th, 2016, changesets [36351-36406]. Here are the highlights:

  • 55 commits
  • 44 contributors with props
  • 99 tickets created
  • 10 tickets reopened
  • 86 tickets closed

Ticket numbers based on trac timeline for the period above.

Note: If you want to help write the next WordPress Core Weekly summary, check out the schedule over at make/docs and get in touch in the #core-weekly-update Slack channel.

Code Updates

Accessibility

  • Improve the focus style on the Credits screen. Leads and contributing developers will now look nicer when focused. Also, combines adjacent image and text links for the same resource thus simplifying markup and reducing noise for screen reader users. [36406] #34953
  • Accessibility: Improve the color contrast ratio replacing the residual occurrences of the #777 gray. Uses the existing #72777c on white backgrounds and the new #555d66 “dark medium gray” on darker backgrounds. [36396] #35605
  • Fix the color contrast ratio in the login screen. [36395] #31548
  • Remove title attributes from the Menus screen. [36379] #35374

Cache API

  • Pass $clean_taxonomy param to ‘clean_term_cache’ action. [36399] #35611

Comments

  • Fire an action after a comment is removed from object cache. When a comment is removed from the object cache, the clean_comment_cache action is now fired. This provides plugin and theme developers a chance to perform secondary cache invalidation as needed. [36405] #35610
  • In comments list table, $post_id should default to false rather than 0. [36387] #35090
  • Allow comment query results to be limited to comments with comment_post_ID = 0. [36381] #35090
  • Ignore hierarchy in pagination calculation when comment threading is disabled. Merges [36275] to the 4.4 branch. [36362] #8071, #35419
  • Respect all post-related filters in WP_Comment_Query. Merges [36326] to the 4.4 branch. Fixes #35478. [36361] #35478
  • Use the post-filter WHERE clause when querying for comment descendants. Merges [36277] to the 4.4 branch. Fixes #35192. [36357] #35192
  • Always respect $comments array passed to wp_list_comments(). Merges [36276] to the 4.4 branch. [36356] #35175, #35356
  • In comments_template(), don’t run hierarchical queries if comment threading is disabled. Merges [36226] to the 4.4 branch. [36353] #35378

Customizer

  • Use “(Untitled)” as site title if blogname is empty. Fixes #35579. [36388] #35579
  • Add shift-click on nav menu items in preview to focus on corresponding nav menu item controls in pane. [36383] #32681
  • Hide help toggle button in panel when no description is supplied. This aligns with the .customize-panel-description element which is also excluded if there is no description. [36374] #35540
  • Fix click.preview event handler for jump links and shift+clicks in preview. Fixes #26005. [36371] #32681, #26005
  • Prevent erroneously directing user to login screen when closing. Fixes #35355. [36363] #32637, #35355
  • Respect custom pagination params when using wp_list_comments() in a query loop. Merges [36324] to the 4.4 branch. [36360] #35402

Documentation

  • Correct return value for is_allowed_http_origin(). [36398] #35607
  • Clarify that mu-plugins can’t be “active” in docs. [36397]
  • Fix parameter documentation ordering in the hook docs for the register_taxonomy_args filter. [36391] #32246

Editor

  • TinyMCE: add inline link dialog. First run. Links the advanced button to the “old” dialog for now. [36384] #33301
  • TinyMCE: remove the srcset and sizes attributes (if any) after replacing or editing an image. [36376] #35434

Emoji

  • Work around a mod_security rule which prevents pages with 4 or more instances of String.fromCharCode( from being served. [36359] #35412

I18n

  • Add the text domain to translate_nooped_plural() calls as well. [36390] #34126
  • Add a test for the add-textdomain.php script. [36389]

Media

  • In _wp_handle_upload(), move ending brace to a new line. [36373] #35565
  • When reusing the initial values from the global MediaElement config object, the config object should first be cloned. Objects in JS are references that will retain any changes. Fixes #34152. [36364] #34152

Multisite

Plugins

  • Pass data consistently on plugin, network plugin, and network theme screens. [36394] #35335

Query

  • Respect ‘suppress_filters’ when filtering search-related SQL. [36404] #35594
  • Introduce $comment_status and $ping_status params for WP_Query. [36403] #35601
  • Avoid invalid SQL when building ORDER BY clause using long search strings. Merges [36251] to the 4.4 branch. Fixes #35361. [36354] #35361

Quick/Bulk Edit

  • Remove a no more used jQuery loop for unsupported post formats. See #24096. [36375] #23426, #24096, #35564
  • On the Taxonomies screens, prevent a page reload when pressing Enter on a focused field. Merges [36260 to the 4.4 branch. [36355] #35401

Posts, Post Types

  • Allow is_post_type_viewable() to accept a post type name. Previously, it accepted only a post type object. [36402] #35609
  • Add tests for is_post_type_viewable(). [36401] #35609

Taxonomy

  • Populate term cache with proper clone of term objects. Merges [36323] to the 4.4 branch. [36358] #35462

Themes

  • Themes: Enhance filtering options for allowed themes on a network. [36366] #28436

TinyMCE

  • Update to 4.3.3. Update the QUnit tests and revert back to testing the non-minified files in /src. [36352] #35539

Upgrade/Install

  • Switch the locking mechanism to using static methods so that it can be accessed from other upgrade-classes. [36370] #34878

Widgets

  • Show the “Clear Inactive Widgets” button only after the sidebar with inactive widgets. Merges [36326] to the 4.4 branch. [36369] #35447

Props

Thanks to @5um17, @afercia, @azaozz, @berengerzyla, @birgire, @boonebgorges, @chandrapatel, @chriscct7, @danielbachhuber, @dd32, @dmsnell, @dotancohen, @drebbitsweb, @DrewAPicture, @ericlewis, @Fab1en, @firebird75, @Frozzare, @georgestephanis, @iseulde, @ivankristianto, @jeremyfelt, @jmdodd, @johnjamesjacoby, @johnnypea, @kraftbj, @lamosty, @luciole135, @MattGeri, @michalzuber, @mrahmadawais, @obenland, @ocean90, @pauldewouters, @rob, @salvoaranzulla, @scarinessreported, @SergeyBiryukov, @spacedmonkey, @tahteche, @walbo, @westi, @westonruter, and @wonderboymusic for their contributions!

#4-5, #week-in-core

Dev Chat Summary, February 4th

Agenda

https://make.wordpress.org/core/2015/02/04/dev-chat-agenda-february-4-2015/

Chat Archive

https://wordpress.slack.com/archives/core/p1423083640001782

Decisions, Announcements

  • @drew will lead a NUX working group during the 4.2 cycle. The first chat will be held in #core-flow next Tuesday at 19:00UTC / 2:00 pm EST.
  • @ryan (hey, that’s me) will attempt to be UX lead for 2015. 🙂

Assignments

Links Mentioned

https://make.wordpress.org/core/2015/02/03/new-lead-developers-helen-and-dion/

Screen Shot

https://github.com/MichaelArestad/Press-This/issues

https://core.trac.wordpress.org/ticket/29820

https://core.trac.wordpress.org/ticket/12696

https://core.trac.wordpress.org/ticket/29820#comment:43

https://make.wordpress.org/core/2015/01/26/customizer-transactions-proposal/

https://github.com/xwp/wordpress-develop/pull/61

https://core.trac.wordpress.org/ticket/30988

https://core.trac.wordpress.org/ticket/30936

https://core.trac.wordpress.org/ticket/30937

https://core.trac.wordpress.org/ticket/28599

https://core.trac.wordpress.org/ticket/26504

https://core.trac.wordpress.org/ticket/29079

https://core.trac.wordpress.org/ticket/30589

https://core.trac.wordpress.org/ticket/21616

https://core.trac.wordpress.org/ticket/18946

https://make.wordpress.org/core/2015/02/04/new-chapters-for-ryan-and-westi/

https://www.openhub.net/p/wordpress/contributors?query=&sort=commits

Continue reading

#meeting

New chapters for Ryan and Westi

WordPress lead developers Ryan Boren (@ryan) and Peter Westwood (@westi) started contributing to WordPress more than a decade ago. Ryan and Peter, along with Mark and Matt, served as the foundation for much of the early years.

For some time now, Ryan and Peter have avoided weighing in on technical matters. Very simply, when you aren’t able to be active in development, you know you’re not up to speed, and you realize your words shouldn’t carry the weight that they do. Being able to make this judgment is one of the things that makes both of them such great leaders.

We’ve all been there, at least for particular features or releases. It’s worth noting, for example, that my own time on core has been cyclical for years, as sometimes I end up working full time on the security team, maintenance releases, the WordPress.org site, or related projects.

The great thing is, there are a lot of fantastic developers who have stepped up over the last few years to seamlessly fill in the huge holes they’ve left. Some of that culminated in promoting Helen and Dion to lead developer yesterday, and my own promotion three years ago.

When I started contributing, I received a lot of advice and learned a lot from both of them. Peter reviewed a lot of my code and was the guy who would revert my code when I broke something. 🙂 Ryan became my mentor and pushed me to become the engineer I am today.

And so, it is with mixed emotion I share that Ryan and Peter have stepped down as lead developers.

Peter will be moving into a dormant/inactive/emeritus status. We hope to have him back when his life and work allows. In the meantime, you may see him committing a bug fix here and there, as he is wont to do.

Ryan has been focusing all of his energy on improving UX for more than a year, especially for mobile and touch devices, and especially for workflows like media management. So I’m pleased to say he’ll continue to do that: Ryan will be spearheading UX for WordPress in 2015. It’s been a while since we’ve had someone truly focusing on just UX, so this is really exciting.

Along with yesterday’s announcement, the active lead developers are @markjaquith, me, @azaozz, @helen, and @dd32.

Please join me in congratulating Ryan and Peter on an epic run. 🙂

The email used for notifications on Trac is…

The email used for notifications on Trac is currently specified in Trac preferences. I’m changing this to pull automatically from your WordPress.org profile. After this change, there will not be a way to have a separate email address for Trac and any manually specified email address will be overridden.

We need to make this change because, very simply, it’s a better user experience. By killing this extra user preference, it’s one less step users need to set up in order to receive notifications. (And a tighter feedback loop could possibly boost engagement.)

That will affect about a thousand users we have in the system, probably incidentally for most. But, about 50-100 users might have been deliberately declaring a separate email address; for example 50 users had “trac” appear specifically in their email. Even without a dedicated email, it is trivial to filter Trac emails; you just might need to make some adjustments.

As you may have noticed, this is part of a series of changes I’ve been making to Trac. I’ll be doing a summary post in a few days outlining everything that has changed.

NOTE: This does not affect wp-trac@lists.automattic.com. If you subscribe to the “firehose” this is not affected.

Edit, 20:23 UTC. This is now enabled. For the moment, the email address will sync when you next visit Trac. Please find me if you have any questions.

#housekeeping, #trac

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.

#3-9, #commit

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.

#post-types, #roadmaps, #taxonomy

Code Revisions: Week 1

My initial post did get quite some feedback – not overall good. I expected the negative feedback. I did not take part in the discussion, but I think others did a nice job there (thanks Jen & Aaron). Also thanks to the developers who offered to give support when I might get stuck.

To make it short:  I already prepared myself for this project before the official coding phase started and could skip the initial “warm up phase”. At the moment I am ahead of the timeline.

This week mostly was on the connection between a file and a post (#284), the initial creation of a post when a file is edited for the first time (#285) and the updating of the corresponding post on every edit (#287). I also chatted with my mentors about the brought up security worries. We will definitely look into those and discuss them (and possible solutions) with lead developers – the code resulting from this project will not make it into core if it introduces security flaws!

The next week will be about viewing code revisions. This on the one hand includes a revisions list which needs to be added below the editors (#286) and on the other hand fixing possible problems with the revisions view on revisions.php (e.g. #289). I will take the negative feedback as a challenge and still hope to get code revisions into core. Till next week then.. Comments are open!

#code-revisions, #weekly-update

Revisions Update, 2/11

As has been the case for many sessions now, Monday’s revisions office hours focused on changes to the UI. @karmatosed provided new mockups, influenced by a thread on the Accessibility blog. @adamsilverstein also posted a series of patches on #23396 that begin to implement the general direction we’ve chosen for UI updates (aside: we’ll do our best to keep future mockups on this ticket, for easier discovery; until now, most have been posted in the comments on these update threads). We are certainly approaching a consensus on the new design, but have held off on any significant UI-specific coding until we’re confident that our efforts won’t be wasted.

Beyond UI, there are patches on three tickets that could use testing: #16215, #22289, and #19932. @adamsilverstein and @westi are working on unit tests, which should help move the patch review along.

We should have new mockups to review during tomorrow’s office hours at 1500 UTC in #wordpress-dev.

[IRC log]

#3-6, #revisions

Editorial Flow Update, 2/7

Editorial flow is making progress and hitting interesting questions to answer. Our two primary tickets right now are #12706 and #23314.

For the first, we’re waiting on feedback on the approach from @nacin. Once we’ve gotten confirmation it’s the right direction, I’ll continue working to make the patch commit-ready.

For the second, the biggest question was how we should handle revisions for post meta and taxonomy terms. In the interest of getting to a committable patch, we’ll be dropping post meta / custom taxonomy support in favor of just being able to stage edits for the title and body content. Furthermore we’ve decided it would be worthwhile to add a new post type property so this functionality is opt-in. Posts and Pages in core will receive this by default.

Our primary goals are to have commit-ready patches for both tickets by the beginning of next week. Konstantin’s secondary goal is to chat with @westi and @ethitter and see whether revisions for post meta is within scope for 3.6. My secondary goal is to go through other editorial flow tickets and touch base with where each is at.

Next office hours are Tuesday, February 12th at 10 am PT / 1 pm ET / 1800 UTC.

Office hour log

#3-6, #editorial-flow