Feature Plugin Proposal: WP Consent API

As part of the core-privacy team’s roadmap the team has started development on a Consent API as a feature plugin.

We welcome all thoughts on this proposal, which you are welcome to leave as comments on this post, or share with us directly in the #core-privacy channel on Making WordPress Slack. We host weekly office hours on Wednesdays at 19:00 UTC, see the meetings page for times in your timezone.


A standard way for WordPress core, plugins, and themes to obtain consent from users should be established to provide a consistent and stable experience for administrators, developers, and users of all kinds.

Currently it is possible for a consent management plugin to block third party services like Facebook, Google Maps, Twitter, if a user does not give consent. But if a WordPress plugin places a PHP cookie, a consent management plugin cannot prevent this.                                         

There are also WordPress plugins that integrate tracking code on the client side in javascript files that, when blocked by a consent management plugin, break the site. Or, if such a plugin’s javascript is minified, causing the URL to be unrecognizable, it won’t get detected by an automatic blocking script.

Lastly, the blocking approach requires a list of all types of URL’s that place cookies or use other means of tracking. A generic API which plugins adhere to can greatly help a webmaster in getting a site compliant.

Does usage of this API prevent third party services from tracking user data?

Primarily this API is aimed at helping to achieve a compliant use of cookies or other means of tracking by WordPress websites. If a plugin or custom code triggers for example Facebook, usage of this API will be of help to ensure consent. If a user manually embeds a facebook iframe, a cookie blocker is needed that initially disables the iframe and or scripts.

Third-party scripts have to be blocked by a blocking functionality in a consent management plugin. To do this in core would be too intrusive, and is also not applicable to all users: only users with visitors from opt in regions such as the European Union require such a feature. Such a feature also has a risk of breaking things. Additionally, blocking these and showing a nice placeholder, requires even more sophisticated code, all of which should not be part of WordPress core, for the same reasons.

That said, the consent API can be used to decide if an iframe or script should be blocked.

How does it work?

There are two indicators that together tell if consent is given for a certain consent category, e.g. “marketing”:

  1. The region based consent_type, which can be optin, opt out, or other possible consent_types;
  2. The visitor’s choice: not set, allow or deny.

The consent_type is a function that wraps a filter, wp_get_consent_type. If there’s no consent management plugin to set it, it will return false. This will cause all consent categories to return true, allowing cookies and other types of tracking for all categories.

If optin is set using this filter, a category will only return true if the value of the visitor’s choice is allow.

If the region based consent_type is opt out, it will return true if the visitor’s choice is not set or is allow.

Clientside, a consent management plugin can dynamically manipulate the consent type, and set the applicable categories.

A plugin can use a hook to listen for changes, or check the value of a given category.

Categories, and most other stuff can be extended with a filter.

Existing integrations

  • Cookiebot
  • Complianz
  • Example plugin. This plugin basically consists of a shortcode, with a div that shows a tracking or not tracking message. No actual data tracking 🙂

Demo site

Plugins used to set this up:

Technical Scope

The feature plugin should at least handle the following functionality:

  • PHP functions to set the consent level and consent type.
  • PHP functions to retrieve the consent level and consent type.
  • Javascript functions to set the consent level.
  • Javascript hook that fires when a consent level is set.
  • Javascript functions to retrieve the consent level.

Introducing the Feature Plugin

What’s next?

Once the plugin is confirmed as a feature plugin, the next steps would be:

  • To increase the number of users of the feature plugin.
  • To add other interested privacy team members and core developers as contributors of the plugin.
  • To have additional Third-Party consent management plugins to adopt the API.
  • To iterate on the feature plugin development.
  • To audit some specific aspects of the feature plugin:
    • security
    • coding-standards and documentation
  • To create a Trac ticket to handle a potential future merge proposal – if the feature plugin deserves it.

Post written by @rogierlankhorst / @paapst and reviewed by @garrett-eclipse / @carike

