Proposed roadmap: Tools for GDPR compliance

This is a proposed roadmap for adding privacy tools to core. The plan is to finalize it at the next #gdpr-compliance chat in Slack.

Main goal

Add tools to help site owners comply with the GDPR and other privacy laws and requirements.

Add notices for both registered users and commenters on what data is collected in core by default, and why.

  • Shorter texts in core with links to more information. Needs text.
  • Create these “more information” pages on Needs text.

Create some guidelines for plugins on how to get compliant.

A page (or several pages) on Needs text.

Add tools to core to facilitate compliance, and privacy in general.

There are few plugins that have started implementing these tools, so we have a nice head start.

The requests to see, download and delete/anonymize private data have to be with a confirmation (double opt-in) to avoid misuse. One possible solution would be to send a token by email when a user or a commenter has requested access to or deletion/anonymization of their private data. Then they will have to submit that token as a confirmation of their request.

TBD: shall we make this process automatic or should a site owner perform the action upon receiving the confirmed request?

  • For commenters. The stored private data is emails and IP addresses, the rest is public.
    1. Dialog for requesting to see and download their private data.
      TBD: should that data also contain the public portion?
    2. Dialog for requesting deletion/anonymization of the data.
      TBD: Deletion or anonymization? Or both and let the site owner decide?
    3. Ask for consensus for storing commenter cookies. This can be a (checked) checkbox under the comments form, something like “Save my name, email and site URL in my browser for next time I post a comment. More information”.
  • For registered users. All of the data stored by default is already visible in the user profile (except IP addresses if they have commented on the site), and most can be edited or deleted from there.
    1. Button for downloading their private data, including IP addresses if they have commented. Again, should that also contain the public data?
    2. Button for requesting deletion/anonymization of their account.

Add documentation/help for site owners on how to use these tools.

This should probably be another page under the Tools menu and contain short explanation of what privacy tools are available and how to use them. It could also contain the actual tools, for example an input field for anonymizing commenters by email address.

There are a few things that need clarification:

  • IP addresses may be considered personal data so they need to be deleted or anonymized. However do they need to be sent to the user when requesting to see or download their personal data? They are essentially third-party tokens used temporarily to access the Internet and the users have no control over them. Do other websites make them available?
  • Who are considered “controllers”? All admins on single install and all superadmins on multisite? Are admins on multisite controllers for their own site?

Please post your suggestions in comments so we can finalize the roadmap at the next #gdpr-compliance chat on Wednesday. Thanks @casiepa for helping with this!


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!

What’s new in Gutenberg? (16th February)

This belated release brings support for nested blocks into Gutenberg. The list of changes is rather big, so it's broken up into sections. It also has a new Columns block that leverages nested blocks to operate — it is labeled experimental, though, as it needs further work and has some browser hiccups.

Most notably to the user experience, we are introducing block shortcuts on empty paragraph blocks to streamline the process of inserting content that is not text, while also optimizing for the writing experience. The global inserter, featured at the top of the editor, is meant to become more of a primary way to add content when the user is not writing. Getting this balance right between block creation and the writing flow is crucial and we'll continue testing with users to refine it. 

We are also making changes to how text is synced to the application state, which improves the reliability of the "unsaved" state, the undo mechanism, the ability to dismiss the publish sidebar automatically as soon as you make another edit, and so on.

2.2 🌱


  • Block Nesting is live! 🎉  It comes with an experimental Columns block. (Note: converting a nested block into a reusable block is disabled on this first version.) Furthermore, this is not a specific implementation for columns alone — any block author can take advantage of defining nested areas.
  • Refined block insertion experience:
    • Introduce block shortcuts on every empty paragraph block. This also temporarily disables the sibling inserter as we work on refining this interaction.
    • Add trailing text area at the bottom of a post to continue writing.
  • Preview saved blocks while hovering on the inserter. Allows users to quickly see what they are inserting before inserting.
  • Enable triggering onChange events within RichText component on every keystroke. This was an enforced limitation that prevented saved post checks from being faithful.
  • Rework undo levels to use history "buffer" and leverage the mechanism to aid in continuous syncing of RichText history records.
Hovering a "saved block" shows a quick preview

User Experience

New features

Block API and Extensibility

Bug fixes

Other changes

GDPR Compliance Chat Recap – February 14th

(full text on slack)

This first GDPR Compliance Chat started by people introducing themselves. There was a nice mix of core comitters, developers, lawyers (or law-lovers), contributors, trainers, project managers, testers, people enrolled in privacy roles in companies, etc.

The main question was what is personal data and where it is stored. Most of it might be in user_meta, but there is personal data everywhere!

For the exporting part, all data needs to be considered, so probably also from all privacy impacting plugins.

