[wp-trac] [WordPress Trac] #53705: Plugin upgrade deletes files from other in-progress upgrades
WordPress Trac
noreply at wordpress.org
Thu Mar 31 22:10:49 UTC 2022
#53705: Plugin upgrade deletes files from other in-progress upgrades
-----------------------------+---------------------
Reporter: bpayton | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: 6.0
Component: Upgrade/Install | Version: 5.8
Severity: normal | Resolution:
Keywords: | Focuses:
-----------------------------+---------------------
Comment (by bpayton):
Replying to [comment:16 peterwilsoncc]:
> Replying to [comment:6 bpayton]:
> I've been thinking about this and don't think it's a wise idea.
>
> In terms of meeting the website owners expectations: this approach would
leave unexpected files on the server in an unexpected location.
>
@peterwilsoncc, thank you for taking time to think about this.
I agree that leaving unexpected files on a server is undesirable, but I
don't believe this code bears primary responsibility for that cleanup.
Here's my thinking:
In general, WordPress attempts to cleanup working files after an upgrade
is done or an error occurs.
Core updates attempt to clean up working files. (refs:
[https://github.com/WordPress/wordpress-
develop/blob/16baa3877991d521cb69df712f1e1be9f61791bb/src/wp-
admin/includes/class-core-upgrader.php#L157-L158 1],
[https://github.com/WordPress/wordpress-
develop/blob/16baa3877991d521cb69df712f1e1be9f61791bb/src/wp-
admin/includes/update-core.php#L978-L979 2], [https://github.com/WordPress
/wordpress-develop/blob/16baa3877991d521cb69df712f1e1be9f61791bb/src/wp-
admin/includes/update-core.php#L992-L993 3], [https://github.com/WordPress
/wordpress-develop/blob/16baa3877991d521cb69df712f1e1be9f61791bb/src/wp-
admin/includes/update-core.php#L1027-L1028 4],
[https://github.com/WordPress/wordpress-
develop/blob/16baa3877991d521cb69df712f1e1be9f61791bb/src/wp-
admin/includes/update-core.php#L1201-L1202 5],
[https://github.com/WordPress/wordpress-
develop/blob/16baa3877991d521cb69df712f1e1be9f61791bb/src/wp-
admin/includes/update-core.php#L1392-L1393 6],
[https://github.com/WordPress/wordpress-
develop/blob/16baa3877991d521cb69df712f1e1be9f61791bb/src/wp-
admin/includes/update-core.php#L1433-L1434 7])
The WP_Upgrader class knows how to clean up after itself after installing
a package. The WP_Upgrader::install_package() method takes a
`clear_working` argument, and if that argument is truthy, the working
files are [https://github.com/WordPress/wordpress-
develop/blob/16baa3877991d521cb69df712f1e1be9f61791bb/src/wp-
admin/includes/class-wp-upgrader.php#L604-L607 cleaned up after
installation]. And it looks like `clear_working` is generally set to true:
- WP_Upgrader::run() is the only method in core that calls
WP_Upgrader::install_package(), and WP_Upgrader also takes a
`clear_working` argument that defaults to true.
- Plugin_Upgrader calls WP_Upgrader::run() three times and each call
passes `"clear_working" => true`. (refs: [https://github.com/WordPress
/wordpress-develop/blob/143df6e76363d59f9bbad1d33747a0ff8d05299e/src/wp-
admin/includes/class-plugin-upgrader.php#L135 1],
[https://github.com/WordPress/wordpress-
develop/blob/143df6e76363d59f9bbad1d33747a0ff8d05299e/src/wp-
admin/includes/class-plugin-upgrader.php#L222 2],
[https://github.com/WordPress/wordpress-
develop/blob/143df6e76363d59f9bbad1d33747a0ff8d05299e/src/wp-
admin/includes/class-plugin-upgrader.php#L337 3])
- Theme_Upgrader calls WP_Upgrader::run() four times and each call passes
`"clear_working" => true`. (refs: [https://github.com/WordPress/wordpress-
develop/blob/143df6e76363d59f9bbad1d33747a0ff8d05299e/src/wp-
admin/includes/class-theme-upgrader.php#L173 1],
[https://github.com/WordPress/wordpress-
develop/blob/143df6e76363d59f9bbad1d33747a0ff8d05299e/src/wp-
admin/includes/class-theme-upgrader.php#L248 2],
[https://github.com/WordPress/wordpress-
develop/blob/143df6e76363d59f9bbad1d33747a0ff8d05299e/src/wp-
admin/includes/class-theme-upgrader.php#L324 3],
[https://github.com/WordPress/wordpress-
develop/blob/143df6e76363d59f9bbad1d33747a0ff8d05299e/src/wp-
admin/includes/class-theme-upgrader.php#L324 4])
- Language_Pack_Upgrader calls WP_Upgrader::run() once and passes
`"clear_working" => true`. (ref: [https://github.com/WordPress/wordpress-
develop/blob/143df6e76363d59f9bbad1d33747a0ff8d05299e/src/wp-
admin/includes/class-language-pack-upgrader.php#L243-L256 1])
I believe this shows that [https://github.com/WordPress/wordpress-
develop/blob/trunk/src/wp-admin/includes/class-wp-upgrader.php#L312-L318
the cleanup code in question here] is a second line of defense, where
WordPress takes the opportunity to clean up working files that should have
been cleaned up earlier.
If that is true, I think it is probably reasonable for this second line of
defense to only clean up working files that are past a certain age. It
honestly seems like the safer thing to do since __this code naturally does
not know why the working files are there to begin with, and that lack of
knowledge is the source of this bug__.
Does this make sense, and if so, does it influence your thinking at all on
[https://core.trac.wordpress.org/attachment/ticket/53705/avoid-corrupting-
concurrent-plugin-upgrades.diff the only-delete-older-working-files
patch]?
In case it helps, I think the patch could be adjusted to clean up files
that are older than an hour or even a number of minutes. In retrospect,
requiring files to be over a day old seems excessive.
>
> If the file names are predictable then a more targeted delete while
preparing for the upgrade could be a better solution.
Since this cleanup code assumes all pre-existing working files are left
over and need to be cleaned up, I'm not sure how better naming would
prevent it from removing things that are in the process of being
installed. Would you be up for explaining further?
--
Ticket URL: <https://core.trac.wordpress.org/ticket/53705#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list