Changing plugin filename causes Fatal error on automatic activation after update

[adiant]

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.

[nacin]

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.

[scribu]

I'm pretty sure this was an issue even before 3.3.

[dd32]

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?

[dd32]

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)

[SergeyBiryukov]

Could not reproduce either.

[adiant]

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.

[SergeyBiryukov]

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).

[SergeyBiryukov]

The steps I've tested the patch with:

1. Activate Debug Bar.
2. Rename debug-bar/debug-bar.php to debug-bar/debug-bar-2.php.
3. Refresh the Plugins screen. Debug Bar should stay activated.

[azaozz]

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.

[scribu]

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.

[SergeyBiryukov]

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.

[francina]

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.