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.

Introduction

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

XML Sitemaps Meeting: March 24th, 2020

In case you were looking for an blog post about the XML Sitemaps feature project last week, worry no more. Work on the plugin is progressing smoothly and steadily, we just didn’t publish an agenda post last week. That means it is time for a double update today!

Meeting Recap: March 10th & 17th

For reference, check my previous blog post from March 10th:

A lot has happened since then. Here’s the summary, not necessarily in the right order:

  • SimpleXML dependency
    We received great feedback from a variety of big hosting providers, all saying that this PHP extension is widely available and we can rely on it safely.
    Current status: no action needed.
  • Rewrite rule conflict with plugins
    As we realized that the new /wp-sitemap.xml URL format clashes with big existing plugins, we decided to look into alternate names for both the rewrite rules as well as the query params. See GitHub issue for details.
    Current status: needs contributors.
  • Rewrite rule issues with custom providers
    It was reported that adding custom sitemap providers might require flushing rewrite rules. Ideally, that shouldn’t be needed.
    Current status: needs decision.
  • Last modified date (lastmod)
    We decided to continue with the proposed PR to remove lastmod from sitemaps (at least for now), but need to make sure there is appropriate documentation. It’s something that can always be added back if needed.
    Current status: has PR, needs documentation.
  • Query Filters
    Valuable feedback emerged from testing, which led to the decision to close the existing PR to make query instances filterable in favor of a simpler approach. In its place, we should make the query arguments filterable, and also add filters to short-circuit queries.
    Current status: needs contributors.

Please let me know in the comments if I got something wrong in this summary!

Agenda: March 24th

The next meeting will be held on Tuesday, March 24 at 16.00 CET.

Today’s agenda is rather straightforward so far:

Want to add anything to the above? Please leave a comment here or reach out on Slack.

This meeting is held in the #core-sitemaps channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #feature-plugins, #feature-projects, #xml-sitemaps

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.

Announcements

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

Auto-updates feature meeting summary: March 17th, 2020

These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday March 17th, 2020. You can read the full transcript on the core-auto-updates Slack channel.

As a reminder, the Feature Plugin is developed on GitHub and is available for testing on WordPress.org plugins repository.

Current status of the project – version 0.3 🦉

Version 0.3.0 was released on Monday 16th. This release addresses a number of issues and introduces Email Notifications.

Changelog:

  • Add functions to handle plugins updates notification emails – PR 54
  • Remove update time text after manual update – PR 43
  • Ensure “Automatic Updates” column is not added if no content would be output in the column – PR 57
  • Specific messages for delayed or disabled cron events – PR 58
  • Prevent mis-match between count in Auto-updates Enabled view and the number of plugins displayed for that view by applying ‘all_plugins’ filter before computing that count. – PR 59

Thanks @pbiron for his invaluable help on version 0.3.

@audrasjb shared a screenshot with an example of email notification:

Please feel free to propose string changes to this first implementation of email notifications.

Version 0.4.0 will focus on backporting every auto-updates features to Themes. @audrasjb to merge this pull request as a first step for the work on themes support. Then, the idea is to open pull requests for each function/feature to be backported, so it’s easier to track progress on themes support.

@bookdude13 asked whether it’s better to open up issues to break up the work on the themes port, or to directly address them with pull requests.

@audrasjb will open an issue to list all the functions/feature that need proper backport and to track the team’s progression.

There is also a few background tasks opened by @jeffpaul concerning the GitHub repository.

Concerning Email notifications, @joostdevalk proposed to add links to the plugins changelog in those emails. @pbiron answered that it might be hard for plugins/themes not in the WordPress.org repo. @joostdevalk proposed to make it filterable. @audrasjb proposed to make the notification entirely filterable. @joostdevalk felt concerned about plugins that would override the email even when multiple plugins are updated at once.

@afragen proposed to use a filter that could be specific for each, like for example:
apply_filters( 'wp_autoupdates_email', $text, $slug )

This item will be discussed again during the next team meeting.

@pbiron wanted to discuss a specific pull request. It proposes to add filters to control whether the Enable/Disable buttons appear in the UI for a given plugin. @pbiron and @audrasjb agreed that having a filter that is specific to the UI is not the way to go and it is to be filterable then the existing auto_update_plugin hook should be used. For now, the pull request will stay open for further discussion.

Next meeting is planned on Tuesday March 24, 2020 at 18:00 UTC and will take place on #core-auto-updates Slack channel.

#auto-update, #feature-plugins, #feature-projects, #feature-autoupdates

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.

