Devchat meeting summary – April 15, 2020

@davidbaumwald facilitated the chat on this agenda.

Full meeting transcript on Slack

Highlighted blogblog (versus network, site) posts

Upcoming Releases

WordPress 5.5 major releasemajor release A release, identified by the first two numbers (3.6), which is the focus of a full release cycle and feature development. WordPress uses decimaling count for major release versions, so 2.8, 2.9, 3.0, and 3.1 are sequential and comparable in scope.

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 releaseMinor Release A set of releases or versions having the same minor version number may be collectively referred to as .x , for example version 5.2.x to refer to versions 5.2, 5.2.1, 5.2.3, and all other versions in the 5.2 (five dot two) branch of that software. Minor Releases often make improvements to existing features and functionality.

@audrasjb shared that on the 13 tickets in the milestone, 12 are already committed and one ticketticket Created for both bug reports and feature development on the bug tracker. 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 candidaterelease candidate One of the final stages in the version release cycle, this version signals the potential to be a final release to the public. Also see alpha (beta). next week and a final releaseRelease A release is the distribution of the final version of an application. A software release may be either public or private and generally constitutes the initial or new generation of a new or upgraded application. A release is preceded by the distribution of alpha and then beta versions of the software. in two weeks.

Components Check-in

@imath shared an update on Comments component:

  • He is working on a pluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party to progress about #35214
  • It would be nice to get some feedback on #49236, since it would be nice to have a patchpatch A special text file that describes changes to code, by identifying the files and lines which are added, removed, and altered. It may also be referred to as a diff. A patch can be applied to a codebase for testing. 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 AccessibilityAccessibility Accessibility (commonly shortened to a11y) refers to the design of products, devices, services, or environments for people with disabilities. The concept of accessible design ensures both “direct access” (i.e. unassisted) and “indirect access” meaning compatibility with a person’s assistive technology (for example, computer screen readers). (https://en.wikipedia.org/wiki/Accessibility) team main focuses for WP 5.5:

@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 makemake A collection of P2 blogs at make.wordpress.org, which are the home to a number of contributor groups, including core development (make/core, formerly "wpdevel"), the UI working group (make/ui), translators (make/polyglots), the theme reviewers (make/themes), resources for plugin authors (make/plugins), and the accessibility working group (make/accessibility). 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 coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. 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 pluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. or can that be worked on after the feature plugin is merged into core? He think the WP_Automatic_Updater class has enough hooksHooks In WordPress theme and development, hooks are functions that can be applied to an action or a Filter in WordPress. Actions are functions performed when a certain event occurs in WordPress. Filters allow you to modify certain functions. Arguments used to hook both filters and actions look the same. 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 URLURL A specific web address of a website or web page on the Internet, such as a website’s URL www.wordpress.org is provided in the APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. 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 UIUI User interface 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