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

Dev Chat Agenda for March 29th (4.7.4 week 4)

Please note the changed start time of this dev chat to account for DST. This is the first meeting at this new time.

This is the agenda for the weekly dev meeting on March 29, 2017 at 20:00 UTC:

  • 4.7.4 planning (bug scrubs, release date)
  • Editor team (feature plugin work is continuing on GitHub)
  • REST API team
  • Community Summit Core team reps

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-7, #4-7-4, #agenda, #dev-chat

Approaches for a complete sites endpoint and an expanded WP_Site_Query

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

Creating a useful sites/ endpoint for the REST API and making WP_Site_Query more useful have been frequent topics over the last few weeks in #core-multisite. Quite a bit of discussion has been centered around the idea of a global wp_blogmeta table, whether it’s a good fit for core, and (if so) how to approach its introduction. See #37923 and the previous make/core post discussing a sites endpoint for additional background.

The intent of this post is to step back a bit and clarify the issues at hand to help identify the right solution(s).

The initial site information problem

A request to a global wp-json/wp/v2/sites/ endpoint on a network should return a set of site objects, similar to how wp-json/wp/v2/posts/ returns a set of post objects. A request to wp-json/wp/v2/sites/4 would return a single site object.

Written today each site object, represented as WP_Site in PHP, would provide at least this data:

  • ID
  • domain
  • path
  • registered
  • last_updated
  • public
  • archived
  • mature
  • spam
  • deleted
  • lang_id

The above fields all mirror what is available in the global wp_blogs database table installed with multisite. These are useful on their own, but additional data is frequently required.

Example: One piece of the admin that would be great to power with the REST API is the My Sites menu that multisite users see in the toolbar. To build this view, the home URL, admin URL, and site name are all necessary. In PHP, this data is made available through magic properties on the WP_Site object. When home, siteurl, blogname, or post_count is requested, the site uses switch_to_blog() and get_option() to populate the data from the individual site’s options table. If 25 sites are on the list, this generates 25 context switches and accesses 25 different tables.

There are at least a few approaches here:

  • Mirror the existing PHP experience and ensure properties are populated before the REST API response is returned. Possibly introduce a lighter weight switch_to_blog() option.
  • Provide a basic site object as well as an option to _embed other data in the response.
  • Migrate these properties into wp_blogs from wp_#_options as additional columns.
  • Migrate these properties into a global wp_blogmeta table.
  • Migrate these properties into another shared global space.

The querying sites problem

It’s currently possible to query for sites by the default fields listed above. This data is useful for querying, but it would also be nice to query by a site’s name, description, or other piece of data at a global level.

Example: In the list table that displays all the sites of a network, it’s possible to query by a site’s domain or path, but not by it’s actual name. In a large network, a user may find it difficult to find a site when many sites share similar domains or paths. The user may know the site’s title, but not the address itself.

There is no real workaround for this issue in core right now as each site’s name is stored individually in that site’s wp_#_options table and cannot be queried collectively.

Possible approaches:

  • Migrate these properties into wp_blogs() from wp_#_options as additional fields.
  • Migrate these properties into a global wp_blogmeta table.
  • Migrate these properties into another shared global space.

Feedback please

Please leave any thoughts you have on possible approaches to these 2 problems. It would be especially helpful to identify some use cases that may not yet be clear, or approaches that are not listed above. All feedback is welcome. 🙂

#multisite, #rest-api

Dev Chat Summary: March 22nd (4.7.4 week 3)

This post summarizes the dev chat meeting from March 22nd (agendaSlack archive).

4.7.4 Planning

  • Moving dev chat back an hour to 20:00 UTC starting with next week’s chat (due to DST)
  • That makes next week’s meeting at Wednesday, March 29, 20:00 UTC
  • Bug scrub planned for Thursday, March 23, 15:00 UTC to review tickets in 4.7.4 milestone, likely tackling needs-patch tickets first
  • Tentatively aiming for first week of May for 4.7.4 release, but will adjust as bug scrubs determine what needs to / should land in 4.7.4

Core team reps

  • Still looking for nominations for a Core team rep
  • Core team reps need to plan to be at the Community Summit and can take on organizing topics and people
  • @logankipp planning to be at the summit, open to helping; will tag him as Core team rep, but would like to find one more person to help
  • Please comment or contact @jbpaul17 directly if you’re planning to attend the summit and can help organize topics/people for Core

Editor team

  • Moving into feature plugin phase with Gutenberg, looking for and greatly appreciate contributions and feedback to the GitHub repo
  • Lots of discussion ongoing in the GitHub repo (e.g., Plugin: Implement block registering API), so please follow along and chime in
  • Will proceed on Gutenberg without support for older browsers
  • Will start surfacing things that may need broader discussion in how we use JS, what tools we develop, etc.

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

Dev Chat Agenda for March 22nd (4.7.4 week 3)

This is the agenda for the weekly dev meeting on March 22, 2017 at 21:00 UTC:

  • 4.7.4 planning (DST, bug scrub, release date)
  • Confirmation on Core team reps
  • Editor team (Gutenberg moving to feature plugin phase)
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-7, #4-7-4, #agenda, #dev-chat

Dev Chat Summary: March 15th (4.7.4 week 2)

This post summarizes the dev chat meeting from March 15th (agendaSlack archive).

4.7.4 Planning

