@davidbaumwald facilitated the chat on this agenda.

Full meeting transcript on Slack

Highlighted blog posts

• What’s new in Gutenberg? (15 April)

Upcoming Releases

WordPress 5.5 major release

WordPress 5.5 Call for Tickets is still open for feedback.

@sageshilling shared that the Editor team is working on a Gallery block update for WP 5.5.

WordPress 5.4.1 minor release

@audrasjb shared that on the 13 tickets in the milestone, 12 are already committed and one ticket still needs some work.

@whyisjake self nominated to lead WordPress 5.4.1. @davidbaumwald added that if anyone is interested in helping with 5.4.1, they can get in touch with @whyisjake. @audrasjb expressed his interest.

The idea is to ship a release candidate next week and a final release in two weeks.

Components Check-in

@imath shared an update on Comments component:

• He is working on a plugin to progress about #35214
• It would be nice to get some feedback on #49236, since it would be nice to have a patch committed early
• Feedback is also needed on #49179

@clorith pointed out that it would be nice to move forward on Dashboard Namespace introduction in REST API. Volunteers are welcome to contribute to the associated tickets.

@audrasjb shared the Accessibility team main focuses for WP 5.5:

• Accessible color schemes (GitHub repository)
• Alternative WP List Tables views
• Refine/replace the upper-right WP-Admin fly-out menu
• And of course, address the 32 tickets already in the milestone

@audrasjb also shared an update about WP Auto-updates feature plugin: version 0.5 was released just before the devchat. It addresses all the feedback received from the Design and Accessibility teams.

Open floor

@audrasjb raised a question concerning WP Auto-updates feature: should it provide a way to rollback to the previous version of an auto-updated plugin? This feature was proposed in a GitHub issue.

@imath believes WordPress could make it easier to come back to a previous version of a plugin.

@timothyblynjacobs pointed out that one of the big issues with rolling back, is that if a plugin does any kind of DB change, it can’t necessarily rollback without data loss or other breakage.

@clorith added that it might “double” the time needed per update in doing so, maybe even triple if it needs to revert as well, the increase in memory consumption, and processing time adds a new layer of potential failures as well.

@afragen raised this could be detected by the new WSOD so at least it wouldn’t white screen a site. @timothyblynjacobs answered WSOD protection would notice the error, but wouldn’t automatically deactivate the plugin.

@timothyblynjacobs thinks it would also be worth clarifying whether this would be limited to the updater automatically rolling back, or it being available for the user to take action.

For @sageshilling, ideally, the update if automated, would check for known problems and either notify site owner if detected during import.  If possible, stop import, roll back and allow the site owner to address it.

@clorith thinks the correct approach is yes, keep a backup until the update is completed so it can be reverted, and introduce an actual feature for plugins/themes to run upgrade tasks after the fact, that way the site can be confirmed still functional without triggering any DB upgrades for example.

@timothyblynjacobs thinks there would be value to plugins being able to rollback the same way core does if the actual upgrade process fails. But he think having a WP-Rollback [note: it’s a plugin available on the repository] type solution in core should be a separate project.

As WP Auto-updates co-lead, @pbiron added an other question to the discussion: if one want to rollback, is that something that should be in the feature plugin or can that be worked on after the feature plugin is merged into core? He think the WP_Automatic_Updater class has enough hooks that we could work on it in the feature plugin, but it might be difficult.

@desrosj point out that the way core handles rollbacks currently is a rollback URL is provided in the API response, and it gets retrieved if a severe failure occurs. There is no equivalent link returned in the API response for plugin updates.

@imath believes it’s better to have a way to manually upgrade/downgrade a plugin in WordPress before merging the feature into Core.

@desrosj thinks that for the first iteration, the WSOD may be enough for a non-technical to recover from an issue. Enabling auto-updates for plugins and themes will be opt-in, so maybe there just needs to be appropriate messaging when the site owner enables an auto-update for the first time.

@clorith agreed, when/if the feature is enabled by default, it needs rollback, but for a first iteration with manual enablling, let’s roll with what a manual way of reverting, sounds reasonable.

@audrasjb pointed out that managing updates rollback is a project in itself as it is something that should be currently available for manual updates.

@afragen asked: aren’t core rollbacks only for critical errors? Any plugin downloads and updates correctly but results in a fatal because of a coding issue sets a higher bar than we have for core.

@pbiron added that the current scope of the feature plugin has been providing a UI for enabling/disabling auto-updates, and rollback seems to be another feature plugin itself. Also, there is a notification email that gets sent with updates successes and failures. Also @timothyblynjacobs added that WSOD would send a recovery mode email if a site has fatal error on protected endpoints. @desrosj added that in the current process to manually upgrade a plugin in the dashboard today, there is no protection for a fatal error or coding error in the plugin.

@audrasjb raised that a rollback feature would be a nice improvement to WordPress Core, but it’s useful for both manual and auto updates.

#5-4-1, #5-5, #feature-autoupdates