The WordPress core development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:
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.
The group decided to move the weekly meeting to Thursdays at 1900 UTC, which is more convenient for participants.
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]
image_downsize assumption changes: Added to 4.7.3 milestone for prioritized discussion.finfo_file() to all files uploaded.Our next meeting is scheduled at the new day/time of February 23, 2017 at 1900 UTC.
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.
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.
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.
GET request is made to site.com/wp-json/wp/v2/users/<id> and that user is not a member of the current site.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).
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!
This is the agenda for the weekly dev meeting on February 8, 2017 at 15:00 CST:
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!
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:
This is the agenda for the weekly dev meeting on February 1, 2017 at 15:00 CST:
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!
This post summarizes the dev chat meeting from January 25th (agenda, Slack archive).
This is the agenda for the weekly dev meeting on January 25, 2017 at 15:00 CST:
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!
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
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:
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:
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.
@rianrietveld had four items on the agenda for the second meeting.
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”.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.
This post summarizes the dev chat meeting from January 18th (agenda, Slack archive).