#consent-api, #core-privacy, #feature-plugins, #privacy, #privacy-roadmap

Dev chat summary, March 18, 2020

@marybaum facilitated the chat on this agenda.

Full meeting transcript on Slack

This devchat marked week 10 of the 5.4 release cycle.


WordPress 5.4 Release Candidate 3 was released on Tuesday March 17th! 🎉Thank you to everyone that has contributed! @johannlinnarsson asked when we might expect the final 5.4 release and @marybaum confirmed that March 31 is the target release date. 

Upcoming releases WordPress 5.4

WordPress 5.4 About Page: @karmatosed shared that many many folks contributed to the design and creation of the About page. Thank you to everyone that contributed. Testing is very much appreciated at this point as we prepare for release candidate 4 on March 24.

@jorgefilipecosta mentioned that there are two pull requests that are in need of review for 5.4 and those can be found at this link.

 @clorith asked if there was any additional information regarding the recent changes to editor default views and there is currently no new information outside of the discussions in the blog post. 

Components Check-In

@azaozz had some exciting Media updates showing off the now merged 1.1 changes for the Lazy Loading Feature Plugin and said that he will be working on a patch to introduce in trunk (5.5.) More to come soon on this much anticipated feature! If you’d like to contribute here is a link to the GitHub repo.

@audrasjb introduced some new changes to WP Auto Updates saying, “WP Auto-updates Feature Plugin version 0.3.0 was released with email notifications for plugins automatic updates. Next version will be focused on porting all the current features to themes screen.” A summary of this chat can be found at this link. If you would like to get involved in contributing to this feature, please feel free to jump into the Feature Plugin GitHub repo.

@pbiron mentioned another plugin that could benefit from some testing; Core Sitemaps plugin is aiming for an early inclusion into 5.5. Please feel encouraged to test it ahead of time! If you’d like to contribute to this feature, explore the GitHub repo!

@aduth provided a #core-js update around their processes. He said, “In the #core-js chat this week, it was suggested to share that our weekly meeting summaries are now including a “News Roundup” of JavaScript and Gutenberg-related items, for those who might be interested or think it helpful to keep in the loop. “ A link to that can be found at the end of this summary post.

Props to @garrett-eclipse for the peer review of this summary. 🙏🏼

#5-4, #core, #feature-plugins

Dev Chat summary – February 12, 2020 (5.4 week 9)

@davidbaumwald facilitated the chat on this agenda.

Full meeting transcript on Slack

This devchat marked week 9 of the 5.4 release cycle.


WordPress 5.4 Release Candidate 2 was released on Tuesday March 11th as expected 🎉

Feedback from hosts is needed on Make/Hosting regarding SimpleXML PHP extension usage.

@joemcgill shared that XML Sitemaps Feature Plugin version 0.2.0 was released this week and could continue to use feedback from folks testing.

@audrasjb shared that Plugins & Themes Auto-updates Feature Plugin version 0.2.1 was released this week. This feature now have a dedicated Slack channel, created right after the last devchat: #core-auto-updates. There will be weekly meetings on Tuesdays at 18:00 UTC. The kick-off meeting recap is available on Make/Core.

@chanthaboune shared the roadmap to get an All-women Release Squad by the end of 2020.

Upcoming releases

WordPress 5.4 Release Candidate 3 is scheduled for Tuesday March 18th, 2020.

trunk is open for 5.5, but the priority is on 5.4 Release Candidate cycle. Polyglots Team already started to work on translation packages.

Components Check-In

@imath worked on Ticket #49236 and needs some feedback. @jeffpaul advised him to slate it to 5.5 with early keyword so it could be handled at the early stage of the development cycle.

@garrett-eclipse found a list of the components and sub-components without maintainers:

There’s the potential to merge some of the less active sub-components like Charset and Emoji into it’s parent Formatting component. But that would needs further discussion.

