Week in Core, March 22nd – 28th, 2017

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

  • 41 commits
  • 27 contributors
  • 76 tickets created
  • 14 tickets reopened
  • 65 tickets closed

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

Code Changes

Administration

  • List Tables: After [38703], [38706], and [40118], adjust the jQuery selector to make the selection of a range of checkboxes work again. [40327] #40056
  • Docs: Add description for $mode global in WP_MS_Sites_List_Table and WP_MS_Users_List_Table. [40310] #40208
  • Docs: Add description for $mode global in WP_Media_List_Table and WP_Posts_List_Table. [40309] #40208
  • Docs: Add missing @global entry for list table view mode in WP_Screen::render_view_mode(). [40308] #40208
  • Docs: Add missing @global entry for list table view mode in wp_ajax_inline_save(). [40307] #40208

Bundled Theme

  • Twenty Seventeen: Declare jQuery as a dependency for navigation.js. [40315] #40224
  • Twenty Seventeen: Use esc_attr_e() for translatable strings in HTML attributes. [40311] #40216

Cache API

Customize

Database

  • Tests: Use utf8mb4 max index length when creating keys. [40339] #35958

Formatting

  • Docs: Correct default value in @param entry for the $num_words parameter of wp_trim_words filter. [40322] #40248

Login and Registration

  • Avoid a potentially incorrect value for the cookie hash on multisite installations that don’t have a value in the siteurl network option. [40320-40321] #34084, #39497

Networks and Sites

  • Multisite: Respect $_wp_suspend_cache_invalidation when clearing network and site caches. [40346] #40028
  • Multisite: Allow falsy properties to be cached in site-details. [40344] #40247
  • Tests: Clarify zero path segment tests for get_network_by_path(). [40342] #37217
  • Multisite: Add lang_id support to WP_Site_Query. [40340] #40196
  • Multisite: After [40305], rename clean_site_details_cache() method as it’s not really private. [40333] #40063
  • Multisite: Add further unit tests for get_blog_details(). [40317] #40228, #40180

Posts, Post Types

  • Add missing REST API properties to WP_Post_Type class. [40329] #39986

REST API

  • Tests: Consolidate logic used to skip API fixture generation. [40341] #40041
  • Confirm the parent post object of an attachment exists in WP_REST_Posts_Controller::check_read_permission(). [40337] #39881
  • Add gmt_offset and timezone_string to the base /wp-json response. [40336] #39854
  • Use get_gmt_from_date() when preparing a draft post for response. [40324-40325] #40136

Taxonomy

  • Add missing REST API properties to WP_Taxonomy class. [40328] #39987

Themes

  • Fix incorrect annotation for __clear_multi_author_cache() function. [40334] #40063, #40262
  • Add filter for excluding directories from being scanned for template files. [40326] #38292

Users

  • Don’t push the current user’s role to the top of the list in wp_dropdown_roles(). [40323] #40162

Thanks to @afercia, @aussieguy123, @bor, @bor0, @caseypatrickdriscoll, @chesio, @clarinetlord, @danielbachhuber, @dd32, @dlh, @flixos90, @GhostToast, @jeremyfelt, @johnbillion, @johnjamesjacoby, @lukasbesch, @michelleweber, @nerrad, @ocean90, @priyankabehera155, @rachelbaker., @redrambles, @sagarkbhatt, @SergeyBiryukov, @swissspidy, and @westonruter for their contributions!

#week-in-core

Week in Core, March 8th – 14th, 2017

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

  • 53 commits
  • 22 contributors
  • 101 tickets created
  • 12 tickets reopened
  • 48 tickets closed

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

Code Changes

Administration

Build/Test Tools

  • Tests: Use https URLs for wordpress.com assets in Tests_HTTP_Functions and Tests_Image_Functions. [40289] #31091
  • Update .travis.yml to include latest improvements from trunk. [40288] #35105, #40100, #30755, #36291, #36490
  • Switch to Node 0.12.18 when testing the 4.2 branch. [40285] #35105
  • Allow Travis CI to cache the node_modules directory. [40280-40281] #36291, #36490
  • Build/Test tools: Get Travis builds working on HHVM again. [40274] #40100
  • Build/Test tools: Don’t install PHPUnit on the travis:js builds. Saves a couple of minutes of build time. [40273] #40100
  • Build/Test tools: Switch to Node 4.7.2 when testing the 4.5 branch. [40266] #35105
  • Build/Test tools: Don’t override the wp_set_auth_cookie() and wp_clear_auth_cookie() functions. [40265] #39367
  • Docs: Remove the duplicate hook documentation for the newly introduced send_auth_cookies filter. [40264] #39367
  • On Travis CI install and use the node version which is specified in package.json. [40258] #35105
  • Build/Test tools: Account for PHP 5.2 when using Composer to install PHPUnit. [40257] #39822, #40086
  • Build/Test tools: Explicitly use PHPUnit 5.7 for the PHP 7 builds on Travis. [40255] #39822, #40086
  • Build/Test tools: Remove the unnecessary clone of the twentysixteen repo. [40253] #31550, #40066
  • Build/Test tools: Revert [40239] due to unrelated changes. [40240] #39486

Bundled Theme

  • Twenty Seventeen: Correct grammar in ‘Page Layout’ control description. [40270] #40107

Canonical

Date/Time

  • Docs: Correct @return type for calendar_week_mod(). [40254] #40077

Media

  • Improve wording of the AYS warning when permanently deleting uploads, tags, posts. [40283] #39712

Misc

  • Build/Test tools: Don’t attempt to report PHP’s extensions when running HHVM jobs on Travis. It doesn’t work. [40267] #
  • Build/test tools: Add some more debugging to Travis and bring the format of the Xdebug fix inline with branches. [40259] #
  • Updates for 4.6. Merge of and to the 4.6 branch.

Query

  • Tests: Use assertSame() for WP_Query ‘orderby’ tests. [40278] #38034

REST API

Taxonomy

  • Fix the formatting of $taxonomies parameter of 'wp_get_object_terms' filter. [40290] #40154
  • Don’t run ‘get_terms’ filter when querying for terms within get_term_by(). [40275] #21760

Themes

  • Docs: Correct the description for wp.updates.deleteTheme. [40279] #40110

