Opened 13 years ago
Closed 4 years ago
#20944 closed defect (bug) (wontfix)
Changing plugin filename causes Fatal error on automatic activation after update
Reported by: | adiant | Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.3 |
Component: | Upgrade/Install | Keywords: | has-patch |
Focuses: | multisite | Cc: |
Description
In a new version of a (my) plugin in the WordPress repository, I changed the filename of the main plugin file (to match the folder name). When an old version of the plugin is activated, doing an automatic update to the latest version of the plugin (with the new filename), the following error message is displayed: "The plugin jonradio-display-kitchen-sink/jonradio-kitchen-sink.php has been deactivated due to an error: Plugin file does not exist."
An immediate manual Activation completes successfully.
Observed on sites with WordPress Network turned off and on, including when the plugin was Network Activated.
Plugin is jonradio Display Kitchen Sink, and update was from Version 1.0 to 1.1.
Attachments (1)
Change History (21)
#3
@
12 years ago
FWIW, This is supposed to be handled, and work correctly.
The following cases should work:
before update -> after update test.php -> test-plugin/test-plugin.php test-plugin/one-name.php -> test-plugin/second-name.php
I just tested it for akismet/akismet-test.php -> akismet/akismet.php
and it worked for me, I just renamed the plugin file locally, and edited the version to force a update, Activated plugin, Upgraded plugin, Works like a charm. Can you see anything that you did that I did differently?
#4
@
12 years ago
Also just tested upgrading jonradio-display-kitchen-sink from v1.0 to 1.1 and didn't encounter any fatal errors, I get a reactivated successfully message (And it's still active)
#7
@
12 years ago
- Keywords reporter-feedback removed
- Version changed from 3.3 to 3.4.1
This is the first time I've tested this problem with Version 3.4.1. The two times that fatal errors occurred previously were with a 3.4 Release Candidate and 3.4 itself, though under different circumstances.
I just completed testing all of the possibilities I could think of, and now only find one failure: a version update in a network where the plugin is updated (of course) from the network admin panel and has been previously activated on only one of the networked sites, i.e. - has NOT been Network Activated.
The error occurs when you display the Admin Plugins panel for the site where the previous version of the plugin was activated: "The plugin jonradio-display-kitchen-sink/jonradio-kitchen-sink.php has been deactivated due to an error: Plugin file does not exist."
As I say, I am no longer able to re-create this problem on a non-network install of WordPress.
This problem appears repeatable, as I have had it occur twice in a row. I'm not sure if it matters, but I only tested this on the second site I added to the network, not the "original" site created automatically.
#8
follow-up:
↓ 10
@
12 years ago
- Keywords has-patch added
- Version changed from 3.4.1 to 3.3
Version number indicates when the bug was initially introduced/reported.
20944.patch is an attempt to check if the plugin file name was changed and reactivate it on the fly when visiting the Plugins screen (in a similar way to how the plugin upgrader handles that).
#9
@
12 years ago
The steps I've tested the patch with:
- Activate Debug Bar.
- Rename
debug-bar/debug-bar.php
todebug-bar/debug-bar-2.php
. - Refresh the Plugins screen. Debug Bar should stay activated.
#10
in reply to:
↑ 8
;
follow-up:
↓ 12
@
12 years ago
Replying to SergeyBiryukov:
20944.patch is an attempt to check if the plugin file name was changed and reactivate it on the fly when visiting the Plugins screen...
Not sure whether we should be reactivating renamed plugins automatically. Renaming a plugin from FTP is a good way to (temporarily) disable it if the user suspects any problems. Renaming it back activates the plugin again. That's also the only way to disable a plugin that throws a fatal error.
#11
@
12 years ago
I agree with azaozz.
The correct way to fix this would be to go through each blog in the network and update it's 'active_plugins' option right after a plugin update.
#12
in reply to:
↑ 10
@
12 years ago
Replying to azaozz:
Renaming a plugin from FTP is a good way to (temporarily) disable it if the user suspects any problems.
Yes, that's why the patch only handles the file name change inside a plugin directory. If the directory is renamed, the plugin would be deactivated. I agree that it might still be questionable though.
Replying to scribu:
The correct way to fix this would be to go through each blog in the network and update it's 'active_plugins' option right after a plugin update.
Thanks, I'll look into that.
This ticket was mentioned in Slack in #meta by sergey. View the logs.
8 years ago
This ticket was mentioned in Slack in #core-auto-updates by pbiron. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-auto-updates by afragen. View the logs.
4 years ago
This ticket was mentioned in Slack in #core-auto-updates by francina. View the logs.
4 years ago
#20
@
4 years ago
- Milestone Awaiting Review deleted
- Resolution set to wontfix
- Status changed from new to closed
After reviewing the ticket in the month of May 2021, the people working on this component decided to close it.
Unfortunately, after evaluation and discussion, the component maintainers don't see an elegant way to automate this action at this time. The solution is to re-activate the plugin from the CLI or via FTP.
Thank you everyone for the discussion over the years.
Yeah, I could see how this would occur, for sure. Probably best to not rename it again. :-)
There is probably something we can do here in case we detect that the file is gone, to see if has been renamed.