Browser support

  • Additional dev chat earlier today on topic of Browser support (Slack archive)
  • After some discussion, we arrived at the following strategy.
    • A “text” editor available to everyone is the best fallback – the new visual editor will leave old browsers behind.
    • Some form of the current version of the editor can be packaged into a plugin. Sites with users requiring a more advanced editor experience for older browsers can install this plugin.
    • The WordPress admin screen will display a notice of some sort to users with older browsers explaining the changes and how they can install the plugin for the experience they were used to (possibly utilizing BrowseHappy).
    • The editor team will use their research for the new editor to determine which buttons need to remain in the “text” editor with support for older browsers.
    • A more general discussion about browser support policies is slated to be had at the Community Summit before WordCamp EU. But this discussion can start before that (@jorbin is working on a Make post to start that conversation).
  • Any additional feedback from anyone who could not attend then is welcomed!

Core team reps

  • Last week we had nominations for @jorbin and @afercia.
  • Core team reps need to plan to be at the Community Summit and can take on organizing topics and people
  • @afercia not currently scheduled to be at summit, but would like to
  • Please comment or contact @jbpaul17 directly if you’re planning to attend the summit and can help organize topics/people for Core

Customize team

REST API team

  • Day of REST event was successful, but delayed continuing bug triage, will pick back up on 4.7.4 to make sure we keep solving the critical pieces
  • @jnylen0 & others resolved issue with tests & daylight savings time
  • due to bandwidth the existing REST API contributor group is fully occupied with the API itself
  • existing REST API contributor group have neither the bandwidth nor the domain expertise to also be leading the WP Admin implementations that will consume the REST API
  • @adamsilverstein lead the charge with Quick Draft, and work has begun in several parallel channels, but as of right now there’s nothing that appears to have momentum
  • We need help to drive adoption of the REST API within WP Admin, please come chat in #core-restapi any time
  • We need more explicit awareness of how the other feature teams want to use the REST API, or volunteers to lead separate implementations to move away from admin-ajax where it introduces inconsistency
  • If you’re not able to lead the separate implementations, then please chime in on component tickets as they’re opened to help us triage the pain points

General announcements

  • PHPunit tests (#39265: Missing @covers and @uses in the comments block in phpunt test for wordpress)
    • @pbearne: I am trying to do is get support to have @cover and @uses required for PHPunint tests
    • @pbearne: Willing to work through the old tests to add the missing comments
    • @pbearne: I would like to propose that we require for all new / updated tests and that the code committers commit updates with these added ASAP
    • How would we use that information going forward?
    • @pbearne: add to WordPress.org as way of show code quality and tell how well we are doing
    • What would be a realistic number we’d want to achieve?
    • @pbearne: anything over 80%
  • If you use the editor, please look to complete the Editor Experience Survey.

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

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!

Editor Experience Survey

As you’re well aware, a project is underway with the focus on redesigning the editing experience in the wp-admin. As the project moves forward, a better understanding of how WordPress users actually feel about the editing experience is needed. Please take a few minutes to fill out this survey and help influence the future of your favorite CMS, WordPress.

Survey Link:

http://wordpressdotorg.polldaddy.com/s/editor-survey

+make.wordpress.org/design

 

#core-editor, #design, #survey

Dev Chat Agenda for March 15th (4.7.4 week 2)

This is the agenda for the weekly dev meeting on March 15, 2017 at 15:00 CST:

  • 4.7.4 planning
  • Browser support (note discussion just prior at March 15, 2017 at 12:00 EDT)
  • Confirmation on Core team reps
  • Customize team update (media widgets & call for testing)
  • REST API team (call for help on JS Leadership for WP Admin implementations)
  • General announcements

If you have anything to propose to add to the agenda or specific items related to the above, please leave a comment below. See you there!

#4-7, #4-7-4, #agenda, #dev-chat

Dev Chat Summary: March 8th (4.7.4 week 1)

This post summarizes the dev chat meeting from March 8th (agendaSlack archive).

4.7.3 Update

4.7.4 Planning

  • The release lead for the next regularly-scheduled minor release (currently versioned as 4.7.4) will be @swissspidy.
  • Timeline tentatively set for April-May 2017, but we’ll have to get into bug scrubs and work with @swissspidy on an actual timeline for 4.7.4 as time goes by.
  • Just like 4.7.3, the timeline may change and will be highly dependent on how triage get tickets goes.

Browser support

  • @desrosj graciously compiled a summary of the discussion along with stats –> The New Editor and Browser Support
    • The overwhelming developer sentiment in the comments was for dropping support. A handful of people expressed that we did not have a full list of pros for dropping support.
    • But there was not as much discussion as I would have liked comparing the three potential fallbacks mentioned in the post, and no new potential fallbacks were mentioned.
    • I think if a solid, workable fallback that everyone is comfortable with can be decided on, then making the decision to drop support would be made a lot easier.
    • Dropping support for lower versions of IE could impact up to 2m WordPress users on the high end.
  • Discussion continues on a follow-up post –> Continued Discussion on Browser Support
  • There will be an additional dev chat this week to further discuss the fallback strategy to be used if support is dropped for older browsers. This chat will take place on March 15, 2017 at 12:00 EDT.

Core team reps

General announcements

  • A11y: #35566 to replace widget, create new widget, or other option from @afercia
    • A couple proposals on the ticket. Some work was done on them also at WC Europe.
    • We’ve discussed this issue during last accessibility bug-scrub on Monday and thought to bring it to everyone’s attention.
    • Before moving on, we’d like to:
      • see if there’s consensus in removing the title attributes there
      • and most of all, get feedback and recommendations about the best path forward, especially from people who have more experience than the a11y team has in managing backwards compatibility issues
    • As “tooltips” can be a controversial topic so the second proposal doesn’t use them
    • Looking for input on the best option: Deprecating the old widget and introduce a new one? Just replace the current widget? Or something else?
  • #39377: wpautop adds a extra </p>
    • @pbearne looking for dev-feedback, input from @azaozz
  • In a minor release we can consider string changes in moderation and for core focuses only, but we’d need a string freeze two weeks prior.

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