Dev Chat Summary: May 23rd (4.9.7 week 1)

This post summarizes the dev chat meeting from May 23rd (agenda, Slack archive).

4.9.6 feedback

  • 4.9.6 was released on Thursday, May 17th thanks to the leadership from @desrosj and @allendav, heavy assists from @sergeybiryukov, @azaozz, and everyone over in #gdpr-compliance 🎉
  • Important developer and site owner topics included in 4.9.6 (New PHP Polyfills and Changes that Affect Theme Authors) all included within the 4.9.6 Update Guide
  • Auto updates were initially left off for 4.9.6 for about one day to evaluate incoming support requests and make sure there were no issues with the more than “normal” amount of code introduced
  • Initially some reports of users seeing a white screen on their sites, tracked to a small handful of plugins that were hooking into one of the new Privacy features using `init` instead of `admin_init`, and this was causing a very edgy edge case on some installs (see #44142)
  • Thus, auto updates have remained off for 4.9.6 to avoid more potential issues, documentation in the Plugin Handbook was updated with a notice describing that using `init` would potentially introduce problems on sites, and @ipstenu reached out to each plugin that was using this hook to inform them of the issue
  • Currently no plugins in the .org directory that implement the new privacy features incorrectly
  • As of devchat, auto updates have not been enabled and we need to plan when 4.9.7 should be released, and what it should contain
  • @matt reiterated that we’re going to put enhancements, new features, notices, and anything else we need into 4.9.x while we work on Gutenberg
  • Discussion on enabling auto-updates lead to agreement to do so; note that @pento enabled auto-updates ~4 hours after devchat

4.9.7 planning

  • Potential focuses: GDPR fixes, TinyMCE update
  • Leads: @sergeybiryukov able to help as deputy (e.g., committing, backporting); @danieltj, @desrosj, and @tristangemus open to help contribute during 4.9.7
  • Please comment on this post, ping @jeffpaul, or comment during the next dev chat for nominations (self or otherwise) for release leads on 4.9.7

Updates from focus leads and component maintainers

  • The Gutenberg team continues to iterate and shipped v2.9 on Friday, May 18th; check the release post for more details
  • The PHP team posted a summary from their meeting last week and welcome everyone to join their next meeting on Monday at 15:00 UTC when they’ll discuss whether there’s updates on the “Upgrade PHP” design review and discuss “Requires PHP” enforcement details

General announcements

  • @clorith: When making changes to twenty-themes we should note somewhere that we made changes to them in a release. Not everyone was happy about a theme update in 4.9.6 as well that added output to their footers. (related #44202)
  • @danieltj has also begun a proposal draft for Dark Mode on GitHub and is open to help, so please review if you’re interested/available

Next meeting

The next meeting will take place on May 30, 2018 at 20:00 UTC / May 30, 2018 at 20:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-6, #4-9-7, #core, #core-php, #core-themes, #dev-chat, #gdpr-compliance, #gutenberg, #summary, #tinymce

4.9.6 Schedule Changes

Last Thursday, 4.9.6 beta was released. In order to properly address all feedback received from beta testers, more time is needed.

After careful discussion, @desrosj, @allendav, @azaozz, and @sergeybiryukov have decided that to prevent any further set backs, both the 4.9.6 release candidate and 4.9.6 release by two days each.

The new schedule moving forward is as follows:

  • Release Candidate: Thursday, May 10th
  • Release: Thursday, May 17th

As previously detailed, 4.9.6 is not a typical minor release because of the inclusion of time sensitive features. In order to give site owners the personal data and information tools needed to be prepared for GDPR (General Data Protection Regulations) before the May 25th, 2018 effective date, these features cannot be removed to ship the minor version on time.

This decision was not made lightly. Deadlines are not arbitrary. However, it is important that the tools are ready and that translation contributors have enough time to localize the large number of new strings in the release.

Please continue to test the 4.9.6 beta package and provide feedback.


Dev Chat Summary: May 2nd (4.9.6 week 5)

This post summarizes the dev chat meeting from May 2nd (agenda, Slack archive).

4.9.6 planning

  • Decision to push beta back two days gave us enough time to backport all the things (thanks to @sergey for all the work there)
  • 25 tickets left in the milestone, aiming to get to 10 for beta, will likely punt non-GDPR tickets
  • Bug scrub tomorrow will be at 15:00 UTC instead of 17:00 UTC
  • @azaozz lined up to help package up the beta in Mission Control, process to begin at 20:00 UTC
  • Heavy discussion on where to introduce new menu items as part of #43873, four options outlined:
    • 1) All three under the Tools menu (currently how it is in trunk).
    • 2) The settings page under the Settings menu labeled Privacy, and the tools under Tools
    • 3) A new top level menu item for Privacy.
    • 4) Listing the erasure and export tools under Users, and the settings page under Settings.
  • Summary of decision:
    • Export and erase tools remain under tools
    • A settings page for Privacy Notice is added to the bottom of the Settings menu.
    • @melchoyce to follow up with feedback on that settings page.
    • @desrosj to create a ticket for the pointers needed for this work
  • Reminder that after beta ships tomorrow, RC will be up next on Tuesday, May 8th (see: 4.9.6 schedule)
  • Please feel free to drop into #gdpr-compliance to continue discussions or if you have some time available to help out before beta.

