Summary of Core Privacy Office Hours, Sept. 25th 2019

Below is a summary of the discussion from this week’s Core Privacy chat (agenda, Slack Transcript).

Agenda Item: 5.3 Bugs

The following tickets were flagged as bugs for 5.3 privacy component and focus;

  • #37782 – Duplicate Page Entry in View All Pages when generating a Menu
  • #43974 – Both personal data request processes should follow the same convention
  • #44038 – Change personal data export path stored in request meta to relative paths
  • #44314user_confirmed_action_email_content filter run on two different strings
  • #44669 – Privacy Notification doesn’t clear after dismissing notification_wp_privacy_send_erasure_fulfillment_notification.
  • #46829 – Denote the special pages in Customizer Menu editor
  • #47366 – Privacy Policy page dropdown needs a max-width

#37782 is ready to commit if any committers can provide a final review.

Agenda Item: Privacy Data Request Form

Feature Plugin Proposal –

We (@audrasjb & @garrett-eclipse) will be joining a future #meta chat to propose adding the plugin to the Feature plugins list.

Agenda Item: Consent and Logging Mechanism for User Privacy

Feature Plugin Discussion –

@idea15 mentioned there was some great comments on the thread many of which support the idea and proposal.

Next steps were discussed and @williampatton offered to review and start on the momentum for the work required.

@idea15 mentioned it would be nice to have the work ready to roll at least 60 days before the CCPA deadline believed to be on July 1st.

Agenda Item: WP User/Pro Survey

@idea15 flagged some earlier discussions on the survey with several questions put forth regarding user needs for privacy;

We also touched on that in the consent and logging proposal 

The consensus was that like other teams, we need data on what users and contributors actually need from us – what their concerns are, what their business needs are, what resources they expect from us, what tools they need us to build.

In this week’s post on the survey (above), which links to the full set of questions

There are no questions about user needs there, for us or for any other team.

It feels like all the feedback about what should go on the survey was ignored.

So, this is worrisome that the once-a-year opportunity to gain critical information to support our work is at risk of being lost.

So, let’s all take a day or two to review both posts and the draft script, with a goal to feedback with a team comment on Friday.

