Dev Chat Agenda for February 15th (4.7.3 week 3)

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

  • 4.7.3 Scheduling
  • Customizer team update (including discussion on CodeMirror as code editor & related accessibility questions)
  • Editor team recap
  • 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-3, #agenda, #dev-chat

Dev Chat Summary: February 8th (4.7.3 week 2)

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

4.7.3 Schedule

  • Still no release date scheduled for 4.7.3, but we began to assess tickets this week and will continue next week
  • Goal is to finish scrubbing tickets in the milestone and plan for release timing
  • 4.7.3 milestone Bug Scrub planned for February 13, 2017 at 10:00 CST in #core
    • Focus on tickets with no owner set to see if any can be picked up and worked towards a commit this month
    • Please attend the scrub if you have tickets you’d like to discuss

Customizer team update

  • Customizer team appreciates any help by looking at tickets and pitching in where you can
  • Going through the customize component ticket backlog, identifying quick wins to add to the next release and then larger issues to tackle for the next major
  • #21666 (Customizer reset/undo/revert) and #38707 (Customizer: Additional CSS highlight, revisions, selection, per-page, pop-out) have initial designs and could use prototype and/or development help

Editor team update

  • The Editor team will post a Make/Design update soon that features a couple of mockups showing block level and inline level controls as well as showing off one or more prototypes in various states of functionality.
  • They’re working to get mockups and prototypes in a place where people can contribute to them, so keep an eye out for their post and please consider contributing and/or giving feedback.

REST API team update

  • @rmccue is working on using the API to improve the editing experience relating to bulk actions in list views
  • With limited team bandwidth, we’re evaluating existing usages of admin-ajax to prioritize places where the API can be implemented to reduce inconsistency
  • During 4.7 Quick Draft stalled out due to questions about content filtering that are happening on the admin-ajax path, and has resurfaced #21170 (JavaScript actions and filters) and #20491 (Introduce some JavaScript i18n functions)
  • @kadamwhite is triaging open API bugs weekly, with a focus on normalizing inconsistencies
  • #38323 (Reconsider $object_subtype handling in register_meta()) is priority from an API design standpoint, because the current behavior completely precludes using register_meta to model your data
  • @jnylen0 has been tracking the multi-site API discussions, and there’s a post from that group up on the make/core blog
  • Our biggest barrier is bandwidth; @rmccue & @kadamwhite are working on 1-2 priorities in their respective areas, but there’s a lot of docs and testing work, as well as POC for future endpoint types (like @westonruter is doing w/ Widgets) that could happen in parallel if there are interested parties
  • Widgets (and therefore Sidebars, later) endpoints are priorities for @westonruter given the Customizer focus
  • Menus endpoints are the other that comes up in conversation the most
  • Once we have the first WP-Admin usage in place, we’ll be looking for more contributors to help spearhead more admin-ajax replacement; that’s higher-priority than new endpoints from a core standpoint, in our opinion
  • The REST API group meets on Mondays at 21:00 UTC in #core-restapi, we hope to see you there!

Trac Ticket(s)

  • @pressupinc advocating for a fix for #34225 (Display correct dimensions for image sizes in media modal)
    • Seems to be caused by #35390 (image_constrain_size_for_editor() should not affect images generated on the front end when `large` size is used)
    • General issue is image sizes not displaying as they should in the Media modal
    • Reported #38906 (wp_get_attachment_image_src() sometimes gives incorrect width and height values)
    • Will check with Media team in #core-media

#4-7, #4-7-3, #dev-chat, #summary

Guideline reminder: commenting and comment moderation

With many new observers and contributors joining the WordPress core project recently, let’s take a moment to review the comment guidelines for Make/Core, which can also be extended to apply to Make/Design, Make/Accessibility, and Core Trac. Overall, the majority of comments seen are positive and constructive, and it’s important to keep it that way to ensure the health of the project and its contributors.

Of particular note to editors is the comment moderation policy:

If a comment is disrespectful and/or unprofessional, it may be edited at the discretion of the core team.

Editing of a comment will be done with the approval of at least two blog administrators. When a comment is edited, only the offending section will be edited with the intent of retaining as much of the expressed opinion. The administrators who edit the offending comment will add an editor’s note stating the reason for editing and the names of the administrators who took action. Additionally, the administrator doing the editing should retain a screenshot of the unedited comment, which can be uploaded to the Media Library on make/core, if necessary.

Comments will only be deleted when the offending comment is clearly spam that was not properly moderated.

Comments are generally approved by default, which means that email notifications are triggered immediately. Outright deletion of a comment that is anything except obvious spam will be noticed and fosters justified feelings of undue censorship and lack of consideration. Comments with issues such as information that should be privately sent to the security team, attacks on individuals, excessive use of profanity, or distractingly off-topic content should be edited with a note per the process outlined above. This serves multiple purposes: a record of what was changed and why; a visible stand by contributors that the cited behavior is not tolerated; and a public record of that particular commenter’s behavior for others to use as context.

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


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<id> and that user is not a member of the current site.
  • Fail when a PUT request is made to<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).


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 with an existing global user’s email address adds the existing global user to a site.
  • POST to with complete new user data creates a new global user.
  • GET to with a global parameter set to true lists all global users.
  • GET to without a global parameter lists only the site’s users.
  • GET to<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<id> without a global parameter lists data for a user only if they are a member of the site.
  • PUT to<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<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<id> with a global parameter set to true deletes the user completely.
  • DELETE to<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

Dev Chat Agenda for February 8th (4.7.3 week 2)

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

  • 4.7.3 Scheduling
  • Bug Scrub: 4.7.3 scrub through tickets with no owners on February 13, 2017 at 10:00 CST
  • Editor team recap
  • REST API team update
  • 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-3, #agenda, #dev-chat

REST API team meeting agenda for February 6

The REST API team will be meeting at 21:00 UTC in #core-restapi. Please note the updated time, which has been moved to 21:00 UTC to better match the schedules of the majority of the REST API leads & contributor team.

On the agenda:

  • focus for 4.7.3 and beyond: project Trello board review & discussion
  • establish owners to complete the docs migration from to
  • scrub tickets in the REST API trac component
  • open office hours

Dev Chat Summary: February 1st (4.7.3 week 1)

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

4.7.2 Update

4.7.3 Schedule

Customizer team update

  • Still going through the customize component ticket backlog, identifying quick wins to add to the next release and then larger issues to tackle for the next major release
  • We’re in need of patch contributors.
  • Tickets currently in the 4.7.3 milestone: should be read as “next minor release” and tickets are prone to punting.

Editor team update

  • The Editor team is working on a prototype, but otherwise has no other urgent updates.

REST API team update

  • The REST API team is also quiet this week, but will be meeting in-person next week.

Trac Ticket(s)

  • #39701: Do not allow editing users from a different site in REST API
    • related to multisite users handling
    • Discussed adding a ?global parameter to the API to enable managing multisite users, in 4.8 or later
    • REST API currently is essentially a single-site API, this ticket is one of the ways it behaves inconsistently regarding user management
    • @jnylen0 would like to make it behave more consistently like a single-site API for now, until we can thoughtfully and carefully add support for multisite
  • #39256: REST API: Multiple issues with setting dates of posts
    • Really needs more eyes, ideally in the form of failing/passing unit tests and patches
    • @jnylen0: These two issues are backwards-incompatible and the penalty of fixing them now, while not many people are using the API yet, far outweighs the pain of having to support and work around them in the future, essentially forever
  • #39696: REST API: Filter which links get embedded when passing the ?_embed query parameter
    • coming along nicely, but probably not as important for a point release

#4-7, #4-7-3, #dev-chat, #summary

Dev Chat Agenda for February 1st (4.7.3 week 1)

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

  • Schedule: no release date scheduled for 4.7.3, will begin to assess tickets this week and plan for release timing
  • Bug Scrub: 4.7.3 scrub on February 6, 2017 at 14:00 EST
  • Customizer team update
  • 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-3, #agenda, #dev-chat

Disclosure of Additional Security Fix in WordPress 4.7.2

WordPress 4.7.2 was released last Thursday, January 26th. If you have not already updated, please do so immediately.

In addition to the three security vulnerabilities mentioned in the original release post, WordPress 4.7 and 4.7.1 had one additional vulnerability for which disclosure was delayed. There was an Unauthenticated Privilege Escalation Vulnerability in a REST API Endpoint. Previous versions of WordPress, even with the REST API Plugin, were never vulnerable to this.