Updates from focus leads and component maintainers

Next meeting

The next meeting will take place on May 9, 2018 at 20:00 UTC / May 9, 2018 at 20:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-6, #core, #dev-chat, #summary

Dev Chat Summary: April 18th (4.9.6 week 3)

This post summarizes the dev chat meeting from April 18th (agenda, Slack archive).

4.9.6 planning

Updates from focus leads and component maintainers

  • The Editor / Gutenberg Team released v2.7 and published information on how they’re organizing component-specific issues in their GitHub repo. Component Maintainers will benefit from utilizing the specific milestone setup for their component when trying to identify areas that would best benefit Gutenberg. There are also additional milestones for a11y and docs.
  • The GDPR Compliance Team published notes from their recent meeting covering recent deployments, available resources, plugin dev guidelines, and the addition of a privacy section to the readme.txt file
  • The PHP Team published notes from their recent meeting
  • The Media Team published notes from their recent meeting covering a time change for their meeting (to Thursday’s at 20:00 UTC) and their main focus on a Gutenberg Media triage
  • @jorbin looking for a proposal on Make/Core post from team working on the JS reorg / no longer using srcwith a summary and proposed timeline; majority of current info is in #43055

Next meeting

The next meeting will take place on April 25, 2018 at 20:00 UTC / April 25, 2018 at 20:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-6, #core, #dev-chat, #summary

GDPR Compliance Chat Recap – April 11

(full text on slack)

First deploy of ticket #43481

  • Core ticket #43481 is about tabs and placeholders to privacy tools page in wp-admin and a first version has been committed into dev. Goal is to have it inside the 4.9.6 release.
  • These screens will allow the site admin to get validation from the requester follow-up on requests. Requests could come in from different sources (email, phone request, contact page, etc) so a dedicated place is needed.

Announcements: Available texts and where to publish them

Plugin dev guidelines

Privacy section in readme.txt

  • Besides the functions in Core and the upcoming filters/hooks that plugin authors will be able to use, there might also be a need to have privacy related info in the readme.txt
  • The advantages of a section in the readme.txt would be:
    • availability in plain text in downloads
    • parsable, can be displayed in tab on plugin repo
    • translation, since readme is in Core’s i18n tools on
    • Version control
  • The eventual section in the readme.txt will however not substitute the need of having the privacy information also delivered using filters/hooks as the purpose and possibilities are different.
  • Another idea was to add a ‘Privacy URL’ keyword where a URL could be provided to a privacy statement hosted on a website.

Trac tickets:!closed&keywords=~gdpr
GDPR agenda and recaps:

#gdpr-compliance #summary

GDPR Compliance Chat Recap – April 4

(full text on slack)

