Make WordPress Core

Opened 20 months ago

Last modified 8 months ago

#50349 new defect (bug)

Plugin Update deletes plugin and showing "could not delete old plugin" message.

Reported by: apedog Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version:
Component: Plugins Keywords:
Focuses: Cc:


I just came across this on my local machine (Windows).

I had a plugin directory open in vscode editor. I had also previously edited one of the files in that plugin (added error_logs in one of the functions for testing). I may or may not have had same file open with further unsaved changes (I don't know at this point).

In the Plugins page I clicked the "update now" in the plugin row (directory was still open in vscode).
The update resolved with a "Could not delete old plugin" error notice. However the plugin was removed and directory is left empty.

Change History (6)

#1 @SergeyBiryukov
20 months ago

I also had this happen a few times when attempting to update a plugin while one of its files was opened in an editor.

I believe this is working as intended though, since the OS doesn't allow for removing a directory with a locked file. What would be a suggested fix here?

#2 @apedog
20 months ago

I'd like to start off by saying that this is not a major issue for me. I ran across this edge-case and figured I'd post a bug report - for the record. This did not impede my work in any meaningful way. Maybe it's an unimportant edge-case, maybe it touches upon a deeper implementation problem - I honestly don't know.

Nonetheless, if this issue is to be addressed:

  1. At the very least the message "Could not delete old plugin" is wrong. The old plugin was deleted. Empty plugin directory was all that remained.
  1. As for "expected" behaviour - my expectation would be that if the update failed, I'd still have the old version in place, and not have the plugin vanish unceremoniously. Or at least some indication that a plugin was removed due to an error (and what the plugin's basename was - allowing the user to troubleshoot). As it stands upon Plugins page refresh - everything appears normal sans the deleted plugin.

I've no idea as to the amount of work that would go into fixing this. Just laying it out.

#3 follow-up: @pbiron
9 months ago

I've also experienced this a number of times on my local dev machine. Also happens (at least in Windows), if you've got a shell open in the plugin directory (or one of it's sub-directories). In fact, probably 95% (or more) of update failures I've experienced over the years on my local were the result of this.

The only way I can think to prevent it would be to check whether any of the files in the directory were opened before starting to try to delete them. However, I don't think there's a reliable way in PHP to check this (that works across OS's and web server configurations).

@apedog Do you remember what version of PHP you were running when this happened to you? I mention that because I just noticed that the PHP manual for unlink() now says that as of PHP 7.3.0:

On Windows, it is now possible to unlink() files with handles in use, while formerly that would fail. However, it is still not possible to re-create the unlinked file, until all handles to it have been closed.

#4 in reply to: ↑ 3 @apedog
9 months ago

Replying to pbiron:

Do you remember what version of PHP you were running when this happened to you?

Nope. Sorry.
I see that I've installed PHP 7.4 almost exactly 12 months ago. And this ticket is from 11 months ago.
But it did take me a while before I fully migrated my environment from 7.2
So this is exactly from that time :(

This ticket was mentioned in Slack in #core-auto-updates by francina. View the logs.

8 months ago

#6 @justinahinon
8 months ago

I assume this mostly arrives in Windows environment?

I've tried to reproduce the issue on this setup:

macOS Big Sur 11.1
WordPress 5.7.2
Theme: TT1
PHP 8.0.0

I've made many tests with only the plugin "Custom Post Type UI"

I've uploaded the version 1.9.0 and updated to the latest 1.9.1 in these scenarios:

  • A plugin file opened
  • A plugin file opened, edited, and saved
  • A plugin file opened, edited, and not saved
  • A terminal opened in the plugin plugin directory

I all these cases, the update works correctly.

Note: See TracTickets for help on using tickets.