@idea15 started a gDoc ( in order to collaborate on some suggested questions for privacy.

#core-privacy, #privacy

Dev chat summary: July 17

@earnjam led the meeting. @marybaum took notes and is writing this summary.


Gutenberg 6.1

@earnjam announced the release of Gutenberg 6.1 last week. New features include animations/motion to block reordering, improved messaging for REST API errors and more.

Check out the release post for more details:

Look for version 6.2 RC to land next week.

PHP Coding Standards

@pento posted a followup to some proposed coding standards changes from a few months back.
See the decisions on these changes here (they might surprise you!):

And keep in mind these affect only the code for WordPress Core. In your own Themes and Plugins, use the coding conventions that make sense for you.



With four tickets in the queue and none of them affecting functionality, it’s still not clear that they warrant a separate 5.2.3 release. Scheduling for that is still pending further info on a roadmap for 5.3, which should land in early fall.


As yet the Core team is progressing on current open tickets — there are 57 in the queue — while @chanthaboune continues gathering data from component maintainers on feature priorities for 5.3.

Component maintainer updates


@azaozz asked for more eyes on #40439.

If you can help test, please check out the ticket or head to #core-media.


@clorith pointed to the call for input for bumping the PHP recommendation and said that soon a Make blogpost will outline next steps—and next versions.

For now, the site-health team isn’t looking to raise the hard minimum. This will be a soft bump up to nudge users toward the minimums that will follow.

Open Floor

Triage Team

@joyously asked about progress from the Triage Team, and the responses came from several quarters.

@desrosj posted a link to his three-month summary: and plans to post more often on

@karmatosed mentioned that Design holds two triages a week, and that from where she sits, triage seems to be going gangbusters and spreading across the WordPress Project.

@azaozz pointed the group to his efforts on TinyMCE:

@marybaum mentioned having been in an accessibility triage last Friday.

Gutenberg Phase 2

Newcomer @Lu asked about the timing of Gutenberg Phase 2, with a particular interest in widget blocks. @earnjam answered with a summary of the release discussion earlier in the chat.


@marybaum asked the group for their thoughts on a more systematic, global approach to the copy in strings.

For now, the group agreed to have #meta add two keywords to tickets—needs-copy-review and has-copy-review.

Props to @garrett-eclipse, who opened meta#4609 and its counterpart meta#4610 on the spot.

Right at the close of the official chat, @audrasjb linked to

#dev-chat, #gutenberg, #releases, #strings, #triage-team


The Block Registration API – status update

Build a directory for discovering blocks, and a way to seamlessly install them is one of the 9 priorities in the 2019 roadmap. This post tries to summarize work done so far and identify all the next steps required to land this project in WordPress core later this year.

It has been over two months since the Meta team published a post intended as a starting point for discussion and new ideas for the Block Directory, and a new type of plugin:

Put briefly, I’d like to propose a new type of WordPress plugin that provides blocks and nothing else: Single Block Plugins. These will be hosted in a separate Block Directory section of the Plugin Directory. They will be JavaScript-based, and each plugin will register a single Block. And they will be searchable and installable from within the Gutenberg editor itself.


Currently, new Gutenberg blocks can be provided by plugins, which often register many blocks, and which are managed from outside the editor. The proposal mentioned above outlines a new type of simple block-based plugin that is intended to be seamlessly installed from within Gutenberg itself. It was later followed up with the call for design on installing blocks from within Gutenberg. There was an essential technical aspect highlighted in the post:

The API will provide an endpoint for searching for blocks by name and description, and return metadata similar to that of plugins. Gutenberg’s Inserter could use that endpoint to also show relevant block plugins that are available to install, with a button and process for seamless installation.


This new endpoint is going to be based on the Block Registration API RFC which intends to address the server-side awareness of blocks and simplify the block discovery for the block directory project. In practical terms, it means that we are seeking for a solution where block type registration is declarative and context-agnostic. Any runtime (PHP, JS, Android, iOS or other) should be able to interpret the basics of a block type and should be able to fetch or retrieve the definitions of the context-specific implementation details.

Core Editor team reached the point where we believe that the Request for Comments is close to being finalized. However, there are still some areas where we feel that other WordPress teams could have a significant impact on the proposal.


The way how translations are handled inside JSON files is something novel for WordPress core. The current proposal for PHP follows the existing get_plugin_data core function which parses the plugin contents to retrieve the plugin’s metadata, and it selectively applies translations dynamically. It would be also similar for JavaScript, with the remark that we plan to implement a custom Babel plugin which would mirror PHP behavior for ESNext code. The transformation would happen during the build step to ensure that files can be statically analyzed before scripts are enqueued. You can find more details in RFC document in the Internationalization section. There is also an issue#15169 opened which describes the technical details of the proposed JavaScript implementation of the Babel plugin.

Core JS team discussed this topic at the end of the weekly meeting on Apr 2nd. We have received great feedback from @swissspidy which helped to shape the proposal. However, we still encourage other Polyglots team members to voice their opinions.

New REST API endpoints

The long term vision for the block discovery in WordPress includes:

  • Fetching the available block types through REST APIs.
  • Fetching block objects from posts through REST APIs.

The proposed implementation for the server-side awareness of block types should ensure that it stays intact with all recommendations that REST API team might have. That’s why we encourage the REST API team to get involved in the process early on. There is no immediate need to start working on new block type related API endpoints. However, it would be great to have it included on the roadmap. Ideally, they should stay as close as possible to the API and the final shape of the endpoint for searching for blocks.

#block-directory, #core-editor, #gutenberg, #i18n, #meta, #rest-api

Editor chat summary: May 15

This post summarizes the weekly Editor meeting on Wednesday, May 15, 2019, 4:00 PM GMT+3 held in Slack.

The agenda followed can be found here.

Gutenberg 5.7

Gutenberg 5.7 was released today, congratulations to everyone who participated in this release!

Gutenberg Docs are now in the WordPress DevHub

You can check this out at:  They have also been reorganized for better navigation and discoverability. Props to @nosolosw @chrisvanpatten @coffee2code @mkaz @kenshino.

WordPress 5.3 planning

During the previous dev chat the scope of the WordPress 5.3 was discussed. Today @youknowriad asked what can we get into that release from the Core Editor team.

@youknowriad, @aduth, @joen, @getdave proposed new Gutenberg features and updates to land in  WordPress 5.3 (to be released in late August):

Improvements we can safely expect:

  • Columns Block Resizing
  • Group Block (new block)
  • Nested Block Selection improvements
  • Table Block
  • UI improvements: Micro-animations, publishing flow tweaks, Snackbar notifications
  • Selecting parent blocks with clickthrough
  • Block Grouping

Big subjects and uncertain features:

  • A Navigation Block
  • A new widgets screen
  • The Block Registration API relying on block.json


  • @mapk expressed concern over committing to landing a Navigation Block in WordPress 5.3 because of a lacking clear place to use the block once it becomes available in the Inserter.
  • @youknowriad expressed hope that we’ll soon have a « widgets screen » prototype in the plugin and clarify whether this can be part of the release or not.
  • @gziolo: Beta 1 is the deadline for new features which means late July to have everything ready

Task Coordination

Explicit Draft statuses for RFCs

There is an increasing worry over the current state of the Widgets RFC because it is hard to make sense of it, or to follow developments as it’s now at over 170 comments. It became a good example that when trying to devise the perfect all-encompassing plan, discussion can become fragmented, we lose sight of the larger goal, and momentum halts.

There was as lively discussion about this and @youknowriad identified the following actionable steps:

To handle multiple merged RFCs @aduth proposed we’d have a Project board with a column for each RFC, and each column would contain issues or PR’s that affect that column’s RFC.

A second Gutenberg triage session that is more APAC timezones friendly

The proposal is to have a second Gutenberg triage session around 06:00 UTC, every two weeks, in the slack #core-editor channel, but no day is yet. @danr, @noisysocks and, @andraganescu would attend/run the sessions and we’d love it if others could join/help. The reasoning is that many struggle to attend meetings or triage sessions due to timezones, so this would be a chance to get involved at a more comfortable time of day.


  • the general feeling was that it’s a good idea and that it should happen.
  • @youknowriad suggested it could include new contributors help


Have thoughts on the above? Please leave a comment on this post!

The agenda for the next meeting, on Wednesday, May 22, 2019, 4:00 PM GMT+3 , is here; please add anything that you want to discuss.


The Block Registration RFC and the Gutenberg RFC process

While Slack is a critical tool for keeping in sync for project status and priorities, it has proven to be an ineffective platform to engage in detailed, long-lived discourse around complex engineering problems.

Inspired by other open source projects like React, Yarn, Rust… we started experimenting with a new RFC (Request For Comments) process in the Gutenberg repository in order to propose, discuss and adopt technical solutions for these big features or complex technical challenges.

The Block registration RFC

The first open RFC in the Gutenberg repository concerns the Block Registration API and intends to address the server-side awareness of blocks and simplify the block discovery for the block directory project.

The block registration API is the most important API in the block editor with a lot of technical challenges. Its implementation should fulfill a number of requirements:

  • A block type registration should be declarative and context-agnostic. Any runtime (PHP, JS, or other) should be able to interpret the basics of a block type (see “Block API” in the sections below) and should be able to fetch or retrieve the definitions of the context-specific implementation details. The following things should be made possible:
    • Fetching the available block types through REST APIs.
    • Fetching block objects from posts through REST APIs.
    • This API should be backward compatible with what we have at the moment.
    • It should be possible to statically analyze a block type in order to support advanced use-cases like the block discovery required by the Block Directory project.
  • It should not require a build tool compilation step (e.g. Babel, Webpack) to author code which would be referenced in a block type definition.
  • It should allow to dynamically load (“lazy-load”) block types, or parts of block type definitions. In practical terms, it means that the editor should be able to be loaded without enqueuing all the assets (scripts and styles) of all block types. What it needs is the basic metadata (title, description, category, icon, etc…) to start with. It should be fine to defer loading all other code (edit, save, transforms, and other JavaScript implementations) until it is explicitly used (inserted into the post content).

This RFC has already received a lot of feedback and technical explorations already started to clarify feasibility already started but I’d like to encourage everyone to chime-in and share thoughts.

What type of features/problems should be submitted as RFCs

All ideas/PRs/proposals require discussions before moving to implementation. When the proposed changes are small then a GitHub issue is fine but in addition to the block registration API, all the features and technical problems with impact across different areas of the code base, new patterns for extensibility APIs, technical problems that are hard to solve without making compromises are good candidates for RFCs.

Some examples for the Gutenberg project include:

  • The Block Registration API.
  • The Block Invalidation and Deprecation handling.
  • Block areas storage mechanism and widgets migration.
  • Block Bahaviour reuse (colors, alignments…).
  • Responsive Image Handling and Block Alignment awareness in nested contexts.
  • Editor Styles.

The RFC workflow

The flow to propose a new RFC is the following:

  • Create a RFC document for your proposal.
  • Submit a pull request to the Gutenberg repository (markdown file added to the `docs/rfc` folder).
  • Discuss and incorporate feedback into the PR
  • After discussions in the weekly meetings, RFCs may or may not be accepted.
  • If the RFC is accepted, the PR is merged.

Accepted RFCs means the proposed feature is approved for implementation. Once implemented, the RFC becomes the de-facto documentation for it.

What makes a good RFC document

A good RFC document can be broken into the following sections:

  • Description of the problems solved by the RFC
  • Current status and previous attempts
  • Solution Proposal
  • Unsolved Problems

Who can submit an RFC

Anyone can submit an RFC.

We’re looking forward to start receiving RFC proposals!

#core-editor, #gutenberg, #meta

Site Health Check Project review at WCUS

This is a verbose set of notes to record the discussions that took place at WCUS and to reflect the work that has been done across multiple teams.

The Site Health Check project is a collaborative multi-team project with a focus on encouraging better site maintenance.

This project benefits not just WordPress users, but also the surrounding PHP ecosystem as a whole. Our hope is that this will prompt a lot of PHP updates across the web.

It started as a project to focus efforts on getting users to update their hosting version of PHP from 5.2 to something where the End of Life has not already passed.

The project was initially called ServeHappy, homage to the BrowseHappy project which was a global tech effort to move away from Internet Explorer 6. The problem with the project name was that, when tested with users who did not know about the ins and outs of the project, the name was confusing and was not clear what the project’s intentions were.

The project is now known as the Site Health Check project. It encourages and hints to users that if they run a website, they should have a routine of checking and updating not just WordPress but underlying technologies that the site is built on. It also builds positive website ownership and habits.

The project is split into what can be considered 3 parts – changes to WordPress core itself, a site health check plugin and the site health check community support.

Upcoming changes to WordPress Core

The core-centric side of the project still reflects the Servehappy origins. This includes:

  • An information page on explaining the importance of updating PHP. The team has been working on improving the language used to benefit non-technical people and have clear instructions of what to do if they find out their site is running an old version of PHP.
  • A dashboard notice that will inform users if their site is running on a PHP version that WordPress considers outdated and plans to drop support for in a future update.
    • The version shown in the dashboard is API-driven which means that WordPress leadership has a centralized “knob” to tune the PHP version distribution.
    • The dashboard includes a link to which has generic information on what the notice means and how to update PHP on their servers.

  • There will be an environment variable or a filter which allows hosting companies to modify the link to the “Update PHP” page on their servers so that it goes to something more relevant for their customers.
    • There are some concerns of security problems and abuse over the link redirection.

  • The team has been working on a feature to add white screen protection, which the hosting group felt was helpful and cool. The white screen protection catches any fatal errors that a PHP update might produce. From the front facing side of the website, the site will still be white screened, but with the protection in place, the user can still access the admin panel.

  • There was a discussion whether it would be better for the site to be slightly broken rather than completely broken, but the general consensus was that it is better to white screen because from the Core Team perspective, they cannot be sure of what the PHP error causes, and thus can’t be sure that all the information being shown is meant to be public.

    It is better to white screen the whole website but ensure that access to the admin panel is still accessible. Once logged in, there will be a general notification regarding the WSOD.

PHP minimum required headers


For a while, WordPress plugins have been able to set a minimum PHP required comment as part of the plugin header. To date it has not done anything but set the intention that the plugin author is able to declare what PHP minimum version they are willing to support.

Work is being done so that the Add New Plugin admin screen will show all plugins a user searches for, but will not be able to install any plugins that require a newer version of PHP without updating that first. Another task being worked on is blocking plugin updates if the newer version requires a higher version of PHP, same as it currently works if the update requires a higher version of WordPress.

This gives plugin authors better control of what PHP versions they are willing to support, and will hopefully encourage people to upgrade their version of PHP at the same time.

This change will allow plugin authors the choice to use more modern PHP functionality and syntax without worrying their plugin will break for the end user.


For themes, the Requires PHP header is not implemented yet, as they didn’t have the same readme.txt file up until recently:

Now that new themes do have that requirement, there is an expectation that the header will be implemented as well in the foreseeable future. Here’s a ticket for that: #meta-3718

Relevant Trac Tickets

  • #43986 Disable “Install Plugin” button for PHP required version mismatch. This has already been committed to core.

  • #43987 Block plugin updates if required PHP version is not supported – Plugins screen

  • #44350 Block plugin updates if required PHP version is not supported – Updates screen

The latter two trac tickets are currently slated for 5.1 as well, planned for February 21:

The feature merge deadline is January 10 though, so it needs to be discussed at the next #core-php meeting whether making it into 5.1 is still feasible.

A prerequisite for these changes is the WSOD protection that needs to be completed and committed by the deadline: #44458

Join in

The group has weekly meetings on Mondays 16:00 UTC on in the #core-php channel of WordPress Slack.


Site Health Check Plugin

The site health check plugin is a way for users to be able to see technical details of their website setup without going into the server side of things. It is useful to conducting top level investigation work without accessing the server directly.

The beta version of the plugin takes the best practices from the Hosting Team’s documentation and checks the server against that. This includes: WordPress version number, plugins and themes are up to date, PHP version number, if HTTPS is active across the whole site as well as a number of other things.

When Health Check gives notifications about upgrading things, it hands users off to plain English documentation to walk them through the process. For example: Notifications for plugins and themes being up to date are based on the version inside the plugin and theme repo. If a theme or plugin is not present in the repo, it will assume it is up to date and will not give an error.

Eventually, a lot of the Site Health Check plugin will be in core.

The Site Health Check Plugin uses a traffic light system to flag up the importance of a suggested change. The definition of critical vs non-critical update notifications is from a security perspective. If it is a security issue, it’s critical.

Early user testing with the community has shown that the plugin suffers from a lack of designer eye. During WCUS, we have had a designer volunteer to review the interface and give feedback.

This should help with the usability of the plugin and balance it between positive reinforcement of things that are set up as guided by best practices whilst not over-burdening people with extra technical information.

There is some useful documentation on how to use the Site Health Check Plugin:

Join in

– Github:

– :

Site Health Check Desks & Community Support

In-person support is invaluable. When a user is unsure of what to do, they can find in-person support at their local meetup and WordCamps. To omit any surprises, we can encourage our community to pre-warn and prepare as many people as possible.

The idea of Site Health Check desks has been tested in 3 different WordCamps and 1 meet-up with improvements and suggestions being fed back to the plugin and fliers.

Site Health Checks is an extension of the Happiness Bar, and by asking the simple question “Do you know what version of PHP your website is running?”, people either:

  • Know & it is up to date – get a high-five. Say Awesome and keep up the good work. Pre-warn the next EOL of PHP Dates.
  • Know & it is out of date – highlight the EOL date has already passed and recommend they update their PHP version.
  • If they don’t know, Check if they know how to check. If they do, suggest that they check and that they want it to be 7.2 or higher. 7.1 EOL is in a year.
  • If they don’t know and don’t know how to check, invite them to sit down and the volunteers can help them check using the Site Health Check plugin. DO NOT scrape the site. They can end up being blocked off the servers.

Postcards were created with 5 core things to check. As well as printable table toppers. They are used as fliers for people to know where to download the site health check.

Meetup organisers have also shown an interest in running the site health check and promoting it at their meet-ups.

This is where much of the user testing of both the “Update PHP” information page and the Site Health Check plugin is happening.

Plugins and Themes Plans

Plugins and Themes served from can be automatically checked and updated to be compatible with 7.X. This is because there is access to the SVN where these plugins are being pushed from.

Ideally, plugin authors who have a plugin in the plugin repo will update their plugins to be compatible with PHP 7.X. There are already plugins such as the PHP Compatibility Checker which people can use to check how compatible their websites are with a version of PHP.

How are premium plugins and themes going to be handled?

The plugin team at can contact authors, but ultimately it is up to the plugin author to action the suggestions that are made from the team.

If there is no answer, or the author does not wish to fix errors, then this is a dead end.

Target Dates

WordPress 5.1  ->  ServeHappy notice + White Screen of Death protector

WordPress 5.2 ->  Site Health Check plugin

Where hosting companies come into play

We would like hosting companies to go aggressively, pushing their communities forward before WordPress does.

We know that, as a hosting company, many of you will see the same issues come up during a PHP update. It would be useful to the rest of the group if any information of any PHP errors that are being seen repeatedly and information about which plugin or theme is causing it. It will allow the rest of the team to prioritise which plugins and themes need attention to be fixed across the whole community.

It will also help the support team if any solutions are found to be shared, so that they know what to be suggesting in the forums. We may be able to add notices before a PHP update into the health check which highlights problematic plugins.

Hosts with PHP lower than 5.6 may see some initial notifications before that date.

Hosting company teams are most likely to know other people working in the hosting sector. Above all else – get the word out.  Big hosts are represented well here, but as a community we are aware and worried about the smaller, independent hosters. Talk to your hosting friends. Let them know this is coming. Invite the small hosting companies to join the Hosting Team on for up to date information of what is upcoming and will be effecting hosters.

The more we can update in batches the less burden there is across the whole industry.

Where plugin and theme authors come into play

If plugin and theme authors ensure that their plugins have a PHP minimum version set in their required header, then their plugins and themes will be ready once the PHP requirement is being enforced.

Plugin and theme authors should also ensure that their plugins are compatible with PHP 7.X. Tools such as PHP Code Sniffer (PHPCS) or the PHP Compatibility Checker as mentioned above should help.

Actions from the meeting

– Ensure there is communication with the hosting team regarding release date plans.

–  #core-php should be cross posting ServeHappy notes to the Hosting P2 as well.

– has been taken, unsure by who. It would be handy to have symlink to Hosting Team P2 to help getting other hosting companies to join the Hosting Team

– Recommend that Hosting Team check and sync up the Best Practices documentation.

– Can someone from the hosting team please review and ensure that Health Check plugin is checking against everything that exists in the “Hosting Best Practices” doc.

– Recommended to Health Check plugin to check out Lighthouse plugin UI.

– Write up more in-depth info for meetup and WordCamp organisers, have postcard and table toppers online so they can be shared and translated easily.


The effort to raise the minimum PHP version requirement of WordPress is a big cross- team effort. Big thanks to

  • @brettface for the notes.
  • #core-php, #plugins, #themes and #meta team for their hard work
  • the #hosting team for their input and support
  • @alexdenning from #marketing team for the content review
  • @clorith from #forums for the health-check plugin development
  • WordCamp London 2018, WCEU 2018 and WordCamp Brighton 2018 organisers for allowing us to test the Health Check help desk concept
  • And to the #polyglots team who will be asked in the near future to translate our work for the whole community.

#recap, #servehappy, #wcus

PHP Meeting Recap – October 22th

This recap is a summary of our previous PHP meeting. It highlights the ideas and decisions which came up during that meeting, both as a means of documenting and to provide a quick overview for those who were unable to attend.

You can find this meeting’s chat log here.

Chat Summary

    • We started discussing roadmap and priorities for Servehappy. It was not clear for everyone what the current state of the project is. Based on latest information we had, we settled on the fact that Servehappy is still considered a blessed task and that it was just moved out of 5.0 because of time constraints. Current goal is to get it included in a minor release following 5.0, as already suggested by the 5.0 release lead.
    • There’s an immediate need for getting more testers to actually test WSOD protection on real, complex sites with multiple plugins and custom code.
    • We discussed including the WSOD protection fork in the beta tester plugin so people can easily switch, but this would violate the plugin repository guidelines.
    • We also discussed what it would entail to commit it early into trunk to get it to run on the infrastructure. We should create a #meta ticket to discuss the details of this.

Next week’s meeting

  • Next meeting will take place on Monday, October 29th, 2018 at 15:00 UTC in #core-php.
  • Agenda: Continue discussion about getting more people to test WSOD protection.
  • If you have suggestions about this but cannot make the meeting, please leave a comment on this post so that we can take them into account.

#core, #core-php, #servehappy, #summary

JavaScript Chat Summary – July 3rd

Below is a summary of the discussion from this week’s JavaScript chat (agenda, Slack transcript).

Participants: @abdullahramzan, @adamsilverstein, @aduth, @afercia, @atimmer, @bpayton, @euthelup, @gziolo, @herregroen, @lonelyvegan, Jorge Costa, @omarreiss, @nerrad, @netweb, @pento, @sharaz, @schlessera.

Have a topic for discussion for the next meeting? Leave a suggested edit on next week’s agenda.

Deprecation Strategy

(Continued from last week’s discussion)

Problem: How can we introduce breaking changes necessary for user benefit without sacrificing a commitment to backward compatibility?

A deprecation strategy proposal has been discussed. Some highlights:

  • Proposal to Include a link to the specific documentation surrounding a deprecation (similar to React).
  • Console logging turns out to be not entirely successful on its own based on the experience from Gutenberg.
  • Feedback collected should be integrated into the UI, ex. Admin bar, Updates screen.
  • For those plugins that are using a recommended set of core build tools, issues could be surfaced there.

Action items:

  • Chat to #meta about logging all deprecations.
  • Discuss Admin bar notifications integration with @johnbillion, who authored Query Monitor plugin.
  • Logging to is also something that should be discussed with the #core-privacy team to make sure we start out in a compliant fashion.

Discussion is going to be continued next week.

Sunsetting the Packages Repository

Last week it was decided in our meeting to merge WordPress/packages repository to the WordPress/gutenberg repository. There is an open pull request at which is almost ready to land. We are waiting for Gutenberg 3.2 release to ensure it doesn’t interfere with the development cycle.

Next steps:

  • Fix the problematic test suite which started to fail on Travis after it was moved to Gutenberg.
  • Merge in the latest changes added in Gutenberg.
  • Test, review and deploy!
  • Ensure all opened issues, PRs , and missing docs are moved over to Gutenberg repository. @netweb started it already.

Core CSS

@omarreiss gave update on core CSS reorganization. Mostly the same as the JS effort, but smaller scope. The current idea is to unify the CSS in a `src/styles` directory with a ` css` and a `sass` directory. We discussed the following:

  • Is Sass the right path forward or should we move closer to native CSS with something like PostCSS?
  • There were previous discussions with @helen in the past on further refactoring CSS to use native CSS with PostCSS rather than Sass/SCSS.
  • How do we deal with styles reuse in a components era? There are similar ongoing efforts in Gutenberg started by @youknowriad in

Code Style

There have been new proposals with regards to code styling:


  • Let’s move forward with quotes exception following the related PHP standards.
  • @aduth is going to add more explicit rules around acronyms at start of variable name and leave the rest as initially proposed.

Dev setup

It’s been requested that two core Trac tickets receive approval:

  1. Make sure all JS globals are explicitly assigned to the window:
  2. Move all JS build config to Webpack:

@netweb volunteered to review item (2). It was also noted that (2) depends on (1).


You might notice that this P2 has gotten…

You might notice that this P2 has gotten a big head. All of the Make P2s have actually, and like the rug in the Big Lebowski we think it really ties the room together.

The Get Involved tab has been added, docs have been moved under support, home has been hidden. This isn’t ideal — we’d eventually like to move to more of a verb-oriented navigation system — but it is better than everything under Make being its own island and not really linked to or from the main side, or to each other. Hopefully it will also let more folks know about how to get involved (I added a link to the Make Core Handbook to the top sidebar widget.)

I’ll be talking more about some of the improvements to tomorrow at 11am PST and you can still get streaming tickets if you’d like to tune in:

#meta, #wordpress-org