Open floor

The main discussion of the open-floor was the Block Editor’s Full Screen Mode enabled by default since WP 5.4 Release Candidate 1.

Here is a quick transcript of the discussion. Please note that no decision has been taken during this chat.

@peterwilsoncc wanted to know when was this committed to the WordPress repository. @jorgefilipecosta answered it was introduced during Beta 3, before WP 5.4 RC 1 was released.

@peterwilsoncc: “same for the release in which it was moved from experimental to stable (for want of a better word) Gutenberg?”. @jorgefilipecosta answered that Full screen mode was not experimental, it was stabilized and working for a long time, it was just not enabled by default (although some hosts were doing it), and the Gutenberg team just had a small PR that enabled the mode by default.

@peterwilsoncc noted that in the discussion on the Make/Core blog, @matt mentions some user testing. @peterwilsoncc asked how much was done.

@joostdevalk proposed to revert and take another look for 5.5, given the negative feedback about this change.

@clorith pointed out that it is still being worked on, and even had a design change between RC1 and RC2. It feels like it’s not ready, and needs more UX work before it goes in.

@chanthaboune asked how the feedback has been in support forums. @ipstenu answered that it’s hard to get feedback in support forums at this stage, since only people beta testing would see it and they tend to be a little more technical savvy than mainstream users.

@youknowriad wanted to clarify some of these questions:
– “I believe we should just the merits of the full screen on its own not whether it can be disabled or not. For instance the customizer is in full screen and it can’t be disabled.
– The UX work after RC1 was a bug fix for RTL languages.
– The feedback is balanced. There were good comments about it. Most negative feedback is about the fact that it becomes default.
– This feature has been on the Gutenberg plugin for more than a year now, It’s in before 5.0.”

@pbiron asked if it was enabled by default in the plugin before being merged into core.

@youknowriad answered that was a request from @matt as release lead prior to the RC.

@joostdevalk added that it’s sounds good to say that @matt has every right to make that call. But he disagrees that this is a good idea in its current form, and he think it will be necessary to guide changes like this more. The Block Editor is changing its default behavior without explaining that in the interface.

For @peterwilsoncc, at this point the question is whether it should be enabled by default rather than whether the feature should exist.

@joemcgill’s main concern is that the reaction to this change will be for people to install code that permanently overrides the feature preference, which makes it harder to move to a fullscreen mode default in the future.

@nilovelez noted that it may seem daunting for existing users, as some part of the UI will apparently be gone, but existing users are the ones that won’t even notice the change. Some attendees disagreed on that as the current behavior for existing users is saved with LocalStorage so it won’t stay for users that use different devices to connect to WordPress Admin.

@clorith also mentioned that Apple clears LocalStorage at set intervals, so users would lose their “don’t use fullscreen” option.

@johnbillion feels concerned that how to switch back to non full screen mode is not obvious.

@youknowriad answered the argument can be turned to the opposite direction for people preferring the full screen mode if it’s disabled. That’s why he think the core team should discuss whether it’s good not whether it can be disabled. For @clorith, given that it’s been off by default, then this is an unexpected change, and thus should not be used as the basis.

@joostdevalk proposed to show how to get out of full screen mode and how to set personal preference in the interface, and save preferences as a user meta and not on the user’s browser.

@jorgefilipecosta pointed out that a new welcome modal is shown to new users. He asked if it would make sense to introduce full screen mode there. @joyously stated that most of the users wouldn’t see it. @jorgefilipecosta, answered that users that won’t see the new modal won’t switch to default FullScreen mode, their preferences will be kept unchanged.

@audrasjb added that users don’t necessarily come to the editor from the posts list. With fullscreen mode and the WP logo button, they can only go back to the Posts list instead of having the full Admin menu. This is the only Admin action/link directly available after editing/publishing a post.