Widgets

  • Customize: Show title input placeholders for widgets that have default titles when rendered. [40251] #39909

Thanks to @afercia, @azaozz, @boonebgorges, @bor0, @dingo_bastard, @dlh, @dllh, @gma992, @ig_communitysites, @jnylen0, @johnbillion, @joostdevalk, @jorbi, @lancewillett, @laurelfulford, @MattyRob, @netwe, @netweb, @ocean90, @SergeyBiryukov, @westonruter, and @zoonini for their contributions!

Dev Chat Summary: March 1st (4.7.3 week 5)

This post summarizes the dev chat meeting from March 1st (agendaSlack archive).

4.7.3 Schedule

  • Reminder of plan to release 4.7.3 as bugfix and maintenance release on Monday March 6, 2017
  • RC is available so please test

Community Summit

  • Working to review submissions on Planning for Community Summit 2017 post on Make/Core as well as submissions to the Make/Summit team via the Community Summit 2017: Sign-up Request post
  • Between now and Friday, March 5th the Core team needs to come up with:
    • 1) a list of topics for the summit
    • 2) A list of representatives to attend the Community Summit
    • 3) One or two contributors who are willing to help with the organization of the event
  • “participating” generally means being physically present for the discussions in Paris, France days prior to WCEU this summer for the Community Summit
  • Each topic facilitator will do both a pre-summit and post-summit Make/Core post. @jbpaul17 to confirm timelines with @_dorsvenabili to help prep those facilitators for those post timings.
  • Javascript in core [will submit to CS]
    • “what we hope and imagine for the future with the REST API, and how we hope to get there… what we have in core now and how we can improve it and how we can attract more JavaScript first developers to build on WordPress and especially contribute to core… How the REST API relates to wp-admin.” Submitted by @adamsilverstein to attend and volunteer to help in whatever role is most helpful.
    • “REST API admin usage: Where we can start moving things to using the API (and maybe even get a couple of them done at the summit)” Related submission from @chriscct7, recommended to include @rmccue
    • @kadamwhite: A heavy dependency on “the future of JS in core” and that discussion should originate from the broader WP community, not be mandated by the REST API group
  • Technology version support policies [will submit to CS]
    • @jorbin: (versions of PHP, MySQL, Browsers, Screen Readers, other AT, etc.) Let’s come up with some concrete plans for when we intend to deprecate things and how we want to handle it. People Who would be good to have in this discussion: @dd32 (to help with stats) @pento (to help with messaging) @afercia and @rianrietveld ( to help formulate AT support policies if they don’t exist already), @westonruter ( as maintainer of the largest JS component) @azaozz ( as maintainer of tinyMCE component) @matveb ( as dev lead of new editor)
    • @getsource, @boonebgorges, and @matt as additional reps for this topic
  • Improved management of contributors with time to spare [will submit to CS]
    • @johnbillion: This topic is particularly focused on pre-existing contributors who are paid to contribute to WordPress (eg. those whose time is sponsored by their employers), but also pre-existing contributors who aren’t sponsored but who do want to contribute a significant and/or consistent amount of time, and also potential contributors in a similar position.
      As a project, we need to manage these people’s time much better. These people need to be project managed in one way or another to avoid repeats of situations we’ve had in the past where a contributor is literally being paid to fix things in WordPress and the project is failing to enable them to do so effectively, or even at all. I’d (@johnbillion) like to attend the summit, and I’d be happy to jointly lead this discussion with someone who has good project management experience and some ideas about how WordPress might be able to better manage contributors, but at the same time do it in such a way that retains the fun and interesting aspects of contributing without turning it into something that too closely resembles “work”. [Side note from John: Worth noting that this doesn’t only apply to core, but it’s a good place to start.]
    • @helen did a survey of time availability a while ago, sent list to John to use for this topic
    • @aaroncampbell, @getsource, @jorbin, @boonebgorges, and @logankipp as additional reps for this topic
  • On-boarding experience for new contributors [will submit to CS]
    • @joemcgill: Lots of people who want to get involved have no idea where to focus their efforts.
    • @kadamwhite: Speaking for myself this is hugely related to the future of JS in core and the REST API, since those pieces really need the energy new contribs would bring
    • @getsource: I am willing to participate or lead, although I don’t know what leading it means besides guiding conversation at this point. @aaroncampbell also willing to lead.
    • @peterwilsoncc, @flixos90, @logankipp, @jorbin, @johnbillion, and @stevenkword as additional reps for this topic
  • Communicating changes to WordPress Core [will NOT submit to CS]
    • @jorbin: For the past few years, core has produced a field guide and worked with the meta and plugins team to email plugin others about changes to core. Each release though triggers a number of people who don’t know about changes until after the release. Challenge: How can we help ensure changes that aren’t worthy of user marketing promotion are known by a far greater percentage of WordPress developers?
      Might also impact or benefit from input from +make.wordpress.org/plugins +make.wordpress.org/themes +make.wordpress.org/marketing +make.wordpress.org/meta.
      Even when we get the field guide out on time, issues come up post release.
      two ideas:
      1) Translating the field guide (is this reasonable if the posts that it links to aren’t translated?) Also means polyglots should be in the discussion
      2) Using the new release email mailing list to announce RC
    • @helen: I think it’s worth at least starting the conversation earlier, even if it ends up still being valuable to continue something in person.
    • @desrosj: There may also be some great ideas from people who cannot attend in person. It would be a great opportunity for them to have their ideas heard and contribute, even if they are not able to follow through with the discussion in person at the summit.
    • @jorbinI’m going to withdraw the communication topic as my proposal for the summit with the note that I might want to resubmit it depending on how the virtual discussion goes
    • @azaozz and @sergey as additional reps for this topic
  • Security [will submit to CS]
    • @chriscct7: The process of a security ticket from report through triage through disclosure. Aaron Campbell (security czar) has made it clear this needs to be discussed at some point and I feel like the community summit would provide a good venue as many of those on the team will be there in person and we can mirror the conversation easily for those who are not. Recommend including @aaroncampbell
    • @aaroncampbell: This is actually a good idea, although I don’t think it’s because “those on the team will be there” but rather because I’d love to get input from some other people too, and security is generally sensitive enough that a place like the summit seems useful
    • @rmccue, @kadamwhite, @matveb, @joen, @westonruter, @melchoyce as additional reps for this topic
  • Collection of Anonymous data [will NOT submit to CS]
    • @chriscct7: If core is interested in doing it, I think my experience with doing it for a trac ticket (settings reduction) might prove to be useful to add to the discussion. Recommend including @drewapicture
    • General agreement to NOT include this topic since this is currently opt-in and the issue is finding an owner of this topic
  • Bootstrap/Load [will NOT submit to CS]
    • @schlessera: Opening up the WordPress Core Architecture to make it flexible enough as a platform so that it can:  * serve both novice end-users as well as large-scale enterprise installations in an optimized way;  * quickly adapt to changing external requirements, to keep up with the accelerating pace of the web. Recommend including @rmccue
    • General agreement to NOT include this topic since it does not need to happen in-person, already has discussions underway, and should be scheduled in next couple of weeks
  • Code editor [will NOT submit to CS]
    • @georgestephanis: Code Syntax Highlighting implementation and accessibility concerns — how we can get CodeMirror or whatever better library there is implemented and rolled out for both Customizer Custom CSS, Theme/Plugin Editor, and Content Blocks. Recommend including @afercia @westonruter
    • General agreement to NOT include this topic since it does not need to happen in-person and should happen sooner than the CS.
  • REST API authentication [will NOT submit to CS]
    • @georgestephanis: Third-party authentication with the REST API.    Between OAuth 1.0a, OAuth2, central application brokers, Application Passwords, or some other system — there’s a lot of possibilities here, and it’d be really nice if Core could pick something and move forward with it before folks start spoofing cookie authentication in applications to integrate with core.
    • Relevant chat summary from the last time we had one
    • This really needs an owner, otherwise it’ll continue to be punted. There’s fundamental differences on what the direction should be.
    • @samuelsidler: I don’t think core can decide until someone has documented the possible options, along with their strengths and weaknesses, then had some discussions on what would be best for core and why.
    • @georgestephanis, @rmccue, @logankipp volunteered post on Make/Core to move this topic along
    • We will table this idea and maybe propose it for the summit based upon how the near term discussions go
  • Front-end Editing [will NOT submit to CS]
    • @westonruter: Frontend editing powered by bootstrapping the customizer onto the frontend, with inline direct manipulation of elements on the page and the controls sidebar being lazy loaded to slide in from the left as needed. Editable elements include post content and site configuration (sidebars, menus, options, etc). Recommend including @celloexpressions
    • General agreement to NOT include this topic since it depends on too many other things we won’t know by then, so we will pass on that topic (at least for now).
  • Nextgen Widgets [will NOT submit to CS]
    • @westonruter: Next generation of widgets which harmonize with content blocks in the editor.
    • General agreement to NOT include this topic for the CS, but good conversation for the contributor day.
  • Feedback on Core focuses [will NOT submit to CS]
    • @georgestephanis: Six months in, how are we feeling about shifting away to a more top-directed set of focuses for the year?
    • General agreement to NOT include this topic as it’ll be hard to say until/unless we’ve shipped a core release by then (we likely won’t) and is a conversation that should happen in public.
  • Complete list of representatives nominated to attend the Community Summit: @matt, @nacin, @adamsilverstein@rmccue@kadamwhite@chriscct7, @dd32@pento@afercia@rianrietveld@westonruter@azaozz@matveb, @getsource, @boonebgorges@aaroncampbell, @jorbin, @logankipp, @peterwilsoncc, @flixos90, @johnbillion, @stevenkword, @azaozz, @sergey, @karmatosed, @joen, @westonruter, @melchoyce, @jnylen0, @ipstenu, @joemcgill, @joehoyle, @rachelbaker, @michael-arestad, @petya, @danielbachhuber, @ocean90, @samuelsidler, @afercia@desrosj, @iseulde, @jjj@celloexpressions
  • We’re still searching for 1-2 contributors who are willing to help with event organization, so please comment here or reach out to @jbpaul17 if you’re interested
  • @jbpaul17 will send the Core team responses to the Community Summit team by Friday, March 3rd.

