Core-privacy agenda – 17 October 2018

This is the agenda for the weekly #core-privacy meeting on Wednesday 17 October 2018 at 1500 UTC:

Roadmap issues

Team issues

  • Group definition: Are we a core component? A component? A team? @idea15
  • Group lack of visibility and consideration: how do we get more of it within and outside the project regardless of how we are categorised? @idea15

Group meta issues


Introducing Twenty Nineteen

Gutenberg grants users an unprecedented level of freedom to customize their site’s layout and design. In order to fully achieve their vision, users will need a new generation of flexible themes, built to take advantage of the creative freedom that Gutenberg offers.

With that in mind, WordPress 5.0 will launch with a brand new default theme: Twenty Nineteen. The theme will be led by @allancole, supported by @kjellr as a design coach.

Twenty Nineteen Theme, Blog Post Example
Twenty Nineteen Theme, Homepage Example

Full page mockups: Low-resHigh-res
InVision prototypes: Post Desktop, Post Mobile, Homepage Desktop, Homepage Mobile

At the core of Twenty Nineteen is its simple, sophisticated typography. The theme’s aesthetic is minimal and non-prescriptive, allowing the theme to work well in a variety of applications. For example: it is effective as an minimal, typography-driven blogging theme, but can also be adapted for use as a static business website.

Twenty Nineteen will ship with full Gutenberg support. It will include both front and back-end styles, so that users can be fully confident in their site’s appearance when they hit publish.

Twenty Nineteen Theme, Gutenberg Editor Styles Mockup


As mentioned in the release plan, WordPress 5.0 will be released on November 19th, 2018, so this is a faster-than-usual theme build. The first release candidate is estimated for the end of October, so we’ll want to have a working version of the theme ready by then. Because of time limitations we may remove Twenty Nineteen from 5.0 if it is not ready in time for launch.

Get Involved

If you are interested in contributing, please be sure to follow this blog. During the design and development process, there will be weekly half-hour meetings every Tuesday at 16:00 UTC in #core-themes, beginning today, October 16, 2018.

Theme development will happen on GitHub and in the interest of time, an in-progress version of the theme code has been uploaded here: Once the theme is stable, it will be merged into core and the GitHub repo will be depreciated.

Some notes:

  • The theme is based on both _s and the gutenberg-starter-theme.
  • SASS is used in some key areas which has been helpful for keeping styles in-sync between the Gutenberg editor, and the front-end experience. This is not usual for a default theme and open to debate.
  • There is plenty of work left to do too and issues will be created in the coming days to help guide the process.

Learn more

If you’re interested in learning more about default themes, you can read the following posts:

WordPress and PHP 7.3

PHP 7.3 is in the final stages of its release cycle. As of the publish date of this post, version 7.3.0RC3 has been released and the final release of PHP 7.3.0 is scheduled for December 13th.

As the changes in PHP 7.3 were solidified earlier this year, contributors to WordPress Core worked to identify compatibility issues within the codebase. Overall, the changes needed to declare full PHP 7.3 support are minor, and are all being made.

WordPress aims to fully support PHP 7.3 in its next release.

Here is a breakdown of the changes in PHP 7.3 that plugin and theme developers need to be aware of and should accommodate in their code.

New Function: is_countable()

It is considered good practice to validate variables before using them. Parameters passed to functions may not be of the variable type expected. Similarly, the type of variable returned by a filter may have changed due to incorrect usage of the filter by plugins or themes.

In PHP 7.2, a warning was introduced when count() is used on an uncountable value. PHP 7.3 introduces the is_countable() function to help detect if a variable is in fact countable. This, paired with is_iterable() (introduced in PHP 7.1) allows developers to better follow this best practice.

In WordPress 4.9.6, two polyfill functions were introduced to help developers follow this best practice regardless of the PHP version a site is running. Using these functions in your code will ensure warnings are not triggered when sites are upgraded to newer versions of PHP.

Undefined Variables and compact()

compact() is a function in PHP that creates an array of values from a list of variable names. If an undefined variable is specified, the resulting array will not contain an index for that variable. This could cause some unexpected behavior due to missing indexes and some scenarios that are difficult to debug.

