Media Meeting Recap – March 8


This post is a summary of the latest weekly Media component meeting, which took place in the #core-media Slack channel, on Thursday,  March 8, 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 @desrosj @karmatosed @postphotos @joemcgill @sergey @chetan200891 @adamsilverstein 

Transcript: Read on Slack


  • The best way to follow along with media related Gutenberg items is the media label in GitHub.
  • Repository milestones
  • Add mediaelement component@antpb discussed that this is currently a blocker to building the Playlist Block. The component renders on the editor view and is enqueuing via client-assets.php but the script is not enqueuing on the front end. @antpb needs help figuring out the front end issue. Steps to creating a clone of the repo can be found at this comment.
  • Add block playlist: Currently blocked by the inclusion of the mediaelement component.

4.9.5 Tickets

The next part of the meeting was spent on tickets in the 4.9.5 milestone

Tickets needing testing:

  • #42724 – Options media page hides breaks on desktop
    Patch still needs testing.
  • #42968 – Media: Grid View: new upload, file is in the wrong position in the grid until after upload is complete
    Agreement all around that it is ready to commit.
  • #43226 – Crop setting in thumbnails never set when uploading PDF files
    Committed to trunk. It was agreed that this will be fixed in 4.9.5. @mikeschroder is working on backports.
  • #43255 – WP _Image_Editor::make_image leaves an output buffer open on failure
    This one has been open for a while but is in need of clean up. Mentioned by @mikeschroder we "want to be sure what we do doesn't break workarounds."

Tickets up for discussion:

#43123 Default captions should NOT use max-width
@joemcgill mentioned that he thinks it is worth reverting due to unintended consequences. @mikeschroder noted that "we’ll want to be sure to message folks and give a warning if we do revert."

Next Meeting

The next #core-media meeting is set for Thursday, March 15, 2018 at 1900 UTC Note: The time is maintained in UTC, so if you are in the US, this time may be different due to DST. We'll move the meeting time once EU has switched to DST in two weeks. Hope to see you there!

#core-media, #summary

Updated REST API Team Meeting Time

After last week's REST API meeting we are updating our standard meeting time to occur at 17:00 UTC on Thursdays (17:00 UTC on March 8 this week), to better accommodate the schedules of the regular participants.

This week we will likely continue or revisit the ongoing conversation around handling autosaves, then review open Gutenberg-related API tickets. If you have a ticket you want prioritized or want to know where help is needed, we hope to see you in #core-restapi tomorrow!

GDPR Compliance Chat Agenda – March 07

Agenda proposal:

  • Roadmap: Please help us, give your ideas
  • Trac tickets: Take ownership, contribution appreciated
  • Open discussion

Join us on slack at 16:00 UTC.
#gdpr-compliance, #agenda

Introducing the Gutenberg Plugin Compatibility Database

Ideally, the majority of WordPress users should be able to use Gutenberg on the day WordPress 5.0 is released. They'll hit "Update WordPress", navigate back to the editor, and continue publishing in Gutenberg with all of the functionality they expect in the Classic Editor.

But plugins! If any one of their active plugins are incompatible with Gutenberg, the WordPress user is likely to experience pain, misery, and bad fortune. Many WordPress installations have a dozen or more active plugins, so WordPress plugins are a significant risk vector for Gutenberg incompatibility.

Enter the Gutenberg Plugin Compatibility Database. The goal for this crowdsourcing tool is to identify whether or not plugins are compatible with Gutenberg. With this data set, we'll be able to:

  • Know the most likely causes of incompatibility.
  • Focus developer outreach on the highest impact problems.
  • Proactively educate WordPress users on whether or not their WordPress installation is ready for Gutenberg.

The only gotcha: we need lots and lots of person-hours for testing. If each plugin takes roughly 1 minute to test, we'll need ~75 person-hours to get through the remaining ~4500 plugins in the database.