Announcements

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

Auto-updates feature meeting summary: March 10th, 2020 (kick-off meeting)

These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday March 10th, 2020. You can read the full transcript on the core-auto-updates Slack channel and find the meeting’s agenda here.

It was the first meeting for the Plugins & Themes Auto-updates feature, and this kick-off meeting was really efficient and worthwhile for the project 🚀

WP Auto-updates feature general scope

Here is the current general scope of the Feature Plugin:

  • Ability for website administrators to opt-in to automatic updates for plugins and themes in the related WP-Admin screens
    • ✅ Done for plugins
    • 🔲 Themes: needs to be ported. Slated for milestone 0.4.
  • Ability to enable/disable auto-updates on a plugin-by-plugin and theme-by-theme basis
    • ✅ Done for plugins
    • 🔲 Themes: needs to be ported. Slated for milestone 0.4.
  • Email notifications to send regular auto-update summaries to website administrators
    • 🔲 Plugins: Slated for milestone 0.3.
    • 🔲 Themes: Slated for milestone 0.4.
  • Hooks and constants to help developers disable or programmatically define auto-update settings
    • ✅ Done for plugins
    • 🔲 Themes: needs to be ported. Slated for milestone 0.4.

For the moment, the team started with plugins autoupdates, then all this work will have to be ported to Themes screen.

As a reminder, the Feature Plugin is developed on GitHub and is available for testing on WordPress.org plugins repository.

Current status of the project – version 0.2 🐝

Last week, version 0.2.0 was released with a lot of enhancements and bugfixes. Here is the complete changelog:

  • Remove auto-updates column from must-use and drop-ins screens – PR #39
  • Ensure the the enable/disable bulk actions appear in the dropdown and are handled in multisite – PR #38
  • Remove dashicon from “Enable” text in plugins auto-updates column – PR #36
  • Replace “Automatic Updates” with “Auto-updates” in filters – PR #35
  • Display only filters with at least one available plugin – PR #33
  • Remove setting from site option when deleting plugin – PR #32
  • Populate site health with plugins auto-updates informations – PR #24
  • In multisite, only add the “Automatic Updates” column on the plugins-network screen – PR #21
  • Add auto-update-enabled and auto-update-disabled views on the plugins screen – PR #18

@pbiron noticed some PHP notices on version 0.2.0 and made a pull request to fix them. It is milestoned for version 0.2.1, later this week.

@audrasjb shared some screenshots of the current design of WordPress Admin screens:

Click images to open them in full size (it will opens in a new tab).

@mclancy3 will open GitHub issues to provide some feedback on the Plugins screen’s user interface.

Work in progress

@pbiron raised an issue with a premium plugin that assumes there is no extra column on the plugins list table and add its own column with a colspan attribute. As mentioned by @clorith, this is not a bug in WP Auto-update feature plugin but rather a bug in this particular plugin. @jeffpaul proposed to add this to a Known Issues/Caveats section in readme files.

@jeffpaul also proposed to port the Features/to-do list section from readme.md into GitHub issues. @audrasjb already ported Email notifications and Themes auto-updates into issues, and @jeffpaul will take care of the remaining ones.

@jeffpaul pointed out that 10up uses two GitHub Actions to help deploy plugins to WordPress.org as well as readme/asset updates. He proposed to submit a PR to add those here and help streamline deploys to WordPress.org. For the moment, @audrasjb generates releases from the GitHub repository and deploy them manually on the plugin repository, using SVN. If it’s not a top priority, it would be nice to improve this workflow.

As proposed earlier in core-sitemaps meeting, @pbiron suggested to add a label to issues when something different will have to be done to the plugin code when it gets merged into core. @audrasjb stated that it would be nice to introduce this kin of labels and also to use DocsBlocks comments to point out things that will need specific implementation on WP Core. @jeffpaul proposed to use a GitHub pull request template for that.

About next development steps, @audrasjb is currently implementing email notifications. It shouldn’t be a problem given there is an useful automatic_updates_complete action to hook on.

Porting auto-updates features from Plugins to Themes will probably be a way more difficult, as there is not so much hooks in the Themes screen template. Themes in multisite is fairly straightforward, since a list table is used there, but for single sites there is no list table so what we’ve done for plugins won’t really apply. We’ll probably end up with JavaScript hacks to include the interface opt-in buttons and informations. @jeffpaul proposed to expand the focus of 5.4.x to include those hooks in the themes screen, which sounds like a perfect option right now.

Current GitHub issues

Issue 31: Automatically rollback to previous version if fatal errors detected after update