Browser support

  • Please take a look at @desrosj’s post: The New Editor and Browser Support
  • This will be a topic of discussion at next week’s devchat.
  • Please leave your thoughts there as comments, and bring them along next week as well.

#4-7, #4-7-3, #community-summit, #core, #core-customize, #core-editor, #core-restapi, #dev-chat, #summary

Week in Core, February 22nd – 28th, 2017

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

  • 41 commits
  • 46 contributors
  • 76 tickets created
  • 21 tickets reopened
  • 71 tickets closed

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

Code Changes

Administration

Build/Test Tools

Comments

  • When commenting on a draft post, display a friendly error message if the user can view the post. [40128] #39650

Mail

  • Ensure entities in the site title are decoded when used in the body of the new user email. [40127] #39446

Media

Misc

  • Bump the version after the 4.7.3-RC1 packaging. [40141] #
  • Version bump for WordPress 4.7.3-RC1 [40140] #

Networks and Sites

  • Multisite: Use WP_Network_Query in WP_Network::get_by_path(). [40102] #37217

Posts, Post Types

  • Docs: Update the description of is_singular() and WP_Query::is_singular() to be parsed correctly by developer.wordpress.org. [40103] #39948

REST API

Themes

  • Enable browser history support in add new theme screen. [40107] #36613

TinyMCE

Upload

Thanks to @adamsilverstein, @afercia, @ajoa, @azaozz, @blobfolio, @codegeass, @davidakennedy, @dd32, @desrosj, @Drivingralle, @flixos90, @gitlost, @grapplerulrich, @iandunn, @ipstenu, @iseulde, @jazbek, @jeremyfelt, @jnylen0, @joehoyle, @joemcgill, @johnbillion, @johnjamesjacoby, @JPry, @markoheijnen, @MatheusGimenez, @mayurk, @mikeschroder, @milindmore22, @mnelson4, @netweb, @ocean90, @rachelbaker, @reldev, @ryelle, @sagarprajapati, @sanchothefat, @SergeyBiryukov, @spacedmonkey, @swissspidy, @triplejumper12, @welcher, @westonruter, and @xknown for their contributions!

Improving the REST API users endpoint for multisite in 4.7.3 and 4.8

