[Request for feedback] Updater Proof of Concept

Welcome!

The WordPress coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. development team builds WordPress! Follow this site for general updates, status reports, and the occasional code debate. There’s lots of ways to contribute:

Found a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority.? Create a ticket in our bug tracker.

Want to contribute? Get started quickly with our tickets marked as good first bugs for new contributors or join a bug scrub. There’s more on our reports page, like patches needing testing, and on our feature projects page.

Other questions? We also have a detailed handbook for contributors, complete with tutorials.

Over the past month, @aristath and @sergeybiryukov have been working on a proof of concept to solve the two first outcomes highlighted in the Updater Initiative scope post.

They drew inspiration from the https://wordpress.org/plugins/rollback-update-failure/ 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 and tried to address a few tickets.

They created a proof of concept that can be found in a draft PR on https://github.com/WordPress/wordpress-develop/pull/1492/files and does the following:

Add new arguments to hook_extra passed by plugin and theme updates to ensure we can rollback to the correct version.
After a plugin/theme is successfully downloaded and extracted, the old plugin/theme folder is moved to wp-content/upgrade/rollback/plugins/PLUGIN or ~~wp-content/upgrade/themes/THEME~~ wp-content/upgrade/rollback/themes/THEME (thanks Paul Bigai for catching that)
If the plugin/theme was successfully installed, the backup of the previous version we kept in wp-content/upgrade/rollback/ is deleted.
If the plugin/theme was not successfully installed, then we cleanup any remnants of files in wp-content/plugins/PLUGIN (or the corresponding folder for themes), and then we move the backup we kept in the rollbacks folder back to its original location.
Adds info in the site-health screen, to make sure the rollback folder is writable (or can be created if it doesn’t exist)

That is the basic concept. The team ran some tests, helped by @peona as well and it seems to be working.

The main difference with the rollback-update-failure plugin is that this solution moves the plugin/theme folders instead of zipping/unzipping them. This change should help to make the implementation a bit lighter/safer on shared hosts with limited resources.

Before moving forward, I would like to ask the Upgrade/Install Maintainers to have a look at this and discuss together, in the comments of this post, if you agree with this change, if it works, etc…

I am not setting a deadline for the comments, but ideally, I would like to be able to write a merge proposal for 5.9 so I will review the post in mid-~~July~~August (thanks @meher for pointing out that we are at the end of July already 😂) and nudge a bit more 😉

Thank you all for your help and feedback!

Thanks @ipstenu for the peer review

#updater

Daniele Scasciafratte 12:26 pm on July 23, 2021

Just my first feedback there are any plans like a filterFilter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. to disable the rollback feature?

I am looking this as security stuff, as usually you update to remove old versions of themes or plugins affected. Also if they are not enabled they can be sources of troubles or have php files that can be called outside wordpress.

I think that something that ensure this is required like htaccess rules to disable the execution of those php file is important or zip those files.
- Ari Stathopoulos 8:05 am on July 28, 2021
  
  The goal of this project is to make the process of updating 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 or a theme more secure and less prone to errors.
  The “rollback” is not something that stays, it’s a temporary backup of the plugin/theme to be updated, and as soon as the update is successfully completed, that backup is deleted from the filesystem. The rollback’s only purpose is so that in case of an update error, we can restore the site to what it previously was without breaking anything.
  These “rollback” folders are not exposed to users, ie they can’t say “I want to rollback this plugin to the previous version I had”, it’s just a transient backup which usually has a lifetime of a few seconds (or as long as it takes to perform an update).
  The reason this approach doesn’t go with zipping files, is because zipping a large plugin folder requires significant system resources that a low-end shared host may not be able to spare. Moving the folders is fast, requires practically zero resources, and achieves the goal of having a transient backup to restore if the update fails.
  - Pascal Birchler 5:52 pm on August 3, 2021
    
    I think to avoid confusion like this we should rename those “rollback” folders to something like “backup” or “temp-old-files” or something.
    - Ari Stathopoulos 10:52 am on August 18, 2021
      
      Good point. I combined the 2 and named the folder temp-backup 👍
  - Andrei Draganescu 9:00 am on August 4, 2021
    
    +1 to @swissspidy ‘s suggestion to include some kind of `temp` in the name.
    - Francesca Marano 6:40 pm on August 17, 2021
      
      cc @aristath ICYMI 🙂
overclokk 4:06 pm on July 29, 2021

I like this idea, I don’t see any issue on that.
Andrei Draganescu 9:01 am on August 4, 2021

The one thing I had reading this is a gut worry related to countless rollback folders remaining behind because of “in between” failures.
- Francesca Marano 6:43 pm on August 17, 2021
  
  Never underestimate gut worries! @andraganescu can you please elaborate on the PR? https://github.com/WordPress/wordpress-develop/pull/1492
  Today, August 17, there was an upgrade/install component meeting where the solution was discussed but there are more steps to take before this makes it into CoreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress., so please add your feedback so @aristath can take it into account. Thanks 🙂
  - Andrei Draganescu 4:15 pm on August 18, 2021
    
    Thanks! I Think @aristath ‘s idea below is quite good 🙂
- Ari Stathopoulos 11:36 am on August 18, 2021
  
  @andraganescu Hmmm when an update succeeds, the temp-backup gets deleted. When there’s an update failure, the temp-backup is moved back to its original location. So both on success and failure, the temp-backup gets deleted or moved.
  The only case I can think of that would cause the temp-backups to not be empty, is if the delete/move action failed. Which would indicate there’s something wrong – and we added an extra section in the site-health screen for the folder’s permissions, to make sure that’s not an issue.
  Do you think it would be useful to have a weekly action that just deleted the temp-backup folder to make sure there’s no remnants? 🤔
  - Andrei Draganescu 3:57 pm on August 18, 2021
    
    it would be useful to have a weekly action that just deleted the temp-backup folder
    
    Yes! I think that is a very good idea 🙂 It prevents cruft from piling up.
    
    Websites are long lived projetcs that could go through hundres of updates for plugins and themes. We may have a perfected approach like the one you describe, but if a bugbug A bug is an error or unexpected result. Performance improvements, code optimization, and are considered enhancements, not defects. After feature freeze, only bugs are dealt with, with regressions (adverse changes from the previous version) being the highest priority. slips in, or a config issue of sorts, and there is time that passes until said bug is fixed and the fix takes time to make it through, cruft. That weekly job is a low effort cleanup worth considering.
    - Ari Stathopoulos 12:12 pm on August 26, 2021
      
      Just an update here, yesterday I implemented this extra action and the contents of the temp-backup folder will be cleaned-up on a weekly basis, and added a few extra checks to make sure the cleanup action does not get triggered in case there is an update currently running (see commit)
Paul Kevin 5:18 pm on August 17, 2021

I like it personally. Makes a lot of sense and I think it will be a great feature making WordPress updates/upgrades safer. The logic is spot on

Comments are closed.

Welcome!

Communication

Share this: