Rescheduling REST API meeting for this week

We’re rescheduling the REST API weekly meeting from February 20 (February 20, 21:00 UTC) to February 21 (February 21, 21:00 UTC). See you in #core-restapi!

Media Weekly Meeting Recap (Feb 17, 2017)

This post is a summary of the latest weekly Media component meeting, which took place in #core-media on Slack, on February 17, 2017 2000 UTC. The purpose of these meetings are to move priority tasks forward, provide feedback on issues of interest, and review media focused tickets on Trac.

Attendees: @joemcgill, @sergeybiryukov, @dnavarrojr, @adamsilverstein, @pputzer, @mikeschroder, @desrosj, @gitlost.

Meeting Time Change

The group decided to move the weekly meeting to Thursdays at 1900 UTC, which is more convenient for participants.

Tickets discussed

We spent this meeting doing a bug scrub for tickets on the 4.7.3 milestone.
Start: [https://wordpress.slack.com/archives/core-media/p1487361876001149]

  • #39883 image_downsize assumption changes: Added to 4.7.3 milestone for prioritized discussion.
  • #39774: PHP 7.1 warning during upload of file with the same name: 
Approved for merge from 4.8 to 4.7.3. @sergeybiryukov to handle it.
  • #37140: Reset of rotation orientation when image is rotated:
 @mikeschroder tested, found fix for issue in tests. Reached out to @sanchothefat re: whether the current number of images being tested can be reduced to not slow down the tests. Otherwise, this looks ready.
  • #39516: Media grid upload errors display below the grid:
 Still needs testing. @joemcgill would appreciate additional eyes here.
  • #39550/#39552: Some Non-image files fail to upload after 4.7.1: 
@joemcgill to write up two possible solutions for the problem to address image files not properly validated with GD so that we can profile appropriately. There are performance concerns around adding ⁠⁠⁠⁠finfo_file() to all files uploaded.
  • #39875: PDF previews overwrite existing images with the same name:
 Worked through this in chat. @gitlost uploaded one approach to the ticket, with @desroj writing up another one based on our conversation in the meeting. Decision being that the filename saves should be handled in the same way that saves happen in the Media Gallery’s image editor. The problem is in https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/image.php#L254, with pre-existing method in https://core.trac.wordpress.org/browser/trunk/src/wp-admin/includes/image-edit.php#L779.

Our next meeting is scheduled at the new day/time of February 23, 2017 at 1900 UTC.

#media, #weekly-update

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

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

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 wp-api.org to developer.wordpress.org
  • scrub tickets in the REST API trac component
  • open office hours

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

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

Dev Chat Agenda for January 25th (4.7.2 week 2)

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

  • Schedule reminder: no release date scheduled for 4.7.2, will assess tickets next week and begin planning for timing then
  • Customizer team update
  • Editor chat summary / visuals update
  • Review on #39256 (REST API: Multiple issues with setting dates of posts)
  • 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-2, #agenda, #dev-chat

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