@jorgefilipecosta raised that the development of database persisting mechanism is in progress and that should happen soon. @ipstenu added it really should be a requirement for this feature to land in WordPress Core. @jorgefilipecosta mentioned database persisting for user’s preferences is expected to land in WP 5.5.

In terms of actions, @peterwilsoncc suggested:

  • Setting full screen to off by default
  • Adding some onboarding for when the switch is made
  • Enable once the user’s preference is saved in the database
  • Clarifying exiting full-screen mode (currently active, stated for completeness)

@johnbillion pointed out Matt mentioned that some hosts enabled full screen mode. He asked what is the feedback been regarding not getting lost, switching modes, etc.

@chanthaboune tried to summarize the concerns raised by the attendees:

  • Consistency/persistency of the visual experience
  • More thoughtful user flows
  • Clearer introduction to the full screen functionality

#5-4, #block-editor, #feature-plugins

Dev Chat summary – January 29, 2020 (5.4 week 3)

The chat was facilitated by @davidbaumwald on this agenda.

Full meeting transcript on Slack

This devchat marked week 3 of the 5.4 release cycle.

Highlighted posts

Upcoming Releases

We are currently in week 3 since WordPress 5.4 kick-off.

Further informations:

@mapk mentioned that there is a new project board in GitHub going for the 5.4 must-haves from Gutenberg.

@garrett-eclipse raised that the Privacy team has been working through their 5.4 list and have several patches ready for committers review.

@karmatosed mentioned that the Design team is moving along for 5.4. There have been 2 triages a week running and feedback is flowing across tickets. If there’s anything a team would like feedback on, please link in design Slack channel or surface in a triage session. The about page squad is also starting to form.

@audrasjb pointed out that since there is no plan for a new minor release for the moment, all unfixed tickets were moved from 5.3.3 to milestone 5.4. Those which were already committed to trunk and ready to be shipped were merged into 5.3.x branch by @sergey, so they could land in an eventual 5.3.3 security release (reminder: security releases can happen at any moment).

Components Check-in

Comments component: @imath raised tickets #39732 and #48772 which are ready to be committed. Also, he noted the Comment Post Type ticket was splitted into two different tickets. The bigger one will wait for WP 5.5.

Media component: @azaozz pointed out that the feature plugin to test lazy loading for images was just released. Please test: feedback, including just “It works!” is very welcome. Feedback can be added on the plugin’s support forum or if there are problems, on the plugin’s GitHub repository.

Concerning Lazyload feature plugin, @xkon added that testers will need posts with a lot of images and a big viewport height to see lazy loading effects. @azaozz added that the browser will still load the first 2KB of images that are going to be lazy-loaded, so looking in the console may not be an indication of exactly how it works.