Documentation: what texts do we need?

  • A table of contents of the needed information is present on . @idea15 started on some of them.
  • Some shorter/other texts will be needed to add to core, but can then have links to the final privacy blog: WP default policy, text for new user registration and on user profile screen, technical text about the new functions for , chapter in the plugin handbook
  • After a chat with Mika, the guidelines for developers will be amended so that it's clear that plugins can assist in helping the site compliant but not that installing the plugin will make the site compliant.

Marketing: How to announce the project to the world?

  • @dejliglama reached out to the WhiP linking to make/core in their newsletter. There will be a longer piece later.
  • A paragraph was also create in the Month in WordPress of March
  • A proposal is to get a post out every 2 weeks with a major one on 25-May.
  • The roadmap can be used as a start, but might be slightly too technical for the broader public.

Trac Tickets: Review of specific tickets

  • #43492 was discussed. Data is stored for telemetry but also to make sure websites have the correct (security) updates.
  • A site admin should not have to opt-in, because having a WordPress site without security updates is not acceptable. But a combination of some data (like website URL, IP, etc) might be seen as personal data.
  • More clarification is needed. @pento and @pesieminski should be contacted.


  • Design should arrive in the next days so Allen and Mike can start with the patches for their tickets.
  • WordCamp Europe workshop: @idea15 will be hosting a GDPR Workshop at WCEU. She is looking for Teaching Assistants that can help her in making it a success. Please comment below (or DM on slack) if you are in Belgrade in June and are willing to support!
  • WordCamp Europe contributor day: @idea15 has been contacted to be ready for questions during Contributor Day (June 14 in Belgrade). Anybody willing to help @xkon, @azaozz and probably @postphotos on that day? Leave a comment or DM.


  • @idea15: Create a text for marketing (due 2018-04-08)
  • @azaozz: Follow up with Marketing for the above text
  • @casiepa: Add short texts needed in the table of contents

Trac tickets:!closed&keywords=~gdpr
GDPR agenda and recaps:

#gdpr-compliance #summary

Ain't no party like a GDPR party
Cos a GDPR party don't stop until someone has a question about personal data.
(Heather Burns)

Dev Chat Summary: March 7th (4.9.5 week 5)

This post summarizes the dev chat meeting from March 7th (agenda, Slack archive).

4.9.5 planning

  • @audrasjb and @danieltj to lead bug scrubs every Tuesday from 20:00 to 21:00 UTC
  • Planned release schedule:
    • Beta: 03/20
    • RC: 03/27
    • Expected release date: 04/03
  • Looking to move some 5.0 `good-first-bug` labelled tickets to 4.9.5 if they are already committed, self-contained, can be back-ported cleanly before milestoning, and don’t introduce any unintended backcompat issues

