Make WordPress Core

Opened 14 years ago

Closed 14 years ago

#11138 closed defect (bug) (worksforme)

WordPress deactivates plugin after upgrade

Reported by: sirzooro's profile sirzooro Owned by: westi's profile westi
Milestone: Priority: normal
Severity: normal Version: 2.8.5
Component: Plugins Keywords: needs-patch
Focuses: Cc:

Description

I have group of sites which reuse the same installation of WP - in wp-config.php I set DB prefix depending on value of $_SERVER['HTTP_HOST'].

When some plugin has update available, I update do update on one of sites. When I do this and go to other site, WP shows that the same update is available (this is OK for me). I usually open plugin list to dismiss it. Usually this works, but sometimes WP deactivates upgraded plugin and displays error 'The plugin <name> has been deactivated due to an error: Plugin file does not exist.'.

I am sure that file exists, because last time this happened for my plugin.

Change History (8)

#1 @markjaquith
14 years ago

  • Milestone changed from 2.9 to Unassigned

Going to need more info. Who is available to investigate this?

#2 @sirzooro
14 years ago

  • Keywords multisite added
  • Milestone changed from Unassigned to 3.0

Multisite installs using WPMU/WP3.0+ may be affected by this too.

#3 @sirzooro
14 years ago

BTW, I think possible scenario may be:

  • user starts plugin upgrade on site A - plugin is deactivated and its files are deleted;
  • after this someone else loads page on site B and WP cannot load plugin;
  • new plugin version is unpacked and activated

I suspect that something wrong happens in 2nd step, but I have not investigated this.

#4 @dd32
14 years ago

There are some possible reasons why:

  1. Networked filesystem hasnt updated the changes to the node that the WordPress install is hosted on
  2. Directory that the plugin or plugin filename has changed
  3. That the SiteB's plugins.php page was loaded while the plugin didnt exist on the filesystem

No matter what, you're likely to end up with bad race conditions when upgrading plugins if they're used by multiple installs.

An option that was put forward for upgrading plugins in bulk, was to simply put the site in maintainence mode, if you've sharing WP_CONTENT_DIR instead of the plugins dir, then that would put all sites into maintainence mode i believe.. which could be an option instead.

#5 follow-up: @dd32
14 years ago

MultiSite probably wouldnt be affected the same way, As its the same wordpress install.

You'd need to be a site admin, and viewing the plugins page, and fetch the active plugins list as the other process was about to update it (Plugins are deactivated before singular upgrade) and then load the rest of the page after the other process deleted the files.

#6 in reply to: ↑ 5 @wpmuguru
14 years ago

Replying to dd32:

MultiSite probably wouldnt be affected the same way, As its the same wordpress install.

You'd need to be a site admin, and viewing the plugins page, and fetch the active plugins list as the other process was about to update it (Plugins are deactivated before singular upgrade) and then load the rest of the page after the other process deleted the files.

In the current multisite terminology, dd32 is correct. This won't be a problem. Like the themes and plugins, the plugin/theme update data is shared/common across the network.

In multisite in the old MU sense (what would be called multi networks under new terminology), this did occur as well. I believe the reason is that if the update check has not expired on the second network, the plugin page just puts out the info from the last update check. This may have been fixed in the 2.9 release.

#7 @wpmuguru
14 years ago

  • Keywords multisite removed

I tested multiple WP networks, the info on the updated plugin is updated on the first refresh of the page in each of multiple networks.

Taking the multisite keyword off, unless some encounters an issue and can outline.

#8 @dd32
14 years ago

  • Milestone 3.0 deleted
  • Resolution set to worksforme
  • Status changed from new to closed

Not sure this actually possible anymore, if the plugin version changes then the update check cache is cleared and requested again.

Re-open if you're still encountering the same problem.

Note: See TracTickets for help on using tickets.