Multisite office hours are held every Tuesday at 17:00 UTC in #core-multisite. The next will be Tuesday 17:00 UTC.

Improving the users endpoint was the main focus of this week’s office hours. The following is a recap of the decisions from that discussion. Please leave your feedback in the comments on this post. Related meeting notes are available from the January 10th office hours and the January 3rd office hours.

Chat log

Attendees: @iamfriendly, @sergeybiryukov, @flixos90, @ssstofff, @vizkr, @jnylen0, @nerrad, @johnbillion, @jeremyfelt

4.7.3

Some small changes to the users endpoint for multisite should be made in 4.7.3. The ticket for these changes is #39701.

  • Fail when a GET request is made to site.com/wp-json/wp/v2/users/<id> and that user is not a member of the current site.
  • Fail when a PUT request is made to site.com/wp-json/wp/v2/users/<id> and that user is not a member of the current site.

The expectation for the users endpoint in 4.7.3 is that only users from the current site can be listed or managed in any way via the REST API. Global access to users will not be available, even to global administrators (super admin).

4.8

The users endpoint will be improved significantly for the 4.8 release, ideally providing full compatibility with how users are currently managed in a multisite configuration. The ticket for this task is #39544.

Here are the expectations for the users endpoint in 4.8:

  • POST to site.com/wp/v2/users/ with an existing global user’s email address adds the existing global user to a site.
  • POST to site.com/wp/v2/users/ with complete new user data creates a new global user.
  • GET to site.com/wp/v2/users/ with a global parameter set to true lists all global users.
  • GET to site.com/wp/v2/users/ without a global parameter lists only the site’s users.
  • GET to site.com/wp/v2/users/<id> with a global parameter set to true lists data for a global user, even if they are not a member of the site.
  • GET to site.com/wp/v2/users/<id> without a global parameter lists data for a user only if they are a member of the site.
  • PUT to site.com/wp/v2/users/<id> with a global parameter set to true updates a global user and data for a user that is in the global context.
  • PUT to site.com/wp/v2/users/<id> without a global parameter updates a data for a site user that is in the site context. This is how role data can be passed to maintain a user’s relationship with the site.
  • DELETE to site.com/wp/v2/users/<id> with a global parameter set to true deletes the user completely.
  • DELETE to site.com/wp/v2/users/<id> without a global parameter removes the user from the site.

Note that while users exist in a global context, data attached to these users can exist in the global context (e.g. email address) or in a site context (e.g. site role). There may need to be a method for registering user meta in a way that specifies whether it should be treated as global or site data.

Much of the work for 4.8 is still fluid. Please leave feedback on this approach in the comments and join office hours in #core-multisite on Tuesday 17:00 UTC!

#multisite, #networks-sites, #rest-api

Improving the Settings API for accessibility and ease-of-use

On January 2nd the first meeting to discuss improvements of the well-known, but not well-loved Settings API took place in #accessibility. After a healthy discussion the next meeting was set to take place last Monday. Since the suggested improvements are not solely related to accessibility, the location for the meeting was moved to #core. This post is a recap of what was decided during these two meetings.

Archives of the full conversations:

Attendees: @afercia, @flixos90, @helen@joedolson, @johnbillion, @rianrietveld, @sc0ttkclark

First Meeting

The original reason for calling these meetings were several accessibility problems on WordPress settings pages. To quite some extent, these are related to the table markup that is automatically printed by the current Settings API. On a related note, it was mentioned that being required to write callback functions for rendering each and every field is a major drawback. Providing default callbacks would thus not only make it easier to work with the API, but also further improve accessibility as these callbacks would all be reviewed by the team. So the two main goals that were figured out were:

  • Add some basic support to automatically render fields so that plugin developers no longer need to write their own callback functions for basic fields.
  • Get rid of the table structure to improve accessibility. Furthermore the accessibility team should also ensure that the markup generated as the core field output is accessible.

The first meeting was also centered on whether these improvements should be tackled through means of the Fields API project, a new “Settings API v2” or improving the existing Settings API. In the end it was decided to continue working with the existing API, mainly for the following reasons:

  • The Fields API project is a huge effort that will still take a while until it can possibly be merged into core. Still, it will follow up with the changes that will be introduced in the Settings API, as @sc0ttkclark pointed out. While printing fields is certainly the focus of the Fields API, introducing a few technically simple callbacks in core at this point will not be a problem as these can be migrated to the Fields API ones at any time.
  • While the existing Settings API has its problems, it appears to be possible to handle the necessary improvements without running into backward-compatibility issues. A completely new Settings API could have further benefits, but it would leave many users behind that would need to manually migrate, and furthermore would take much longer to scaffold and implement.

After the meeting, a general ticket for the task was opened at #39441. The ticket description provides more information on how the two identified goals should be accomplished. In addition to the technical details, the first part of the accessibility measures will be to create an HTML-only prototype of what a better settings page would look like. It should be created without the limitations of the Settings API, so that the result can be the best possible example for what the enhanced Settings API should produce.

Second Meeting

@rianrietveld had four items on the agenda for the second meeting.

  • At first, everyone was asked to review the patch that @flixos90 provided on the above ticket. The patch only applies to introducing default field callbacks, so it still lacks adjustment of the table markup and a proper accessibility review, but it shows a possible technical approach.
  • Related to the patch, a tiny plugin was created and uploaded to the ticket as well. This plugin allows for easy testing of the functionality. For easier collaboration and possible iterations, that plugin has now been moved to GitHub. Feel free to try it out with the patch applied.
  • Some results of an accessibility test for form elements that was conducted by the accessibility team were revealed as a preparation for the prototype settings page in HTML. A few major issues to consider were discussed, for example the requirement of IDs on every field, the proper usage of fieldset and legend elements and the problematic usage of <input type="number"> for Dragon NaturallySpeaking speech recognition software. For creating the HTML prototype, it was decided to focus on replicating the core settings pages “General” and “Discussion”.
  • For the next step of the efforts, @afercia volunteered for creating the prototypes. As of now, the field markup he created for the two replicated settings pages can be inspected on GitHub (last two items in the list). These will probably be discussed in the next meeting.

If you are interested in helping out, there are several ways for you to do so: Please review the suggested improvements, the HTML prototypes and/or the technical approach. Feedback can be provided on the ticket, this post or by participating in the upcoming meeting/s. The Settings API meeting takes place biweekly on Monday at 17:00 UTC, so feel free to drop by. The next meeting will be on Monday, January 30.