@audrasjb thinks this issue is out of the feature plugin’s scope. @clorith added that if auto-updates are off by default, yes this would be out of scope for the first release, but definitely something to look into in the future. If they are on by default, this would be a blocker. @audrasjb answered that Plugins, Themes and Core (major) auto-updates are all meant to be opt-in, in the 2020 general roadmap. The team agreed to keep this issue open for the moment.

Issue 13: Automatically delay/postpone updates

@audrasjb said Postponing updates is a great feature, but it’s not on this feature plugin scope, and not sure it’s even in Core scope. @clorith pointed out that the core solution should facilitate by providing filters and such, but not add all those options. The team agreed to keep this issue open for the moment.

Next steps

  • @audrasjb will focus on email notifications development and grant GitHub commit access to @pbiron.
  • A call for testing will be published on Make/Test once 0.2.1 is released with the PHP notices fixes.
  • @jeffpaul will work on improving the GitHub repository organization.

Next meeting is scheduled on Tuesday March 17, 2020 at 18:00 UTC and will take place on #core-auto-updates Slack channel.

#auto-update, #feature-plugins, #feature-projects, #feature-autoupdates

XML Sitemaps Meeting: March 10th, 2020

A lot has happened since last week’s meeting for the XML Sitemaps feature project. Here’s a quick rundown of what we’ve discussed & did, as well as a brief agenda for today’s meeting.

Meeting Recap: March 3rd

For reference, please check out last week’s agenda post:

The tl;dr of our discussion:

  • Disabling sitemaps for private sites
    Mentioned the currently open PR and how it could be used to kill two birds with one stone by making that process filterable; thus making it easier for plugins to disable the sitemaps feature.
    Current status: needs tests
  • Prefixing sitemap URLs
    The main PR for this change has been merged, a new issue has been opened for @kraftbj to handle 404 requests.
  • SimpleXML dependency
    We went over potential alternatives to this extension, but ultimately settled on sticking with the status quo as initial feedback indicated a rather wide availability of SimpleXML. We then discussed how we should gracefully handle the unavailability of said extension and decided on using wp_die to output a nicely formatted error message in XML with HTTP status 501 (“Not implemented”).
    Current status: merged!
  • @joemcgill proposed looking into how to best transition the code base to something more in line with WordPress core. Something that we can discuss in a future meeting, once the plugin is more stable.
  • Added @pbiron, @kraftbj, and @pfefferle as new contributors to the GitHub repository. 🎉

Agenda: March 10th

The next meeting will be held on Tuesday, March 10 at 16.00 CET.

PSA: Unfortunately I won’t be able to lead today’s meeting, but thankfully @tweetythierry stepped up to help out with this.

Today’s agenda is rather straightforward so far:

  • Released version 0.2.0 of the plugin (changelog)
  • Plugin compatibility with new URL structure
    Yoast SEO’s rewrite rules seem to clash with ours
  • SimpleXML dependency: blog post on make/hosting (@pbiron)
  • Currently open issues and pull requests
  • Open floor

Want to add anything to the above? Please leave a comment here or reach out on Slack.

This meeting is held in the #core-sitemaps channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #feature-plugins, #feature-projects, #xml-sitemaps

Auto-updates kick-off Meeting Announcement

Last week, WP Auto-updates Feature Plugin was introduced with a post on Make/Core to give everyone an idea of where it is heading.

Now, the idea is to gather more contributors around the feature plugin and get your feedback on the project.

For this, let’s kick-off regular meetings in the brand new #core-auto-updates Slack channel.

The first meeting will be held on Tuesday March 10th, 2020 at 18:00 UTC and will serve as an introduction to the project and as an opportunity to discuss the next steps.

Proposed agenda:

  • WP Auto-updates feature general scope
  • Current status
  • Next steps
  • Openfloor / issues and pull requests reviews

If you have anything specific that you’d like to propose being discussed in this meeting, feel free to leave a comment below.

This meeting is held in the #core-auto-updates Slack channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#auto-update, #feature-plugins, #feature-projects, #feature-autoupdates

XML Sitemaps Meeting: March 3rd, 2020

Another week passed by with quite a productive meeting for the XML Sitemaps feature project. Here’s a short summary, as well as the agenda for today’s meeting.

Meeting Recap: February 25th

In case you missed it, I recommend checking out last week’s post with everything that happened so far:

As planned, we went over some of the existing issues, but we also discussed some things that came up on short notice. Here’s the gist:

  • We reiterated on the idea to remove the lastmod field. @swissspidy offered to start a PR that explores this so it can actually be tested in the wild. @joemcgill offered to post some stats about the performance of this last modified date calculation.
  • There was a discussion, also after the meeting, about changing URLs to have a /wp- prefix and whether that prefix should be filterable. The consensus was that a filter is unnecessary. A new PR was added to implement this.
    @kraftbj offered his help to implement automatic redirects from /sitemap.xml to /wp-sitemap.xml for improved discoverability.
  • Next up was the SimpleXML dependency and how the plugin should behave when that PHP extension is missing.
    We tend towards just disabling sitemaps if that’s the case, but perhaps provide some messaging about it.
    @kraftbj offered to try to get some stats about the availability of SimpleXML via Jetpack, as well as to help with a PR.
    @pbiron reached out on the hosting community channel, and is looking for specific questions that we could ask in a make/hosting post.
  • Last but not least, there was an open question about leveraging the REST API for sitemaps. It was not fully clear though how that would be beneficial. As of now, there are no plans to explore this.

Agenda: March 3rd

The next meeting will be held on Tuesday, March 3 at 16.00 CET

This meeting is held in the #core-sitemaps channel , to join the meeting, you’ll need an account on the Making WordPress Slack.

#agenda, #feature-plugins, #feature-projects, #xml-sitemaps

Feature Plugin: WP Auto-updates

In 2018, @matt posted 9 projects for Core to focus on in 2019. This roadmap was updated for 2020. Plugins and Themes automatic updates is one of those 9 projects. WordPress contributors did a lot of work on the two related tickets during WP 5.4 development cycle, but decided to give it more time for testing as it’s an important feature. This project is now planned for WordPress 5.5 and the feature is going to be tested in a Feature Plugin.

For reference, see the two related Trac tickets:

A lot of interesting points were discussed in the tickets above, including the scope of the feature and the user interface/design. Many thanks to everyone who already contributed to this exciting new feature ♥️

Now, the development that happened in the related tickets are moved into WP-Auto-updates Feature Plugin which is available for testing and feedback. Contributions from the WordPress community are welcome on the plugin’s GitHub repository.

Project overview

As a quick reminder of what this project is trying to achieve, here are the main features that are being worked on:

  • Ability for website administrators to opt-in to automatic updates for plugins and themes in the related WP-Admin screens.
  • Ability to enable/disable auto-updates on a plugin-by-plugin and theme-by-theme basis.
  • Email notifications to send regular auto-update summaries to website administrators.
  • Hooks and constants to help developers disable or programmatically define auto-update settings.

Design considerations

The current design of the feature plugin reflects the last ideas that were discussed in #48850. This is still a work in progress and the implementation will probably evolve, as WordPress contributors discuss the feature on GitHub.

Latest Plugin screen mockup in #48850
WP Autoupdates screenshot
Current implementation in WP Auto-updates Feature Plugin – version 0.1.2

Here is the proposed roadmap:

  • ✅ Create feature plugin
  • ✅ Submit feature plugin to WordPress.org repository
  • ✅ Get the plugin featured as beta plugin on WordPress.org
  • 🔲 Move the repository to WordPress.org GitHub account
  • ✅ Publish the feature plugin proposal
  • ✅ Open a dedicated Slack channel on Make WordPress
  • ✅ Organize weekly meetings
  • ✅ Handle plugins auto-updates
  • 🔲 Handle themes auto-updates
  • ✅ Handle plugins auto-updates in a multisite context
  • 🔲 Handle themes auto-updates in a multisite context
  • ✅ Add hooks and constants for plugins
  • 🔲 Add hooks and constants for themes
  • ✅ Add email notifications for plugins
  • 🔲 Add email notifications for themes
  • ✅ Add auto-updates information in update-core screen
  • 🔲 Validate design for plugins screen
  • 🔲 Validate design for themes screen
  • 🔲 Validate design for update-core screen
  • 🔲 Full documentation for new functions, hooks and constants
  • 🔲 Copy review
  • 🔲 Accessibility review
  • 🔲 Security review
  • 🔲 Coding standards review
  • 🔲 Inline Docs review

Last update: March 21, 2020

Next steps

The release of the WP-Auto-updates feature plugin is an early step in the process of having this functionality included in WordPress Core. Now, your help is needed to test, validate, and improve the current feature to ensure that it meets the needs of the WordPress community. Plugin and theme authors, hosting companies, WordPress developers and users are welcome to share their thoughts about this feature.

#5-5, #feature-plugins, #feature-autoupdates