WordPress.org

Make WordPress Core

Opened 7 years ago

Last modified 2 years ago

#20944 new defect (bug)

Changing plugin filename causes Fatal error on automatic activation after update

Reported by: adiant Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.3
Component: Upgrade/Install Keywords: has-patch
Focuses: multisite Cc:
PR Number:

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)

20944.patch (1.7 KB) - added by SergeyBiryukov 7 years ago.

Download all attachments as: .zip

Change History (17)

#1 @nacin
7 years ago

  • Version changed from 3.4 to 3.3

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.

#2 @scribu
7 years ago

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

#3 @dd32
7 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 @dd32
7 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)

#5 @SergeyBiryukov
7 years ago

  • Keywords reporter-feedback added

#6 @SergeyBiryukov
7 years ago

Could not reproduce either.

#7 @adiant
7 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: @SergeyBiryukov
7 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 @SergeyBiryukov
7 years ago

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.

#10 in reply to: ↑ 8 ; follow-up: @azaozz
7 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 @scribu
7 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 @SergeyBiryukov
7 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.

#13 @dd32
6 years ago

  • Component changed from Plugins to Upgrade/Install

#14 @chriscct7
4 years ago

  • Keywords dev-feedback added

#15 @dd32
3 years ago

  • Focuses multisite added
  • Keywords dev-feedback removed

This ticket was mentioned in Slack in #meta by sergey. View the logs.


2 years ago

Note: See TracTickets for help on using tickets.