#accessibility, #settings

Week in Core, December 14th 2016 – January 3rd, 2017

Welcome back the latest issue issues (sorry) of Week in Core, covering changes [39599-39665]. Here are the highlights:

  • 67 commits
  • 56 contributors
  • 203 tickets created
  • 24 tickets reopened
  • 145 tickets closed

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

Code Changes

Bootstrap/Load

  • Bootstrap: Re-initialize any hooks added manually by object-cache.php.
    Prior to 3.1 if a object cache dropin wanted to add actions, they needed to use $wp_filter directly. [39605] #39132

Build/Test Tools

  • Tests: Restore the database connection earlier when switching test groups. [39626-39627] #39327

Bundled Theme

  • Twenty Seventeen: Fix incorrect $content_width value in theme. [39635], [39650] #39272
  • Twenty Seventeen: Hardens the logic for calling featured image in header.php [39624] #39302
  • Twenty Seventeen: Ensure functions in customize-controls.js don’t count on Customizer sections always being present [39623] #39335
  • Twenty Seventeen: Improves code readability and code standards in files [39618] #39152

Comments

  • Ignore the ‘comment_order’ setting when determining comment pagination. [39663-39664] #31101, #39280
  • Fix placement of the wp_update_comment_data filter to safeguard filtered data from triggering a database error. [39640-39641] #39380

Customize

  • Fix visible edit shortcuts for wp_nav_menu() instances using the menu arg (such as in the Custom Menu widget) instead of the theme_location arg. [39622], [39653] #27403, #39101
  • Bump wp_custom_css_cb from running at wp_head priority 11 to 101 to ensure Custom CSS overrides other CSS. [39616], [39651] #35395, #38672, #39270
  • Prevent edit shortcut from losing event handler after selective refresh. [39606] #27403, #39100

Editor

External Libraries

Feeds

  • Replace the RSS2 lastBuildDate date field with the r date specifier. [39614] #39141
  • Do not translate the lastBuildDate field in RSS feeds. [39613] #39141

Filesystem API

  • Filesystem: Add return statement to WP_Filesystem_ftpsockets->rmdir [39644] #39405

General

  • Update copyright year to 2017 in license.txt. [39659], [39661] #39433
  • Docs: Misc corrections and additions to inline documentation. [39639] #39130
  • Use interpolation instead of concatenation for all dynamic hook names. [39600] #39148

Mail

  • Ensure that any phpmailerException exceptions generated by setFrom() are caught to avoid PHP Fatal errors. [39655] #25239, #39360

Media

  • Move a variable definition outside of conditionals to ensure it’s always available.
    This [39654] #39250
  • Allow PDF fallbacks filter to process custom sizes. [39617] #39231, #38594
  • This [39612] #39250
  • PDF Images: Avoid a PHP Warning when attempting to process a file without an extension. [39607] #39195

Posts, Post Types

  • Taxonomy: Eliminate redundant and inaccurate dupe check when creating categories from post.php. [39637] #16567
  • Ensure is_page_template() can only return true when viewing a singular post query. [39599], [39608] #39211

Query

  • Don’t double-escape terms payload in WP_Tax_Query::transform_query(). [39662] #39315
  • Improve documentation for orderby=relevance in WP_Query. [39636] #39336

REST API

  • Add missing assertions to the view and embed context response data for the Users Controller. [39660] #39399
  • Add the supports property to the Post Type response object. [39647] #39033
  • Remove errant annotation from test_get_items_pagination_headers() method. [39643] #39398
  • Allow schema sanitization_callback to be set to null to bypass fallback sanitization functions. [39642] #38593, #39042
  • Docs: Add and correct @since docs for a variety of functions and methods. [39638] #39343, #39357, #39344, #39130
  • Allow sending an empty or no-op comment update. [39628] #38700
  • Improve the rest_*_collection_params filter docs and fix the terms filter. [39621] #39300
  • Fix PHP warnings when get_theme_support( 'post-formats' ) is not an array. [39620] #39293
  • Do not include the password argument when getting media items [39610] #38977
  • Do not error on empty JSON body [39609] #39150
  • WP-API: JavaScript client – fix setup of models used by wp.api.collections objects. [39603-39604] #39070
  • Add support for filename search in media endpoint. [39598] #39092

Shortcodes

  • Clarify the docs for pre_do_shortcode_tag and do_shortcode_tag. [39665] #39294

Taxonomy

  • Redirect to current taxonomy when adding a term without AJAX. [39649], [39652] #39328
  • REST API: Merge similiar error message strings in the Terms Controller. [39648] #39176
  • Ensure that mods to query vars in pre_term_query callbacks have an effect. [39625] #39354
  • Restore the ability to use string-based $args in wp_get_object_terms(). [39611] #39215

Upgrade/Install

  • Updates: Show the Authentication key settings after selecting the SSH transport in both the modal, and also on the plugin/theme updates screen. [39657-39658] #39057
  • Updates: Remove a stray " from a tag. [39656] #39057

Thanks to @adamsilverstein, @afercia, @bcworkz, @boonebgorges, @chandrapatel, @ChopinBach, @chris_de, @davidakennedy, @dd32, @dhanendran, @dl, @dlh, @dots, @dreamon11, @dshanske, @garyc40, @gitlost, @iseulde, @jblz, @jesseenterprises, @jfarthing84, @jnylen0, @joemcgill, @johnbillion, @jorbin, @JPry, @keesiemeije, @keesiemeijer, @kkoppenhaver, @kovshenin, @laurelfulford, @MattyRob, @MikeHansenMe, @natereist, @Nikschavan, @obenland, @ocean90, @pento, @peterwilsoncc, @rachelbaker, @ramiy, @sanket.parmar, @sebastian.pisula, @SergeyBiryukov, @sfpt, @shazahm1hotmailcom, @sirbrillig, @sstoqnov, @stevenkword, @szaqal21, @thepelkus, @timmydcrawford, @tymvie, @tyxla, @voldemortensen, and @westonruter for their contributions!

#4-8, #week-in-core

