Auto-updates feature meeting summary: May 12, 2020

These are the weekly notes for the WP Auto-updates team meeting that happened on Tuesday May 12, 2020. You can read the full transcript on the coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress.-auto-updates SlackSlack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/. channel.

Reminder, WP Auto-updates Feature PluginFeature Plugin A plugin that was created with the intention of eventually being proposed for inclusion in WordPress Core. See Features as Plugins. is developed on GitHub and is available for testing on WordPress.org plugins repository.

Update on core 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.

@pbiron is in charge of the core patch. It should be ready around the middle of this week. Paul asked whether it’s better to do a pull request against wordpress-develop GitHubGitHub GitHub is a website that offers online implementation of git repositories that can can easily be shared, copied and modified by other developers. Public repositories are free to host, private repositories require a paid subscription. GitHub introduced the concept of the ‘pull request’ where code changes done in branches by contributors can be reviewed and discussed before being merged be the repository owner. https://github.com/ repository or a diff file on TracTrac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress..

@azaozz answered both would work, and have different pluses and minuses:

  • Pull requests can be reviewed in inline comments, but are harder to modify by different people.
  • A diff file would need to be applied to a svn checkout before testing, but easier to iterate (to 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). new diffs)

Paul will send a diff file.

WP auto-updates version 0.8.0

Here are the expected steps for the core merge:

  1. Publish the diff file on the related Trac ticketticket Created for both bug reports and feature development on the bug tracker. (#50052)
  2. After merge details are known, update Pull request #123 – Self-deactivate the plugin after the functionality has been merged to core
  3. 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. WP Auto-updates version 0.8
  4. Commit the Trac diff file to WordPress Core

@azaozz noted that releasing version 0.8 after the diff is available on Trac is needed to make sure the 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 can self deactivate once the diff file is merged into WordPress core. The check in version 0.7 doesn’t actually work with the patch, because the name of the function it is checking changed in the patch

The plugin’s options should also be deleted from WordPress installs once the plugin is uninstalled by sites owners. @audrasjb opened pull request #125 to handle that.

The team noted the feature plugin reached 900+ active installs. 77% are running version 0.7, 12% are running version 0.6 and 11% are running versions 0.6.0 or less.

@whyisjake also implemented prettier on the plugin. It allows to run CSSCSS Cascading Style Sheets./JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. lint check, using npm test , and to fix linting issues using ESLint --fix option.

Open floor

@azaozz shared some thoughts about keeping some stats on successful/failed autoupdates, on the WordPress.orgWordPress.org The community site where WordPress code is created and shared by the users. This is where you can download the source code for WordPress core, plugins and themes as well as the central location for community conversations and organization. https://wordpress.org/ 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. side. It’s not a blockerblocker A bug which is so severe that it blocks a release. for merging and can be added later. The idea is to potentially have anonymous/aggregated stats per plugin/theme. This is also related to the Tide project, which can use those stats to determine how “safe” an update may be.

@audrasjb asked if it’s directly related to this feature or if it should be handled in a separate ticket/project. For @azaozz, it is part of plugins and themes auto-updates, but it can be a separate Trac ticket.

@pbiron asked if we were talking about stats on the results of auto-updates, or about user preferences for what should be auto-updated (since whether an auto-update is attempted can be controlled by other plugins, such as Easy Updates Manager, etc). Andrew answered that it may be both.

@audrasjb asked what would be the main benefit for the end user? Having prompts to alert on “not recommended” updates? @azaozz doesn’t think it would be a direct communication but an auto-update may be eventually stopped/postponed if there are many failures.

@apedog wanted to mention a version-rollback feature for plugins. For them, it would become relevant as more installations start using WP Auto-updates feature plugin. @audrasjb answered it should eventually be introduced independently of auto-updates feature as it’s not only related to this type of updates mechanism. @apedog pointed out that breakage occurring from a manual update gives the user immediate feedback. An over-night auto-update (especially if multiple plugins/themes were updated) could make debugging much harder. @audrasjb added that the best way to move this independent project forward is to open a ticket on Trac if it doesn’t exists yet. @sergeybiryukov added that WP Core do perform a rollback if a background core update fails (enabled for minor versions by default), that might be helpful when looking into implementing this for plugins and themes too.

@apedog also asked whether WP Auto-updates log the previous version vs new version? For example, for a user encountering breakage from an auto-update. Sitesite (versus network, blog) breakage can occur even on successful updates – simply due to conflictconflict A conflict occurs when a patch changes code that was modified after the patch was created. These patches are considered stale, and will require a refresh of the changes before it can be applied, or the conflicts will need to be resolved.. @audrasjb answered there is no such log mechanism in core, even for manual updates.

@pbiron asked @audrasjb if Pull request 121 – Add help tabs on update-core, plugins, and themes admin screens is going to be ready on time for version 0.8.0. @audrasjb is on it, but it will probably needs copy review.

The team agreed Help Tabs will be handled separately from the initial core patch, to give it time for copy review.

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