Make WordPress Core

Opened 12 years ago

Closed 3 years ago

#20944 closed defect (bug) (wontfix)

Changing plugin filename causes Fatal error on automatic activation after update

Reported by: adiant's profile 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)

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

Download all attachments as: .zip

Change History (21)

#1 @nacin
12 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
12 years ago

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

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

#5 @SergeyBiryukov
12 years ago

  • Keywords reporter-feedback added

#6 @SergeyBiryukov
12 years ago

Could not reproduce either.

#7 @adiant
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: @SergeyBiryukov
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 @SergeyBiryukov
12 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
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 @scribu
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 @SergeyBiryukov
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.

#13 @dd32
11 years ago

  • Component changed from Plugins to Upgrade/Install

#14 @chriscct7
9 years ago

  • Keywords dev-feedback added

#15 @dd32
7 years ago

  • Focuses multisite added
  • Keywords dev-feedback removed

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


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


3 years ago

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


3 years ago

#20 @francina
3 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.

Note: See TracTickets for help on using tickets.