Starting in PHP 7.3, a notice will be triggered when an undefined variable is passed to compact() to help with identify such situations.

switch() and continue

In PHP, applying continue to a switch() statement causes the same behavior as break. However, in other languages, using continue within switch() statements will continue the surrounding loop instead (the equivalent of continue 2).

Starting in PHP 7.3, a warning will be generated when using continue to target a switch() control structure (break should always be used instead). The two instances of this pattern in WordPress Core have been corrected.

while ($foo) {
    switch ($foo) {
        case "bar":
            continue; // This now throws a warning.
            break;    // Use this for equivalent behavior.
            continue 2; // No warning, correctly targets the while loop.


As always, reading through the complete upgrade document is highly recommended.

Even as WordPress Core continues to expand its support for new versions of PHP, there is no intention of abandoning support for older versions until usage numbers show that the impact on users will be minimal. If you wish to help with this, an effort to decrease the usage numbers for older versions of PHP is being lead by the #core-php team through the servehappy initiative.

WordPress continues to encourage all users to run the latest and greatest versions of PHP, including PHP7.3 upon its official release.

A full list of tickets related to PHP 7.3 support can be found on Trac.

Granular Timeline

As promised, here is a link to the list of dates I am tracking. I asked every named component lead in the release post what items/dates could block progress in their focus.

A few pieces of context that will be helpful as you look at this document:

  • My work is focused on the 5.0 release, so those are the items I have in this document.
  • Not every item or date is included, generally because it has no contingencies.
  • Not everyone has given me their items and/or dates yet. There is some educated guessing happening in here.

This document is updated every day and I’ll post regularly with notable changes, including any items that are at risk so that people will have an idea of where they can focus their time.

A few people in the chat this week raised their hands with things that needed to be added to this doc. Feel free to leave them in the comments and I will either add them or share where they are already accounted for.

What’s new in core-privacy

Below is a summary of the discussion from this week’s #core-privacy chat. You can read the chat in its entirety in Slack. This summary highlights current work and also provides a view into how this relatively new team is working together to further privacy awareness following the success of its V1 GDPR-specific focus.

Ticket milestone changes

As a result of 4.9.9 being removed from the schedule in favor of a Gutenberg only 5.0 release, 25 core-privacy tickets scheduled for 4.9.9 have been punted to either 5.0.1, 5.1, or Future Release. These included some which were already committed to trunk and backported to 4.9.9, as well as some marked commit which will not be shipped with 5.0. Each ticket will be reviewed and evaluated for release with either 5.0.1 or 5.1. Each ticket can be re-milestoned when the scopes and timelines of these releases become more clear.

Impacted tickets include #44038, #44044, #44051, #44081, #44084, #44135, #44175, #44179, #44267, #44314, #44550, #44621, #44644, #44669, #44674, #44677, #44707, #44723, #44761, #44822, #44833, #44901, #43438, #44233, and #44236.

The component’s focus until post-Gutenberg will shift to the (currently) 31 bug tickets, with a goal of marking at least 75% of them as ready for commit.

@allendav and @desrosj will also use the feature and enhancement freeze to address #43895, which aims to properly organize the privacy code introduced in 4.9.6 within the codebase.

A full list of privacy tickets can be found in Trac.

Bug scrubs are led by @desrosj every Monday. The next one will be held October 15, 2018 at 15:00 UTC in the #core-privacy room on Slack.

Future major release

There was agreement that advocating for Privacy to be a focus for a future major release (possibly 5.2) would be very helpful to land the features outlined in the V2 roadmap. The timing of two pieces of legislation of particular interest would potentially coincide with that release schedule, allowing those features to be shipped prior to the effective dates.


The V2 roadmap moves beyond the enhancements and fixes to the V1 GDPR privacy tools to address general areas of privacy and data protection outside legal requirements. Its scope includes:

  • Core privacy features
    • Gravatar privacy controls
    • Embed privacy controls
  • Plugin privacy
    • For administrators
    • For developers
  • Consent and logging
  • WP-CLI support
  • Multisite support

This week, those in attendance agreed to add two upcoming privacy issues within legal requirements – the US California Consumer Privacy Act (CCPA), and the EU ePrivacy Directive overhaul – to the roadmap. It is anticipated that these two pieces of privacy legislation will create the most obligations for WordPress site administrators in 2019. Team members will continue to monitor each law carefully. Once the specific requirements are announced by each respective government, a discussion of what functionality may need to be created to allow site administrators to meet their requirements well ahead of compliance deadlines will be had.

@idea15 is the lead for monitoring and evaluation of privacy legislation. @idea15 and @riankinney are working on an analysis of CCPA.

They are also monitoring other privacy legislation, including individual US state requirements as well as that of countries like Brazil, to anticipate possible future work.

Gutenberg review

@allendav is reviewing Gutenberg for any potential privacy issues stemming from CDNs, telemetry, or other issues, and will document his findings. Please make him aware of any concerns. He also welcomes privacy evaluations of Gutenberg from non-Automattic testers for transparency’s sake.

#45057 is currently the only Gutenberg blocker from a Privacy standpoint.

Cross-platform privacy working group

At Drupal Europe, @idea15 and Chris Teitzel from the Drupal core privacy team gained enthusiastic support from Dries Buytaert for a proposed cross-platform privacy working group. This group would create a forum for the core privacy teams from all major open source CMS projects (WordPress, Drupal, Joomla, Typo3, etc), to engage, share resources, compare experiences, and periodically meet in person to discuss privacy issues on the social, legal, and code levels. The group, which would be run through the Drupal community structure, may receive some funding. @idea15 will update the WordPress core privacy team in the next fortnight with news.

Group meta issues

  • Our current weekly office hours time of 1500 UTC on Wednesdays does not work for most participants. If you are interested in attending the weekly office hour meetings, please fill out this Doodle poll to identify a better time.
  • The component will be more diligent about posting agendas and meeting summaries on the Make core blog. New contributors are encouraged to volunteer, as this is a great way to get involved. @desrosj, @idea15, and @allendav will ensure these are posted when there are no volunteers for that week.
  • The team will discuss and choose team reps, in response to a discussion during the weekly Core dev chat of whether the core-privacy group is a team in addition to a component and focus.
  • @allendav will research more privacy-conscious document and collaboration tools outside Google docs.

Next Meeting

The next office hours will be held on October 17, 2018 at 15:00 UTC in the #core-privacy room on Slack.


What’s new in Gutenberg? (11th October)

4.0 is at the release candidate stage, which can be grabbed here.

Our 40th release is going to be a long one. Main changes are the introduction of a new data structure for RichText that will allow building sophisticated interfaces for inline content that we can make portable and relevant to mobile too.

It also has improvements for blocks, a way to set a different color as the overlay for Cover Image, a new font size picker that is clearer to use and scales much better, a cool Pullquote style variation, etc. This crosses a lot of the pending items.

There are also several interface improvements, including the ability to search categories, post locking when multiple people interact with the editor, better handling of floats, and many more.

Updated Font Size Picker component

4.0 🍯

Bug Fixes

Other Changes


Deprecations removed with this version.

Call for Testing: Lazily Evaluate Translation Strings

While attempting to localize REST API responses (#44758), Gutenberg contributors identified that there was an order-of-operations issue preventing locale information from being properly passed in via the REST API. @schlessera had previously worked on a performance optimization patch to lazily translate strings on demand, which was found to also permit locale information to be set before computing the strings, unblocking the Gutenberg issue.

To get this patch landed quickly, we request assistance from interested contributors to test and validate the patch on ticket #41305.

There has been some recent discussion about additional performance and memory usage optimizations, but I believe the solution proposed in the latest patches is close to being satisfactory. It just needs a little further testing and validation from committers and contributors familiar with translation handling and PHP performance before we can comfortably land the patch.

We request input by the end of this working week, if possible, to help remove the blocker to further Gutenberg localization work. Thank you!

WordPress 5.0 for Contributors and Committers

Gutenberg is a big project, and many WordPress contributors have limited hours in which they can contribute. This makes getting up to speed on the scope of Gutenberg a daunting (if not insurmountable, at least in the WordPress 5.0 timeline) task. With this phase of the Gutenberg project setting the stage for the future of WordPress development, I’m sure you’re wanting to get involved in whatever way you can, so my goal is to help you get up to speed as quickly as possible. Every one of you has different skills, availability, and experience with the Gutenberg project, so the Gutenberg and WordPress 5.0 teams need your help to prioritise what information you need.

If you’re an experienced contributor or committer who has time available during the WordPress 5.0 release cycle, and want to be able to make meaningful contributions towards making WordPress 5.0 awesome, you’re exactly who I need to hear from.

Please reply to this post with information about your availability, what components of WordPress you have experience in, and (if you haven’t got involved with Gutenberg yet) what you feel has been getting in the way.

In the mean time…

While we’re sorting out which tasks are available, please read Gutenberg’s Getting Started documentation, and get a Gutenberg environment up and running. The helper scripts in the Gutenberg repo use Docker, but if you already have an environment you prefer, there’s no need to switch: just make sure you have Node 8.x (or higher), and the latest NPM installed.

There are a few places where you can start straight away, depending on which components are of particular interest to you:

I’m also putting in a special request for folks to help with triaging Trac reports:

  • Open tickets in the 5.0 milestone need to be reviewed, most of them should be moved to the 5.0.1 or 5.1 milestones.
  • Closed tickets in the 5.0 milestone need to be reviewed, and reopened if the need to be ported to the 5.0 branch. If they don’t need to be in 5.0, there are two options:
    • If they should be in a 5.0.x release, move them to the 5.0.1 milestone, and reopen them for porting after 5.0 is released.
    • If they can wait until 5.1, move them to the 5.1 milestone. If they need changes due to the milestone move (eg, inline documentation needs to be updated to the new version), reopen them.
  • Open tickets in the 4.9.9 milestone will mostly be moved to the 5.0.1 milestone, though there may be some that are appropriate for 5.0.
  • Closed tickets in the 4.9.9 milestone will probably need to be reopened and moved to the 5.0 or 5.0.1 milestones.

These are just a few areas you can explore to get started. If there’s a different area you’d like to be contributing to, please say so, and we’ll see what we can find!


WordPress 5.0 Commit Management

Keeping our focus tight is key to ensuring WordPress 5.0 is released on time, so commit approval will be managed a little differently than usual. During this time, the 5.0 branch will be the working branch, rather than trunk, we can then port 5.0 commits to trunk after WordPress 5.0 is released.

And so, here is the current commit state of each branch:


trunk is closed for all commits.

4.9 Branch

The 4.9 branch is closed for all commits.

If the WordPress 5.0 schedule slips until January, PHP 7.3 fixes will be ported for a WordPress 4.9.9 release.

5.0 Branch

The 5.0 branch is current open for Gutenberg-related commits.

The 5.0 branch has been created from the 4.9.8 tag, not the 4.9 branch. Newer Gutenberg-related commits in the 4.9 branch will need to be ported to the 5.0 branch.

Prior to beta 1, any Gutenberg-related commits can be added by any committer. Commits not related to Gutenberg must be approved by me.

After Beta 1, commits must be approved by the relevant release lead, or me. After RC 1, commits must be approved by the relevant release lead, and me.

All other branches are in their usual closed state, except for security releases, of course.

Thank you, my dear committers, for your cooperation here. We’ll be back to your regularly scheduled committing in short order. 🙂


Gutenberg Phase 2 Leads

Phase 1 of Gutenberg has been about upgrading the writing and editing experience of WordPress, across posts, pages, and the delightful things people do with post types. The block framework will allow us to drastically simplify the various concepts and user interfaces across WordPress, including widgets, TinyMCE magic sections, and shortcodes.

Phase 2 is about thinking outside the box, namely the post and page box, to allow Gutenberg to handle entire-site layouts. We will replace widgets with blocks, so any block will be able to be used in any registered “sidebar” for legacy themes, and we will upgrade “menus” to a navigation block.

Phase 2 will be led by @alexislloyd on the design and product side, and @youknowriad on the technical side. Please join me in welcoming these two and sharing your thoughts on Phase 2.

I’ll propose and discuss Phases 3 and 4 of Gutenberg at WordCamp US in December.