About the roadmap, the first steps are:

  • Identify what is considered personal data (emails, IP, etc)
  • Who are the identifiable persons?
    • Controller: Site owners, admins? In multisites?
    • What about anonymous people that create posts?

Shared documents:

Some items raised worth keeping in mind and explore further:

  • What does the web owner need to do? And what part can WordPress Core take care of?
  • Proposal for a new column (is_personal_data) in all tables to indicate clearly the personal data, but of course data could be serialized and contain both. So interfaces and hooks might be a better way to go.
  • Could some developers share what privacy impacting data some of their own plugins collect and see if a pattern emerges?
  • Data stored on backups have to be deleted too.
  • Is a public post "personal data" if the user posted something that is considered personal? So how far is deletion inside posts needed? And what about quotes?
  • For plugins: a Privacy Impact Assessment is required by the GDPR for data intensive projects. It would be nice to get a tab in the plugin repo noting every plugin's data flows, including collection, retention, cookies, telemetry.

Next GDPR Compliance Chat:

  • Structure the approach
  • Define goals and the roadmap
  • What is in scope and out of scope

Dev Chat Summary: February 14th (4.9.5 week 2)

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

4.9.5 planning

  • We’re looking for nominations for people to lead this minor release, self-nominations are very much welcome. Please reach out to @jbpaul17 (@jeffpaulon Slack) or comment on this post with nominations.
  • No timeline set for 4.9.5, but minor releases tend to run 6-8 weeks so we’ll go with what fits with the release leads’ schedule
  • Potential focus for 4.9.5 could be support of foundational work needed to support Gutenberg

Updates from focus leads and component maintainers

  • The PHP team shared a recap from their recent meeting, thanks again to them for documenting that discussion
  • The GDPR compliance team met earlier today, so if you missed the meeting but have interest in the topic you can follow along in the #gdpr-compliance channel.
  • The New Contributor meeting has resumed, thanks to @desrosj for getting that going again

“good-first-bug” claiming process

  • Topic primer from @drewapicture: Gardeners have (mostly) been updating patch-related keywords on `good-first-bug` tickets, but not assigning the tickets which is what actually moves a `good-first-bug` ticket from the unclaimed to the claimed list. I just went through and assigned maybe 40 tickets, which puts the unclaimed list at a much more realistic 4 tickets. It might be worth a discussion about whether we should change the “claiming” behavior to trigger off of adding the `has-patch` keyword vs being assigned. It’s one thing to ask people to just do what needs to be done in the current workflow, but that doesn’t seem to be working, so maybe the better option is to just change how it works so it can be more automagical.
  • Agreement that adding a patch equates to claiming a ticket, conceptually auto-claiming could work
  • Meta#3459 created to track this work

General announcements

Next meeting

The next meeting will take place on February 21, 2018 at 21:00 UTC / February 21, 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, #core-php, #dev-chat, #gdpr-compliance, #summary

Dev Chat Agenda: February 14th (4.9.5 week 2)

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

  • 4.9.5 planning
  • Updates from focus leads and component maintainers
  • `good-first-bug` claiming process
  • 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 Contributor Meetings Return

The New Contributor meeting is held in the Slack aimed at anyone looking for help contributing to WordPress. No questions are too big or too small, and all are welcome!

This meeting started last July, and will be returning on February 14, 2018 at 20:00UTC after a brief hiatus. It will be held twice monthly on the 2nd and 4th Wednesday of the month at 20:00 UTC.

The meeting is moderated by the following volunteers on a rotating basis: @desrosj@flixos90, @sergey, @stevenkword, and @welcher.

Questions or comments about the meeting? Topics you would like to request be covered? Want to help out with this meeting? Any other feedback? Feel free to post in the comments below or reach out to one of the moderators on Slack. We hope to see you there!

GDPR Compliance Agenda: February 14

This is the agenda for the first weekly meeting about WordPress core GDPR compliance on February 14, 2018 at 17:00 UTC / February 14, 2018 at 17:00 UTC in the gdpr-compliance channel on Slack.

  1. Introductions. Please introduce yourself with few words and include your field of expertise (developer, documentation specialist, project manager, lawyer, etc.).
  2. Start on a roadmap for GDPR compliance for core. There were few prerequisites identified in the gdpr-compliance channel. We'll need to have clear understanding about:
    • What is considered personal information in WordPress?
      • Emails, IP addresses.
      • Are posts and comments personal information? What about private posts?
      • Are login names personal information?
      • Anything else?
    • Who are the identifiable persons?
      • Are site owners "controllers"?
      • Are all admins site owners?
      • On multisite installs, who are controllers: site admins or only the network admins?
      • Are people that post comments and don't have accounts "identifiable persons"?

As always, please suggest other agenda items in the comments.

#agenda, #gdpr-compliance

PHP Meeting Recap – February 12th

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