Week in Core, December 7 – 13, 2016

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

  • 69 commits
  • 39 contributors
  • 143 tickets created
  • 29 tickets reopened
  • 100 tickets closed

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

Code Changes

Administration

  • Remove the WordPress version number from readme.html. [39583] #35554
  • De-Emphasise the minor (x.y.Z) version in readme.html by including only the major version for the 4.7 branch. [39582] #35554
  • Accessibility: Remove inappropriate content from the Edit Categories and Edit Tags screens headings. [39553] #26601
  • Accessibility: Remove inappropriate content from the Edit Comments screen heading. [39552] #26601
  • Accessibility: Remove inappropriate content from the Network screens headings. [39551] #26601
  • Accessibility: Remove inappropriate content from the Menus screen heading. [39543] #26601
  • Accessibility: Remove inappropriate content from the old Edit Media screen heading. [39542] #26601
  • Accessibility: Remove inappropriate content from the Widgets screen heading. [39541] #26601
  • Accessibility: Remove inappropriate content from the Edit User screen heading. [39538] #26601
  • Accessibility: Remove inappropriate content from the Link Manager screens headings. [39537] #26601
  • Accessibility: Remove inappropriate content from the Add Plugins screen heading. [39536] #26601
  • Accessibility: Remove inappropriate content from the Plugins screen heading. [39535] #26601
  • Accessibility: Remove inappropriate content from the Users screen heading. [39534] #26601

Bootstrap/Load

  • Bootstrap: Re-initialize any hooks added manually by object-cache.php.
    Prior to 3.1 if a object cache dropin wanted to add actions, they needed to use $wp_filter directly. [39565] #39132

Build/Test Tools

  • Facilitate SVN and Git being co-located in the same directory. [39577] #39245
  • Remove some more randomness. [39556] #37371
  • Reuse another fixture in the user capability tests. [39555] #38716
  • Remove commented out tests that have existed in an unimplemented state since the dawn of the test infrastructure. [39554] #38716

Comments

Customize

  • Prevent navigation in preview when clicking on child elements of preview links that have non-previewable URLs. [39584-39585] #39098
  • Prevent edit shortcut from losing event handler after selective refresh. [39581] #27403, #39100
  • Deprecate page_home nav menu item starter content in favor of home_link; replace usage in Twenty Seventeen. [39561], [39575] #38615, #38114, #39104
  • Allow (optional) url parameter to be omitted in intercepted calls to history.pushState() and history.replaceState() in customize preview. [39547], [39574] #39175
  • Trim whitespace for URLs supplied for external_header_video to prevent esc_url_raw() from making them invalid. [39560], [39573] #38172, #39125
  • Fix ability to shift-click on placeholder/pre-saved nav menu items in preview to focus on corresponding control. [39562], [39572] #39102
  • Use selected user language for edit shortcuts in preview instead of site language. [39545], [39571] #39009
  • Fix inability to delete nav menus by preventing preview filters from being added during customize_save admin ajax request. [39558], [39570] #30937, #39103
  • Prevent scrolling custom_css textarea to top when pressing tab. [39557], [39569] #38667, #39134
  • Use esc_url_raw() instead of wp_json_encode() to eliminate extraneous slashes when outputting background image URL in CSS url(). [39546], [39568] #22058, #39145
  • Prevent single quotes (apostrophes) in custom_css values from unexpectedly causing false positives for unbalanced character validation errors. [39559], [39567] #39218, #35395, #39198
  • Collapse available nav menu items panel when clicking outside over preview or over existing items. [39548] #38953

External Libraries

  • Libraries: Update zxcvbn from version 1.0 to 4.4.1 [39596] #31647

General

  • Correctly detect trailing newline when prepending. [39592] #37082
  • Remove most uses of create_function() [39591] #37082
  • Taxonomy: Correct the type for the first parameter of the the_category filter. [39530] #39130

Login and Registration

Media

  • PDF Images: Avoid a PHP Warning when attempting to process a file without an extension. [39580] #39195

Misc

  • Bump the version in package.json to 4.7.1 after [39576]. [39579] #
  • The 4.7 branch is now 4.7.1-alpha. [39576] #

Options, Meta APIs

  • Options: Prevent unnecessary SQL updates by update_option. [39564] #38903

Query

  • Docs: Correct param definition for WP_Query::query(). [39550] #38963

REST API

  • Add support for filename search in media endpoint. [39598] #39092
  • Allow sending an empty or no-op comment update. [39597] #38700
  • Do not include the password argument when getting media items [39595] #38977
  • Do not error on empty JSON body [39594] #39150
  • Treat any falsy value as false in ‘rest_allow_anonymous_comments’. [39566] #39010
  • Allow schema sanitization_callback to be set to null to bypass fallback sanitization functions. [39563] #38593, #39042

Role/Capability

  • Tests: Use wp_delete_user() during teardown to delete a single site’s user. [39590] #39065
  • Multisite: Replace is_super_admin() with manage_network in get_dashboard_url(). [39589] #39065, #37616
  • Multisite: Handle capability check for removing oneself via map_meta_cap(). [39588] #39063, #37616
  • Multisite: Replace is_super_admin() with update_core for update permissions. [39540] #39060, #37616
  • Multisite: Remove redundant is_super_admin() when checking for edit_others_posts. [39539] #39059, #37616

Taxonomy

  • Use get_term_link() instead of get_category_link() in get_term_parents_list(). [39593] #17069
  • Restore the ability to use string-based $args in wp_get_object_terms(). [39578] #39215
  • Introduce get_term_parents_list(). [39549] #17069

Themes

Toolbar

Users

  • Style the super admin message on the user editing screen as a notice, not a success message. [39531] #39131

Thanks to @afercia, @boonebgorges, @bradyvercher, @celloexpressions, @chandrapate, @Christian1012, @david.binda, @dd32, @flixos90, @Hristo Sg, @iaaxpage, @jblz, @jnylen0, @joehoyle, @johnbillion, @jorbin, @JPry, @kafleg, @keesiemeijer, @ketuchetan, @kkoppenhaver, @obenland, @ocean90, @pento, @peterwilsoncc, @rachelbaker, @rafaehlers, @rmccue, @rockwell15, @salcode, @SergeyBiryukov, @sgolemon, @Shelob9, @sirbrillig, @sstoqno, @tomdxw, @tyxla, and @westonruter for their contributions!