Definition of what’s included in minor releases && Gutenberg updates

  • @jbpaul17: Suggestion to expand what can go into minor releases and allow new files to be introduced as this could benefit projects being able to ship in a minor versus waiting for a major release/5.0 (e.g., serve happy, debug screen, on boarding improvements, GDPR compliance tools)
  • @jbpaul17: Question as to cons for doing so (e.g., breaking auto-updates) and whether they’re unsolvable technical problems or historical blockers that haven’t been researched recently and could potentially be resolved
  • Previous discussion on this topic related to inline docs
    • “Every extra file adds a significant amount of KB to the package, which adds up pretty quickly. This not only stretches the load balancers (when suddenly millions of sites are updating within an hour), but also each individual site, which must download the ZIP, which takes time (partial builds made things, on many shared servers, go from minutes to seconds) and introduces lots of possibilities of download failures, and thus sites needing to retry later (and wait longer) to get patched.”
  • Prior comment that although it’s a little inconvenient, it’s a handy line in the sand for backporting to prevent new files
  • @joemcgill: Important to get input from people familiar with and have access to the infrastructure and historical data about releases
  • Side conversation on altering version numbering scheme such that next major could be 4.10.0 and allow non-Gutenberg projects to land in a major release while Gutenberg can still have the 5.0 version number; alternative to switching to semantic versioning is pushing Gutenberg back to 5.1
  • @joemcgill: Important to clarify what we’re trying to solve: trying to release some new features that are blocked while we wait for Gutenberg/5.0. Suggestion: discuss the specific features and why they’re worth including in a minor and figure out the technical blockers to make that happen
  • @xkon: GDPR work is trying to avoid shipping with Gutenberg to ensure user-stress levels are low for these respective updates; in an ideal world GDPR should land before May 25th
  • @joemcgill: Helpful to understand the roadmap for 5.0 timelines to know if we should squeeze something in a minor release or do a vanity 4.9.10 major release
  • @matveb: Gutenberg plan is still tentatively April
  • @peterwilsoncc: Pushing new files into minors would require two releases:
    • 1 to update auto updates
    • 2 to update and include the new files for GDPR, serve happy, etc.
  • @sergey: precedent of adding new functions to existing files in a minor branch where they’re in separate files on trunk, same could apply for GDPR/etc.
  • @joemcgill: restating the problem… We have some features ready for release but are blocked by historical constraints on our minor release process, meanwhile we have no clear sense of when the next major is going to be ready because it’s tied to Gutenberg
    • Option 1: Change the constraints on a minor release and add the features. This needs input from infrastructure people
    • Option 2: Do a major release before Gutenberg is ready if we need to
    • Option 3: Wait for Gutenberg to be ready
  • Gutenberg team looking for more help in getting it ready for the path to merge proposal, getting a promo notice in a release to help increase testing
  • @azaozz: GDPR tools cannot wait very long. Will need to be out end of April, early May the latest
  • Gutenberg work divided into “feature complete”, “merge proposal” (things we definitely need), and “5.0
  • Gutenberg areas that need attention for 5.0 merge:
    • API tasks need owners.
    • All core issues should have corresponding tickets.
    • JS packages integration can be a topic for the core-js chats.
    • Gutenberg repo needs help with triage and fixing bugs.
    • Documentation and coding standard updates.
    • Accessibility needs to be improved
  • Various Gutenberg-related tasks could use help and don’t have to wait for merge proposal:
    • Various REST API tasks that can be done now in parallel
    • Core changes
    • New endpoints and infrastructure plans
    • How would inclusion of Gutenberg/JS packages work
  • Gutenberg team would like to see how integration with truck would work as early as possible, aiming for April for an initial merge/first beta (not actual 5.0 release)
  • Gutenberg team needs more component and lead developers focus and feedback

Next meeting

The next meeting will take place on March 14, 2018 at 21:00 UTC / March 14, 2018 at 21:00 UTC in the #core Slack channel. Please feel free to drop in with any updates or questions. If you have items to discuss but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#4-9-5, #core, #dev-chat, #summary

Dev Chat Agenda: March 7th (4.9.5 week 5)

This is the agenda for the weekly dev meeting on March 7, 2018 at 21:00 UTC / March 7, 2018 at 21:00 UTC:

  • 4.9.5 planning
  • Definition of what’s included in minor releases
  • Updates from focus leads and component maintainers
  • 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-9-5, #agenda, #core, #dev-chat

New Contributors Meeting Recap – February 14th

On Wednesday, February 14th, the weekly new contributor meeting was held in the #core Slack room. Here is a recap of the meeting. A full chat log is also available.

Participants: @adamsilverstein @abdullahramzan @aduth @chetan200891 @clorith @desrosj @dougvanslembrouck @jorbin @joyously @lakenh @notnownikki @thrijith @welcher @williampatton @xkon

Discussion Highlights

Contributing with Git

Even though every change to WordPress core must pass through Trac/SVN eventually, SVN is not the only option for creating patches.

See these articles for more intofmation on creating patches with Git:

Coding standards

An easy way to make your IDE/editor aware of the WordPress coding standards regarding whitespace usage is to use the .editorconfig file that trunk contains. This file uses a common standard, and there are plugins available for almost all popular environments that automatically parse the file and adjust the whitespace settings for the project.

Extensions can be found on the website of the project. Some IDEs like PHPStorm already come with built-in tools for the WordPress coding standards.

Refreshing a patch