@audrasjb reminded that Plugins and Themes Automatic Updates tickets (#48850 and #49199) need code review and testing:

  • Testing on multisites installations on the plugins ticket (themes autoupdate on multisites is still a work in progress – help welcome!)
  • Review from the security team (@whyisjake is going to take a look)
  • Review from very experimented core devs to check for eventual consistency issues between Core and new functions/filters/constants
  • Potential Unit Tests patches
  • Wider testing from every contributors

Open floor

@kjellr asked for attention to the new bi-weekly Block-based Themes Meeting. This meeting is dedicated to exploring and defining block-based themes. It’s an opportunity for folks across teams to discuss and define the future of themes as they relate to Gutenberg’s full-site editing work.

@isabel_brison left a comment in the agenda post to encourage core contributors to start a discussion about “CSS-in-JS”, which is going to be investigated by the Gutenberg team. Links to the related Pull requests are listed in the comment and it’s worth a read for those interested to weight in it during further discussions.

@audrasjb talked about a new contributor (@valentinbora) who took notes of all the answers he got from the last New Contributors meeting’s facilitator and few core devs who regularly attend this meeting. He kindly provided his notes and they were put together into a FAQ for new contributors handbook page proposal. The idea would be to add new questions after each new contributor’s meetings, and refer to this handbook page when people ask for things that are already well explained in the FAQ. @marybaum proposed to do a copy review before publishing.

#5-4, #devchat

Dev Chat summary: December 18, 2019

Please note Dev Chat is suspended on December 24th and January 1st 2020. It will be back on January 8th 2020, same time, same place!

The chat was facilitated by @francina on this agenda.

All the discussions can be found in Core channel on Slack here.

Announcements and highlighted posts

@audrasjb gave an update about 5.3.1 version that was released on December 13. Right after, a couple of high severity issues were raised on Core Trac. The release team then planned and held two bug scrubs and released a provisional schedule for 5.3.2.

The first Release Candidate for 5.3.2 was released on December 17, with the 5 main issues fixed.

Update: WordPress 5.3.2 went live later yesterday after the devchat.

@francina gave a quick update of WordPress 5.4, which is ETA is still March 31 as initially planned. She is currently collecting feedback from component maintainers and the release could eventually be shortened if there are no big features planned to ship into the version.

Components Check-in

@johnbillion precised that component maintainership doesn’t mean having to fix all the bugs, and that it’s more a shepherding role. So, anyone interested in maintaining a component or just wanting to know more is welcome to ping a committer or release lead.

@imath called for attention on #33717 from the Comments component to which he proposed a patch.

@francina then manifested her desire to see the Comments components as one of the focus for 5.4, since it has been abandoned for a while.

An interesting discussion about components and components maintainers then took place. @francina asked about how the Core team can help with the recruitment of maintainers.

@karmatosed suggested a few steps that would basically consist in

  • Clarifying what component maintainers do.
  • Being ok with people going in and out of that role, almost encouraging it to spread good people around.
  • Looking at what is a focus for this coming year.

@garrett-eclipse suggested we do on Make/Core on seeking maintainers. He also proposed we can see who the regular contributors are in the component and reach out to them specifically.

@mikerbg said that a good step would be to identify individuals that are willing and able to provide some assistance to the marketing team to publicize recruitment opportunities and needs.

@jeremyfelt reminded this discussion from a chat in May, that it might worth looking at.

The full transcript of the discussions about components and components maintainers can be found here.

#devchat, #summary

Alternate color schemes changes in WordPress 5.3.1

WordPress 5.3 added some noteworthy CSS changes to WordPress Admin. These changes also impacted alternate color schemes, especially concerning secondary buttons.

Indeed, secondary button borders unexpectedly inherited their scheme’s primary color, which resulted in arguable visual aspect and poor readability for most color schemes.

“Blue” alternate color scheme in WordPress 5.3
“Coffee” alternate color scheme in WordPress 5.3
“Midnight” alternate color scheme in WordPress 5.3

A bug also occurred on :active state, where the background color of the button was quite the same than the text color.

On the right: secondary button with :active state on “Blue” color scheme in WordPress 5.3
On the right: secondary button with :active state on “Midnight” color scheme in WordPress 5.3

WordPress 5.3.1 will fix these issues by unifying WP-Admin secondary buttons for all alternate color schemes.

Secondary button styles will be the same for all bundled alternate color schemes. This change also fixes the :active state CSS issue.

Please note this change also introduces some hardcoded colors for both gray borders and texts. Plugin authors who provide specific support for alternate color schemes can use these new hardcoded colors.

New secondary button CSS/Sass styles in WP 5.3.1:

.button {
	border-color: #7e8993;
	color: #32373c;

.button:hover {
	border-color: darken( #7e8993, 5% );
	color: darken( #32373c, 5% );

.button:focus {
	border-color: #7e8993;
	color: darken( #32373c, 5% );
	box-shadow: 0 0 0 1px #32373c;

See /wp-admin/css/colors/_admin.scss.

New CSS styles for secondary buttons in alternate color schemes:

Secondary buttons in WordPress 5.3.1
“Midnight” alternate color scheme in WP 5.3.1
“Coffee” alternate color scheme in WP 5.3.1

For reference, see the related Trac tickets: #48585 and #48598.

#5-3-1, #accessibility, #core-css, #dev-notes

Dev Chat summary: October 2

The 5.3 Release Coordinator, @francina, led the chat (full transcript). For the record, here was the agenda for the meeting.

Announcements and highlighted posts

@francina made some announcements and pointed out highlighted posts from Make/Core blog:

Feel free to browse through these posts and add comments or thoughts.

@youknowriad mentioned Gutenberg 6.6 recap post. This version focused on stability for the editor and performance for WordPress.

Upcoming Releases

Gutenberg team lead @youknowriad said they welcome any testing to detect bugs and regressions before 5.3 release. You can see what’s happening with the editor on this GitHub board.

Site Health component maintainer @clorith reported that desired changes are on track and should be ready for the Release Candidate, currently scheduled for October 15.

Docs coordinator @justinahinon said 5.3 dev notes include some for major changes/enhancements, plus many others. Check out all the dev notes here.

@earnjam reminded the group that each published dev note on Make/Core sends an email to ~4000 newsletter subscribers. He suggested authors limit each dev note to a single topic so people can find things in the index.

@francina shared WordPress 5.3: Accessibility focus progress report.

WordPress project Executive Director @chanthaboune brought up changes that are coming to the admin interface. She stated that the focus leads have been discussing whether to keep the changes or allow extra exploration time for them, as suggested in this post.

Here are the key stances she noted from the various discussions so far:

  • There are some concerns about how quickly the changes were decided on and then implemented from design.
  • There are some concerns raised about the process overall, and whether there’s enough time for testing. Josepha and a few core committers share this concern.
  • There are concerns that further delays will result in loss of momentum from accessibility as well as confidence in an iterative process.

Josepha said she’s doing her best to balance progress with caution, and that she has gotten a lot of feedback from the release focus leads.

Here are the different opinions that have been shared by people regarding this:

  • @garrett-eclipse said that when the changes landed in trunk with several bugs popping up all over, he was leaning towards the pull, but now that the team seems to have addressed and crushed the majority of them, he’s more in favor in keeping the changes.
  • @clorith reminded that while they are worth doing, he agrees on the fact that the changes may have come a bit late in the cycle with limited time for testing and exposure.
  • @mapk asked if the a11y improvements at the cost of design worth immediate and rapid merging, or if we can take the time we need to fully test and address issues?
  • @samuelsidler asked about the items of concerns/tasks that can not or will not be fixed before 5.3 Release Candidate.
  • @melchoyce answered @samuelsidler about tasks that can’t/won’t be fixed before 5.3 RC:
    • Wider design changes to account for the shift in the hierarchy; because the new form fields are so much darker than the list tables, any page where both exist is thrown off a little.
  • @mapk answered @samuelsidler saying that he believes there are other design explorations to address and a committed testing cycle for a large release.
  • @karmatosed shared some worries she has about this:
    • Documentation: those that write tutorials and might find their screenshots out of date.
    • Testing: A longer testing phase for her would be better just like during mp6 project. She thinks that 5.4 should be a focused release, with testing, time and iteration feel safer.
  • @joemcgill said that since he has not been part of the discussions, he would be more concerned by process problems keeping a11y improvements from shipping rather than shipping changes that improve a11y and then iterating on the design.
  • @afercia clarified that most of the design changes come from design and were implemented on top of the a11y improvements. He also mentioned that from an a11y perspective all the matters are:
    • Removing the fixed heights from the input fields etc.
    • Improving contrast
  • He also said that all the other changes are unrelated to a11y and came from design feedback.
  • @samuelsidler asked @melchoyce if there is a plan in place to fix/iterate on those visual issues for the future? If yes, when in the future? He also asked if those improvements happen in 5.3.x or they would need to be in 5.4 or later?
  • @melchoyce replied to @samuelsidler and said that he thinks they would be wide-reaching enough that the design team would need to ship them in 5.4.
  • @earnjam expressed that he would personally lean toward a more cautious approach and allowing further iterating as a feature plugin with an earlier merge in a release cycle to allow more time to catch/fix the bugs. He also feels like we’re trading one set of bugs/issues for a different set and doing it during the beta period.

This discussion has continued with different arguments from design and a11y team members and with other contributors as well. You can read the discussion in its entirety here.

Calls for components maintainers have been skipped for this chat.

Open Floor

@azaozz noted that he’s started to get concerned by the 100+ tickets that are still open for 5.3. He invited maintainers and committers to review and comment on tickets that must be in the release and move the rest to the Future Release milestone.

@afercia said that while the a11y team is committing a lot of things, they will need urgent feedback on #47069 and #43037. @ryokuhi gave a brief explanation about the last ticket.

@davidbaumwald said he’s planning a last-minute scrub due to the high number of tickets that are remaining for 5.3. The schedule for 5.3 scrubs can be found here. Again, everyone is welcomed to attend scrubs and also to organize them.

@justinahinon shared a “Special interest” he has about developer documentation, dev-notes, and WordPress codebase. You can read about it on the chat agenda comments.

@davidbaumwald reminded that they will be doing a lot of punting at the end of the week, so two things:

  • If you have a ticket you absolutely want in 5.3, get moving.
  • If not, at least leave a comment on feasibility for 5.4, or he’ll be moving everything to Future Release if they haven’t seen any movement in a while.

@desrosj clarified that the tickets owned by committers and maintainers have largely been left in the 5.3 milestone to allow those owners to make the decisions they feel are appropriate. If those tickets are not gardened in the next few days they will be punted.

Finally, @azaozz added that the best would be the component maintainers to decide what is good to be in 5.3 and what is going to be in 5.4 of future releases.

That’s the end for this long, lively and important devchat.

#5-3, #dev-chat, #summary

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 – https://make.wordpress.org/core/2019/09/04/feature-plugin-proposal-privacy-data-request-form/

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 – https://make.wordpress.org/core/2019/08/07/feature-plugin-discussion-a-consent-and-logging-mechanism-for-user-privacy/

@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  https://make.wordpress.org/core/2019/08/07/feature-plugin-discussion-a-consent-and-logging-mechanism-for-user-privacy/#comment-36281 

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 https://docs.google.com/document/d/171KgbxvNukyuuHwLiY14yhqfbs7X5KBkw6hvbEcQZ9k/edit

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 (https://docs.google.com/document/d/1ZXfT-Mvvfxa-ZjD9cSQG9BKvtTAhXuZb0QS5lK47BGY/edit?usp=sharing) in order to collaborate on some suggested questions for privacy.

#core-privacy, #privacy

Dev Chat summary: September 18

@francina was the chat leader. Archives for the chat can be found in #core on Slack.


@francina shared a devnote by Accessibility team. We also had an update from @audrasjb from Accessibility team who said they are working on creating accessibility devnotes for 5.3.

Upcoming Release Discussions

@ianbelanger gave an update of the work on default theme Twenty Twenty. A working version of the theme will be available on Monday for Beta 1 of WordPress 5.3. The development of the theme is happening on GitHub and contributions are more than welcome on the repository or in #core-theme channel on Slack.

@audrasjb make an update for Accessibility focus for 5.3. He remembered that they have 2 dedicated scrubs per week and that the team is currently coordinating with the Design team to determine which changes will be included in 5.3.

@jorbin gave an update for PHP 7.4 in WordPress. All the changes for the version are already landed in trunk. He also highlighted the great work of @desrosj and @jrf to make this possible. He finally announced the target is to fully support PHP 7.4 with WordPress 5.3.

@desrosj made a call for help for tickets in this report on WordPress Trac. People who own tickets in that report are invited to give them a status and to punt them if they feel that the tickets will not be ready for 5.3 release. Also owners who are not anymore available to continue working on their tickets are invited to remove themselves as owner and leave a status so that another contributors can take the relay.

REST API component maintainer @kadamwhite announce that the team is about to land a good set of enhancements before the Beta 1 deadline. Dev-notes for these changes will be published soon of Make/Core blog.

@garrett-eclipse from Privacy team announced that 4 privacy related enhancements have already been included for the release with no issues.

@antpb made an update for Media component, and remembered that the focus for the the release is around image handling and UI improvement and accessibility issues. Tickets for the focus can be found on WordPress Trac here.

5.3 Marketing Lead @mikerbg announced that the marketing team is working to organize content for the about page and other assorted release announcements. Progress on their work is tracked here.

@davidbaumwald remembered that scrubs schedule for 5.3 can be found here and that @marybaum volunteered to lead the one of October 9. Scrubs take place on #core channel on Slack and anyone interested in welcome to participe or to run scrubs.

Calls from component maintainers

@kadamwhite said 5.3 is probably the best release for REST API improvements in a long while, and that the team is grateful for everybody who has contributed to the component.

Open floor

@ianbelanger said Twenty Twenty team have been discussing the idea of having a demo site for the theme asked if this is something that can be done, and what happened for previous default theme. @kraftbj volunteered to help on this.

@kadamwhite asked for another persons eyes on #42094.

@garrett-eclipse asked help for review from available committers on #37782 before Monday.

@audrasjb pointed out #46312, a candidate for an easy commit action.

@hareesh-pillai asked for movements on https://meta.trac.wordpress.org/ticket/4706 as it is a blocker on #22994.

#5-3, #devchat, #summary

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

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

Agenda Item: 5.3 Enhancements

The following tickets were flagged as enhancements for 5.3 privacy component;

  • #43890 – Allow Admin to Skip e-mail confirmation for Export/Anonymization.
  • #44133 – Should the Data Export indicate when we have no information on the user.
  • #44135 – Have Erasure button workflow follow Export button workflow replacing with static link.
  • #44588 – Denote the Copy action is complete by updating the Copy button to state ‘Copied’.
  • #46303 – Update wp_privacy_send_personal_data_export_email to provide the same filters as _wp_privacy_send_erasure_fulfillment_notification.
  • #46895 – Personal Data Export Report: A way to display the group count.

#44133, #44135, #46303 and #46895 are all nearing completion but will need another set of eyes and review/testing before they can be marked commit.

#43890 and #44588 will need some work either a refresh or initial patch.
#43890 needs discussion but @garrett-eclipse is leaning towards the use of checkboxes instead of dropdown.
#44588 has site health example to follow and just needs coding.

@pputzer graciously offered to review some of these tickets.

Agenda Item: Privacy Data Request Form

Feature Plugin Proposal – https://make.wordpress.org/core/2019/09/04/feature-plugin-proposal-privacy-data-request-form/

Not much feedback has been received yet so will let it gestate a little more. Initial feedback is pointing towards plugin territory over a core merge.

@audrasjb indicated it would be nice to test as a featured plugin so will determine how that can be accomplished.

Agenda Item: Consent and Logging Mechanism for User Privacy

Feature Plugin Discussion – https://make.wordpress.org/core/2019/08/07/feature-plugin-discussion-a-consent-and-logging-mechanism-for-user-privacy/

@garrett-eclipse asked if the effort needs to be setup like the WP-Notify #feature-notifications team and meetings.

Neither @idea15 nor @garrett-eclipse have capacity currently to spearhead the effort so decided to collect names of interested parties to create a working group. If anyone is interested in working on the consent/logging mechanism please feel free to comment on this thread or reach out in #core-privacy on Slack.