The agenda was to discuss which version to include the notice in and how to deal with the dismissal functionality of the notice.

Release Plan

  • After requesting feedback in the #core channel, there were some concerns expressed about publishing the notice in a minor release (like 4.9.5), particularly because a notice like that suddenly being thrown from a minor release may seem weird.
  • However the amount of users affected by this would be very low, since only users on PHP 5.2 are initially targeted.
  • Releasing sooner than later would allow for quicker feedback and stats, to iterate based on those.
  • The decision was to go with the 5.0 release for now. When the notice has been merged into trunk, it can be reevaluated whether it should be merged in the minor release branch.

Notice Dismissal

  • Four initial possibilities were suggested to be considered:
    • The notice shouldn’t be dismissible at all.
    • The notice should be permanently dismissible.
    • The notice should be dismissible, but come back every month.
    • The notice should be dismissible, but come back every core update.
  • @clorith expressed concerns about heavier support load when bringing the notice back “unexpectedly”, like after a month. On the contrary, the notice being persistent is part to the solution, so people trying to get rid of it otherwise are doing it wrong.
  • If it needs to be brought back, that should preferably happen per (major) update.
  • Option 4 ended up to be the most viable one out of the suggestions.
  • @SergeyBiryukov then suggested to check how the existing Browsehappy notice does that. It was quickly discovered/remembered that the Browsehappy notice is not actually implemented as an admin notice, but as a dashboard widget.
  • That approach sounds promising too, so @flixos90 added he’ll work on an alternative patch for an implementation as dashboard widget.

Next week’s meeting: Admin Notice vs. Dashboard Widget

The agenda for next week is to decide on one of the following approaches to pursue:


Servehappy Admin NoticeServehappy Dashboard Widget

Benefits of admin notice

  • Very visually prominent.
  • Quick overview of details, layout similar like known welcome notice.

Benefits of dashboard widget

  • Not as easy to accidentally click away without looking, as fully dismissing requires to open screen options first.
  • Only shown in dashboard which appears to be more appropriate than everywhere.
  • Follows Browsehappy implementation, so less new code and tweaks required.

If you have any suggestions or feedback before the meeting, please comment on the Trac ticket or the individiual pull requests if applicable.

#core-php, #servehappy

Dev Chat Summary: February 7th (4.9.5 week 1)

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

4.9.3 + 4.9.4 update

  • 4.9.3 went out on Monday, 4.9.4 went out on Tuesday; note technical details behind 4.9.4
  • Note final paragraph from the 4.9.4 technical details post:
    • What we’re doing to prevent this happening again We’ll be making a follow up post after we’ve been able to determine how to ensure that this never happens again. We don’t like bugs in WordPress any more than you do, and we’ll be taking steps to both increase automated coverage of our updates and improve tools to aid in the detection of similar bugs before they become an issue in the future.
  • If you have ideas, solutions, or are able to support increasing “automated coverage of our updates” and improving “tools to aid in the detection of similar bugs” then please gather those and add them to the pending post on this topic.
  • @jbpaul17 to see if any process-related changes might help
  • @sergey also asked for ideas on how we can improve the quality and consistency of our code reviews
  • @helen spoke with @dd32 and will look into a way to test auto-updates
  • @desrosj noted that automating some parts of the release process might help

Updates from focus leads and component maintainers

General announcements

  • Comment thread from today’s agenda post on topic of security not able to be addressed as no one from the Security team was present, but @aaroncampbell provided a response ahead of time:
    • Okay, so this is the DoS issue with load-scripts.php and load-styles.php: Basically, the best mitigation for this is at the network level. Hosts and WAFs can rate limit this in a way that makes a lot more sense than anything WordPress can do. Caching would also be extremely useful in this case. Something that we _could_ do is limit the number of scripts that could be loaded at once with those, but the problem with that is all it does is reduce the load by some relatively marginal amount.
  • @leemon asks for review on #43226; @drewapicture to take a look
  • @binarymoon asks for review on #38545; looking for someone to give feedback and get to an agreement so this ticket can move forward
  • @joyously asked whether New Contributor meeting was still occurring; @desrosj to speak with other facilitators and get the meetings re-started
  • @williampatton shared insights into his experience being a deputy release lead on 4.9.3; encourages others to contribute as leads, noting core commit access is not required, recommends pairing with experienced lead; highlighted permissions issues that should be resolved; thankful for support from others during the release process; will help elaborate on minor release handbook page
  • @chanthaboune highlighted the need to “lessen that cognitive load for new/learning release leads”, need to call out contingencies and what’s time-specific; in general how can we make the contribution process easier

Next meeting

The next meeting will take place on February 14, 2018 at 21:00 UTC / February 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-3, #4-9-4, #4-9-5, #core, #core-editor, #core-media, #dev-chat, #security, #summary