Older tickets often have attached patches that no longer apply to the current codebase. The older the ticket, the lower the likelihood that the associated patch will apply cleanly. If you find a ticket with a patch that does not apply, add the needs-refresh keyword to indicate this.

Over time, code shifts around and sometimes these patches only need a bit of reorganization to apply. Other times, you may find code that has been refactored and needs an alternative solution for the proposed bug/enhancement. Once this has been done, create a new patch with the clean code and submit it to the ticket.

While refreshing a patch, it’s also a good idea to make sure the patch is what you would consider the best approach and to verify that it follows the style guide.

See Contribute with Code handbook article for more information.

Ticket ownership

Ticket owner is generally responsible for moving the ticket forward. From the handbook:

When working on a ticket, the Owner field is typically left blank, even if you have contributed a patch. Committers utilize the field to offer traction for a ticket, to identify they are investigating, committing, or otherwise following a ticket, or to tentatively accept the bug or enhancement for core inclusion. It is also common during the feature development phase for developers to accept tasks in the area of responsibility for which they have volunteered, as well as related bug reports. Trusted contributors may assign tickets to others based on an inside knowledge of who should be responsible for reviewing it.

For good-first-bugs, the person who submitted the patch is assigned as an owner so that the ticket shows as “claimed” in the queue.

It’s OK to drop ownership if the ticket is no longer relevant for you, just reassign it to an empty field.

See The Bug Tracker (Trac) handbook article for more information.

Tickets brought up

  • @notnownikki has been working with @iseulde and @azaozz on #43187, which comes from an issue in Gutenberg.
  • @williampatton asked for feedback on #42057, specifically opinions on introducing an additional parameter for a function in a minor release, and more eyes on back compat to make sure nothing is broken by the change.

Thanks to everyone who attended! As always, please feel free to leave a comment below or reach out to any of the moderators (@adamsilverstein, @desrosj, @flixos90, @sergeybiryukov, @stevenkword, @welcher) with questions on Slack. Or, feel free to reach out to any core developer or component maintainer with questions specific to certain core areas.

#core, #new-contributors, #summary

Media Meeting Recap – February 15, 2018


This post is a summary of the latest weekly Media component meeting, which took place in the #core-media Slack channel, on Thursday, February 15, 2018 at 1900 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.

@mikeschroder @antpb @blobfolio @flixos90 @jdub233 @sergey @desrosj @azaozz

Transcript: Read on Slack


  • The best way to follow along with media related Gutenberg items is the media label in GitHub.
  • Repository milestones have been re-arranged to make it easier to see what is going on.
  • Add block playlist: A discussion took place around how mediaElement should be added to Gutenberg. The two options discussed were to include it in the npm package list or make a global instance of Core's mediaElement Library. Consensus was to go with Core's implementation. @antpb is blocked on the playlist block with lack of mediaElement component. He is working on building a mediaElement REACT component that will need to be utilized in the audio and video blocks. Before this is complete enough to merge, he'll need some help understanding how to make the Core library globally accessible in Gutenberg.

5.0 Tickets

The next part of the meeting was spent on tickets in the next major milestone (5.0).

#33979 – Add filter for 'post_gallery_item'
#38228 – Add filter to default gallery shortcode output

Discussion around how granular gallery filters should be. With #3379 we gain a filter to add  styles individually per item in the Gallery. It was discussed that we will need tickets to add more granular filters going forward for captions and other image attributes. From @desrosj : "Currently the shortcode builds the HTML string as it goes. I think if the attributes were built in an associative array, that could just be filtered, and then the element built at the end. That could allow additional attributes to be added, widths to be changed for specific images making it easier to do different grid layouts." This sparked the question above around how Gutenberg will handle backwards compatibility with filtered attributes.

The following tickets need a combination of code review and approval:

  • #33979 – Add filter for 'post_gallery_item'

Seems good to go as a first step towards more granular Gallery filters if it won’t make it more difficult for Gutenberg to provide backcompat.

Next Meeting

The next #core-media meeting is set for Thursday, February 22, 2018 at 1900 UTC. Hope to see you there!

#core-media, #media, #summary