We believe transparency is in the public’s best interest. It is our stance that security issues should always be disclosed. In this case, we intentionally delayed disclosing this issue by one week to ensure the safety of millions of additional WordPress sites.

On January 20th, Sucuri alerted us to a vulnerability discovered by one of their security researchers, Marc-Alexandre Montpas. The security team began assessing the issue and working on solutions. While a first iteration of a fix was created early on, the team felt that more testing was needed.

Meanwhile, Sucuri added rules to their Web Application Firewall (WAF) to block exploit attempts against their clients. This issue was found internally and no outside attempts were discovered by Sucuri.

Over the weekend, we reached out to several other companies with WAFs including SiteLock, Cloudflare, and Incapsula and worked with them to create a set of rules that could protect more users. By Monday, they had put rules in place and were regularly checking for exploit attempts in the wild.

On Monday, while we continued to test and refine the fix, our focus shifted to WordPress hosts. We contacted them privately with information on the vulnerability and ways to protect users. Hosts worked closely with the security team to implement protections and regularly checked for exploit attempts against their users.

By Wednesday afternoon, most of the hosts we worked with had protections in place. Data from all four WAFs and WordPress hosts showed no indication that the vulnerability had been exploited in the wild. As a result, we made the decision to delay disclosure of this particular issue to give time for automatic updates to run and ensure as many users as possible were protected before the issue was made public.

On Thursday, January 26, we released WordPress 4.7.2 to the world. The release went out over our autoupdate system and, over a couple of hours, millions of WordPress 4.7.x users were protected without knowing about the issue or taking any action at all.

We’d like to thank Sucuri for their responsible disclosure, as well as working with us to delay disclosure until we were confident that as many WordPress sites were updated to 4.7.2 as possible. We’d also like to thank the WAFs and hosts who worked closely with us to add additional protections and monitored their systems for attempts to use this exploit in the wild. As of today, to our knowledge, there have been no attempts to exploit this vulnerability in the wild.

#4-7, #release, #security

Dev Chat Summary: January 25th (4.7.2 week 2)

This post summarizes the dev chat meeting from January 25th (agendaSlack archive).

4.7.2 Schedule

  • Reminder that no release date has been scheduled for 4.7.2 yet, we will assess tickets milestoned in Trac next week and begin planning for timing then.

Customizer team update

  • Please read two most recent posts: Customization in 2017 and Meeting Notes from January 23
  • Began scrubbing 198 tickets in customize component backlog to evaluate their priorities against the goals for the year, closing the ones that are no longer valid
  • We’re assigning tickets to the next minor release when they are defects or small enhancements that can be tackled in the next month
  • Larger enhancements that are aligned with the year’s goals which are not suitable for the next few weeks will be assigned to 4.8
  • The Future Release milestone is for tickets that should be done but which aren’t a priority for the goals of customizer this year
  • Looking for input on #39692 (Fix missing assignment of menus on theme switch), #39693 (Fix missing assignment of widgets on theme switch), and #35243 (Extending the text widget to also allow visual mode)
  • Big effort around #35760 (Provide API for TinyMCE editor to be dynamically instantiated via JS), so if you’re well-versed in TinyMCE please help
    • In summary, this will provide basic text formatting, links, and media embedding capabilities
  • If you’re looking for patches to contribute, please look at the defects milestoned for 4.7.2 that need patches
  • Continuing big picture design discussions about what the customizer should look like in light of conversations also happening with the editor

Editor team update

  • Please review the What Are Little Blocks Made Of? post and subsequent comments to get some insight into their approach on “blocks” as the focus this year

Trac Ticket(s)

  • #39256: REST API: Multiple issues with setting dates of posts
    • Not really possible to use the REST API to manipulate dates in a reasonable fashion
    • This is something we should fix ASAP before people start relying on the current, broken behavior
    • Please take a look, especially if you have experience with date handling in other parts of WP
  • #39466: Get list of post API request missing status
    • Should be a pretty easy win in 4.7.2
  • #39264: Add WP-API JS Client unit tests to core
    • Could use a review
    • Would love help automating the generation of the mocked data, ideally as a grunt task
  • #39072: Add gmt_offset as a REST API setting
    • Sort of related to date handling, a bit involved, doing it later isn’t so bad because it’s an addition rather than a change
  • #36574: Redesign term pages
    • Patch needs testing from Taxonomy team

#4-7, #4-7-2, #dev-chat, #summary