#4-7-1, #week-in-core

Multisite Office Hours Recap (December 13, 2016)

Multisite office hours are held every Tuesday at 17:00 UTC in #core-multisite. The next will be Tuesday 17:00 UTC.

The weekly agenda was to discuss long-term goals for multisite and prioritize tickets to work on related to one of the three new focuses, particularly the REST API.

Today’s chat log

Attendees: @iamfriendly, @mista-flo, @johnjamesjacoby, @loreleiaurora, @johnbillion, @jeremyfelt, @flixos90

Chat Summary:

  • @jeremyfelt, @flixos90, @johnjamesjacoby, and @johnbillion sat down for a chat at WCUS to discuss multisite topics and possible future focuses. @jeremyfelt shared his notes from that session. Items of particular interest in today’s chat were:
    • Identify statistics for multisite usage, size of multisites: Possibly sending more general multisite-related metrics during core updates could be helpful and should be further discussed. In addition to whether multisite is enabled and the count of sites (on the main network) it could be helpful for future decisions to know how many sites there are in total, how many networks exist and whether user / site registration is open or not.
    • Implementation of network user roles: A ticket is in place at #39174. @flixos90 requested feedback: Everyone interested is asked to read through the ticket description and provide an elaborate response with how they think network roles should work. Then a discussion based on these approaches can start.
    • Network administrators should be able to enable themes on the site level: It is currently not very convenient for a network administrator to switch back to the network admin to enable a theme when currently working within the site admin.
    • Disable plugins per site in the network admin: Sometimes not all plugins should be visible on all networks or all sites, which is currently not possible. However, even for a disabled theme a network administrator should still be able to “silently” activate it on a site. Plugins would need to be enabled by default, so it would be the opposite way of how themes are currently handled. This also ensures there are no concerns with backward-compatibility. UI-wise an improved flow should be investigated instead of simply pursuing a similar approach to how enabling themes works: Having all the functionality inside the Network > Plugins screen would be helpful, with row and bulk actions for “Network Disable” as well as “Disable for Site…” with the latter having some kind of popover with an autocomplete field for sites. A related ticket to take into account for the implementation is #38652 which @johnbillion opened to introduce singular capabilities for managing plugins.
    • Whichever flow is agreed on for disabling plugins per site or network, once this functionality is implemented, it will probably make sense to “back-port” the behavior to improve the existing theme and maybe even user handling in a multisite.
  • At this point, the highest priority is multisite support for the REST API.
    • The users endpoint should be improved, particularly the implementation of DELETE for a user on a multisite as well as removing a user from a site or setting their capabilities per site via PUT (see #39000 and #38962 for related tickets).
    • A sites endpoint should be added.
    • A networks endpoint is not as important and should for now only live in a standalone plugin if there is interest to implement it.
  • A general question raised was how No-JS fallbacks for REST API functionality in the admin should be handled. Should JavaScript become a requirement to use such new functionality or should the REST API only be used to improve existing PHP-only features? These questions should be discussed in a broader scope than just multisite since they affect all of WP Admin.
  • Possible usage for a REST API sites endpoint:
    • Replacing “My Sites” in the toolbar with a menu that doesn’t load until needed and pulls all sites from the API.
    • The possible autocomplete field for disabling plugins for a specific site (see above) could pull sites from the API.
  • @mista-flo brought up #13743 and asked for feedback. Everyone in the chat agreed that the ability to set a default theme for a network would be a valuable enhancement over the existing constant. For the approach, introducing a new row action “Set default theme” the Network > Themes list table was suggested, alongside an indicator “Default Theme” in that same table. This is an enhancement that can be worked on beside the other important REST API features.
  • A Google document was opened a while ago to gather input for a future multisite roadmap, as a follow-up to 2013’s post. @jeremyfelt highlighted that this document should continue to move forward in order to hopefully be able to publish an actual roadmap in early January.

#4-8, #multisite, #network-sites

Week in Core, November 30 – December 6, 2016

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

  • 150 commits
  • 63 contributors
  • 140 tickets created
  • 17 tickets reopened
  • 104 tickets closed
  • WordPress 4.7 released 🎉

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

Code Changes

Administration

  • Accessibility: Remove inappropriate content from the Themes screen heading. [39528] #26601
  • Accessibility: Remove inappropriate content from the Add Themes screen heading. [39527] #26601
  • Accessibility: Remove inappropriate content from the Media Library screens headings. [39526] #26601

Build/Test Tools

  • Correctly set up the current screen during list table tests so that they don’t fail when run individually. [39481] #38761
  • Specify exact node version in package.json. [39480], [39478] #35105, #38657
  • Remove PHP 7.1 from allowed failures [39424-39425] #37625

Bundled Theme

  • Default Themes: Update version numbers and readme files for 4.7 release [39496] #38858
  • Twenty Seventeen: Fix CSS specificity problem with CSS feature query for object-fit [39495] #39073
  • Twenty Seventeen: Improve display of video header and header image in modern browsers [39485], [39483] #39035
  • Twenty Seventeen: Add specific font stack for Thai language [39484], [39482] #38937
  • Twenty Seventeen: Improve ARIA for the nav menu. [39451-39452] #39029, #39026
  • Twenty Seventeen: Ensure header text color updates in Customizer preview when cleared [39447-39448] #38993
  • Twenty Seventeen: Fix broken menu toggle in Customizer after menu items are added [39419], [39423] #38992
  • Twenty Seventeen: Fix style issues with gallery image links [39418], [39422] #38969
  • Twenty Seventeen: Hide front section panels on page load of Customizer. [39417], [39421] #38951
  • Twenty Seventeen: Add .has-header-video styles for custom color schemes. [39416] #38995
  • Twenty Seventeen: Better handling of custom headers when no image is set. [39413-39414] #38995
  • Twenty Seventeen: Make spacing on pages without comments consistent [39404-39405] #38972
  • Twenty Seventeen: Make sure header text color is applied when color schemes are active. [39397-39398] #38980
  • Twenty Seventeen: Make fixed navigation apply at correct height on front page, without header video or image [39394], [39392] #38927
  • Twenty Seventeen: Provide a background color fallback for non-webkit browsers on input styles [39388] #38939
  • Twenty Seventeen: Allow child themes to easily extend custom color patterns [39386] #38949
  • Twenty Seventeen: Make screen reader text on scroll arrow more meaningful [39384] #38970
  • Twenty Seventeen: Keep header videos from extending past footer. [39380-39381] #38950

Comments

  • Merge a similar string between comments.php, XML-RPC and the REST API comments controller. [39508] #39013

Customize

  • Prevent infinite full refresh from occurring when selective refresh falls back for a nav menu that has items excluded from rendering via filtering. [39510-39511] #38612
  • Defer populating post_name for auto-draft posts in customized state until posts are published. [39506-39507] #39078
  • Ensure changeset_uuid query param is removed from the customize.php window’s location once a changeset has been published (committed) with starter content. [39504-39505] #39081
  • Prevent posts/pages imported via starter content from being dropped when adding post/page stubs via nav menus and the dropdown-pages control. [39502-39503] #38114, #34923, #39071
  • Ensure textarea for Custom CSS displays as code (in LTR) when an RTL language is active. [39499-39500] #35395, #39085
  • Ensure a custom_css post insertion gets an initial post revision. [39479], [39477] #30854, #38672, #35395, #39032
  • Custom CSS: Change the help link to something better for users. [39467], [39466] #39015
  • Fix posts limit query arg for WP_Query from incorrect number to posts_per_page. [39434-39435] #39022
  • Reuse existing non-auto-draft posts and existing auto-draft posts in the customized state with matching slugs when applying starter content. [39411] #38114, #38928
  • Reject a changeset update when a non-future date is provided and also ensure that a published changeset always gets set to the current date/time. [39409-39410] #30937, #38943
  • Fix handling of the nav menu item labels (titles) that match defaults (original titles) and fix the display of item type labels. [39395], [39393] #38015, #38955

Feeds

General

Help/About

Media

  • Accessibility: Improve keyboard accessibility avoiding confusing tab stops in the Media views. [39529] #30599
  • Docs: Add inline documentation for image-edit.js. [39493] #38748
  • Fix regression with display of small images in media library. [39399], [39396] #38965
  • Docs: Document the usage of the global $wpdb in _filter_query_attachment_filenames(). [39390] #38973

Misc

  • Tag 4.7 [39525] #
  • WordPress 4.7 “Vaughan”. [39524] #
  • Post-RC3 bump. [39519] #
  • WordPress 4.7 RC3. [39516] #
  • Post-RC2 bump. [39474] #
  • WordPress 4.7 RC2. [39473] #
  • Twenty Seventeen: Add .has-header-video styles for custom color schemes. [39415]

Options, Meta APIs

  • REST API: Register the admin_email setting in single site only. [39470-39472] #38990
  • REST API: Site URL setting should not be present on multisite installations. [39468] #39005
  • REST API: Correct the admin_email setting description for single site installs. [39406] #38990
  • Multisite: Display different descriptions for multisite or single site installations. [39407] #38990
  • Options: Pass the $passed_default parameter to the 'default_option_{$option} filter in add_option(). [39382] #38176, #38930

Plugins

REST API

  • Comments: Merge similar strings between comments.php and the REST API comments controller. [39490-39491] #39014
  • Merge similar date strings in the revisions and comments controllers. [39488-39489] #39016
  • Treat any falsy value as false in ‘rest_allow_anonymous_comments’. [39487] #39010
  • Docs: Add missing REST API-related args to register_post_type() and register_taxonomy(). [39462-39463] #39023
  • Merge similar strings in a comments endpoint parameter description. [39457] #39036
  • Fix bug where comment author and author email could be an empty string when creating a comment. [39446], [39444] #38971
  • Fix handling of some orderby parameters for the Posts controller. [39440-39441] #38971
  • Disable DELETE requests for users in multisite. [39438-39439] #38962
  • Return a WP_Error if meta property is not an array. [39436-39437] #38989
  • Add test for creating a comment with an invalid post ID. [39408] #38991
  • Fix incorrect uses of rest_sanitize_value_from_schema(). [39400-39401] #38984

Role/Capability

  • Don’t assign the delete_site capability to anyone on single site installs. [39494] #38326
  • Multisite: Replace is_super_admin() with manage_network for admin bar permissions. [39492] #39064, #37616

Taxonomy

  • Docs: Update an @since as there will not be a 4.6.2 before 4.7. [39475-39476] #37291
  • REST API: Capability check for editing a single term should use the singular form. [39464] #35614, #39012
  • REST API: Use the correct error message when editing a single term. [39460-39461] #39017
  • REST API: Fix incorrect capability check on term create. [39402-39403] #35614, #38958
  • Performance: Revert [38677] from the 4.7 branch. This avoids fatal errors caused with recursive calling of term functions within the get_terms filter. [39454] #21760

Themes

  • Reuse existing non-auto-draft posts and existing auto-draft posts in the customized state with matching slugs when applying starter content. [39412] #38114, #38928

TinyMCE

  • Fix the styling of notices generated by the editor UI. [39501] #38917

Users

  • Clarify the return value of get_current_user_id() for non-logged-in users. [39486] #39051
  • REST API: Require the reassign parameter when deleting users. [39426-39427] #39000

Thanks to @andizer, @mor10, @adamsilverstein, @afercia, @azaozz, @boonebgorges, @celloexpressions, @ChopinBach, @clorith, @coffee2code, @davidakennedy, @dd32, @desrosj, @dlh, @flixos90, @georgestephanis, @helen, @helen, @hnle, @iaaxpage, @imnok, @jbpaul17, @jeremyfelt, @jnylen0, @joedolson, @joehoyle, @joemcgill, @johnbillion, @jorbin, @kadamwhite, @karmatosed, @ketuchetan, @laurelfulford, @littlebigthing, @lucasstark, @melchoyce, @michaelarestad, @mikeschroder, @mt8.biz, @nacin, @netweb, @ocean90, @ovenal, @pento, @peterwilsoncc, @presskopp, @rachelbaker, @rahulsprajapati, @ramiabraham, @ramiy, @rensw90, @rianrietveld, @rmccue, @samuelsidler, @sayedwp, @SergeyBiryukov, @sstoqnov, @The PHP tea, @timmydcrawford, @utkarshpatel, and @westonruter for their contributions!

#4-7, #week-in-core