Check out the project for a more complete introduction to what's involved. This includes a definition for "Gutenberg-compatible", explanation for why only 5000 plugins are in the database, and other design decisions.

Do you or someone you know have access to lots of person-hours (e.g. WordCamp contributor day, hosting support team, etc.)? I'd love to chat! Feel free to leave a comment, ping me on Slack (I'm 'danielbachhuber'), or get in touch however most convenient.

GDPR Compliance Chat Agenda – February 28

Agenda proposal:

  • Information/documentation: Quick update
    • Useful links
    • Trac tickets
  • Roadmap: Finalized version, trac tickets
  • Allen's view and his development around privacy policy
  • Open discussion

Join us on slack at 16:00 UTC.
#gdpr-compliance, #agenda

GDPR Compliance Chat Recap – February 21st

(full text on slack)

A centralised GitHub folder was created to gather all info (Roadmap, knowledge base, trac tickets list, etc) while waiting for a final location:

@idea15 (webdevlaw on slack) indicated that a privacy centre to hold GDPR information for site users, for site administrators/owners, and developers is being build. To be checked how this will be split between and

How 'other systems' deal with the request to see personal data can be found on

A discussion was started if the interface is way to go and/or if Core should provide actions & filters to provide means to plugins to report their personal data.

@allendav was pointing to for possible shortcodes to expose privacy policy statements in a consistent way.

@schlessera pointed out that localization might be difficult to handle, how to avoid a mix of languages?

Current global idea is that plugins submit the info using hooks/filters, the admin/controller needs to 'accept' them so that enduser can see the full list, all based on versioning per plugin.

Additional capabilities (like e.g. manage_compliance) could be needed.

#gdpr-compliance #summary

PHP Meeting Recap – February 19th

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

  • Main topic for this meeting was to discuss the two different implementations of the servehappy notice we have so far:
    • an admin notice that appears at the top of all pages;
    • a dashboard widget that only appears on the dashboard.
  • @flixos90 quickly described the main benefits of the alternative dashboard widget approach:
    • it requires less logic;
    • it is harder to unintentionally hide;
    • it matches what the browsehappy project did.
  • We discussed how best to set the priority of the widget, so it won’t be displayed below the fold. @clorith noted that adding it to dashboard.php would ensure it is always shown first, just like the browsehappy one.
  • Those present during the meeting unanimously voted for the dashboard widget, instead of the admin notice. We thus decided to go with the alternative approach of the dashboard widget moving forward.
  • We decided to work on getting this into trunk for now, with the option of backporting it to the next minor release if there’s consensus later on.
  • The reshowing of the widget should not be included in the code for now, but could be part of the “database migration” code that gets run on updates. This lets us defer the decision of when to reshow.
  • The discussion then moved on to a ServeHappy API endpoint on that could be used to dynamically control the behavior of the dashboard widget.
  • @flixos90 has implemented a first version of the API endpoint following the details we’ve discussed, and it is already available right now:
  • The information that is sent to the ServeHappy API endpoint (PHP version + indirectly IP address through server access logs) might have implications on GDPR compliance. We should raise this concern in the #gdpr-compliance channel.
  • We discussed how to let hosts provide upgrade information. A mechanism using constants or filters would be preferable to providing this through the API endpoint, as we’d want to decentralize this information and not maintain it ourselves.

Next week’s meeting

  • Next meeting will take place on Monday, February 26, 2018 at 16:00 UTC in #core-php.
  • Agenda: Discuss the new API endpoint.
  • 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-php, #php, #servehappy, #summary

GDPR Compliance Chat Agenda – February 21st

Warning: meeting starts at 16:00, not 17:00 UTC!

Agenda proposal:

  • Information/documentation: what do we have and where is it stored
  • Roadmap: review the proposal and create working groups
  • Open discussion

Join us on slack.
#gdpr-compliance, #agenda

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!


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

#gdpr-compliance #summary