Sorry, I couldn’t help myself…
In November 2020, I posted about an initiative to update the updaters. It took a bit longer than expected to research the issue and an efficient way to manage the project, but here we are.
Context
The WordPress updaters are a set of PHP The web scripting language in which WordPress is primarily architected. WordPress requires PHP 5.6.20 or higher classes that assures that users can safely upgrade WordPress core Core is the set of software required to run WordPress. The Core Development Team builds WordPress., plugins, themes, and translations.
The ability to manually update WordPress from the admin (and super admin) area, and to install and update plugins and themes, has existed since 2.3 in 2007. Auto-update features were added in WordPress 3.7 (for minor releases), extended in 5.5 (as opt-in for plugins and themes), and 5.6 (major releases). To make the user experience of auto-updates even better, and build trust with users and extenders, it’s important that this mechanism works well and provides all the failsafe checks needed.
The WordPress Core update has proven to be generally reliable, but it doesn’t actually have many tests nor is well documented. There are also some reliability concerns around adding new files and the overall number of changed files, which is the reason WordPress currently tries to keep the number of changed files in minor releases to a minimum.
Plugins and themes updaters are older: in general, all of them can be improved.
Goal
The project goal is to review the existing state of the updaters and propose ways to improve them.
Outcomes
The expected outcomes are:
- Make sure the zips upload and unpacking are safe.
- Create a mechanism to upgrade and rollback.
- Have managed updates (database migrations).
- Create a unified JSON JSON, or JavaScript Object Notation, is a minimal, readable format for structuring data. It is used primarily to transmit data between a server and web application, as an alternative to XML. convention for requirements and dependencies.
Outcome 1 – Make sure the zip uploads and unpacking are safe
With the introduction of auto-updates, these processes run more frequently.. So relatively small issues get triggered more often, and with that become a bigger problem. They also now more often run unattended: an auto-update that breaks could lead to quite problematic results.
The goal here is to address most of the known issues related to:
- downloading and extracting update packages
- copying files and directories
- improving documentation for updates
- adding some automated tests
- making the update process more reliable in general
Related Trac An open source project by Edgewall Software that serves as a bug tracker and project management tool for WordPress. tickets
Edited 2021-05-06T19:38 MDT: added #36710 and #36373 to the list of tickets. @pbiron.
Outcome 2 – Create a mechanism to upgrade and rollback.
When a core auto-update fails, core has long had the ability to automatically attempt a “rollback” to the latest stable release (in the branch A directory in Subversion. WordPress uses branches to store the latest development code for each major release (3.9, 4.0, etc.). Branches are then updated with code for any minor releases of that branch. Sometimes, a major version of WordPress and its minor versions are collectively referred to as a "branch", such as "the 4.0 branch". that the site is running). Note: for core auto-updates, “rollback” is not attempted for certain failures (e.g. “disk full”, etc).
This capability should be extended to be available for plugin and theme updates. Work on some of these issues is already undergoing as part the rollback update feature.
Related Trac tickets
Outcome 3 – Have managed updates (database migrations)
Plugins should be able to easily run database migrations, so that update and rollback could be performed not only for files but also for data.
Yoast already does this by having a migrations library:
If we had a unified process for data migrations in core, WordPress would be able to run the latest available migration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. after an update or rollback:
- without the need to store anything about the previous state
- without requiring anything from the plugin author, apart from adding a “migrations” folder
Relevant Trac tickets
Outcome 4 – Create a unified JSON convention for requirements and dependencies.
Different plugins have introduced compatibility tags (For example, Elementor and WooCommerce). In the long run, this could become harder to manage.
Relevant Trac tickets
@afragen has written a lightweight library, wp-dependency-installer, that takes a JSON config file and can install a suggested or required plugin dependency. He mentions this as a lighter-weight solution to something like the TGMPA library. This makes it possible to solve many of the issues above.
How to contribute
- Familiarize yourself with the existing classes, listed above.
- Update your local WordPress SVN (use
svn up
) or Git repo (use git pull
) to the latest version of WordPress trunk A directory in Subversion containing the latest development code in preparation for the next major release cycle. If you are running "trunk", then you are on the latest revision.. - Pick a ticket Created for both bug reports and feature development on the bug tracker. from the above list, review its history, refresh it if needed or make a new patch 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..
- Upload your patch to the Trac ticket you created, and add the keywords
has-patch
and needs-testing
- If during the exploration of the above goals you can think of other enhancements, please create a new ticket and assign it to the Update/Install component
Keeping Discussions Focused
Any discussion about the specifics of a patch itself should happen on Trac. Any discussion about the broader scope of what this feature project is about should take place during the weekly chat in the #core-auto-update Slack Slack is a Collaborative Group Chat Platform https://slack.com/. The WordPress community has its own Slack Channel at https://make.wordpress.org/chat/..
What’s next?
See you on May 4, 2021 at 17:00 UTC for the kickoff meeting, during the weekly #core-auto-update.
In the meantime, if you already know that you want to work on a specific goal or a specific ticket, please leave a comment.
Thank you!
Thanks @afragen, @audrasjb, and @hellofromtonya for the peer review. Thanks @sergeybiryukov for combing through Trac to look for the tickets!
#auto-updates, #updater