Project

General

Profile

Bug #6755

Cannot Deactivate Plugin

Added by Laura Kane over 5 years ago. Updated over 5 years ago.

Status:
New
Priority name:
Normal
Assignee:
-
Category name:
WordPress (misc)
Target version:
Future release
Start date:
2016-11-15
Due date:
% Done:

0%

Estimated time:

Description

Hi Commons Team,

I've tried several times to remove the "Sociable" plugin from the JITP Staging Site (http://jitpstaging.commons.gc.cuny.edu) but the plugin will not deactivate. After clicking the deactivate button, the browser refreshes but the plugin is still listed as active. This happens in Fire Fox and Chrome.

History

#1 Updated by Boone Gorges over 5 years ago

  • Category name set to WordPress (misc)
  • Target version set to Future release

Hi Laura - There is an occasional bug on the Commons that causes plugin deactivation to result in a cache lag. I've just spent a few minutes trying to track it down, but I didn't have any luck. I'm going to leave this ticket open for future analysis. In the meantime, I've manually cleared your cache, so you should be OK.

Dev team - I have a hunch that there's a race condition between the cache calls in update_option() and some other piece of code on our site that fetches the active_plugins option. It could have to do with latency while contacting Memcached, perhaps exacerbated by the size of the 'alloptions' and 'active_plugins' keys. We should try to duplicate on cdev. Then, on a lark, we might try switching autoload to 'no' for 'active_plugins' - keeping it out of the 'alloptions' kerfuffle might be enough to solve the problem.

#2 Updated by Laura Kane over 5 years ago

Thank you, Boone!

Boone Gorges wrote:

Hi Laura - There is an occasional bug on the Commons that causes plugin deactivation to result in a cache lag. I've just spent a few minutes trying to track it down, but I didn't have any luck. I'm going to leave this ticket open for future analysis. In the meantime, I've manually cleared your cache, so you should be OK.

Dev team - I have a hunch that there's a race condition between the cache calls in update_option() and some other piece of code on our site that fetches the active_plugins option. It could have to do with latency while contacting Memcached, perhaps exacerbated by the size of the 'alloptions' and 'active_plugins' keys. We should try to duplicate on cdev. Then, on a lark, we might try switching autoload to 'no' for 'active_plugins' - keeping it out of the 'alloptions' kerfuffle might be enough to solve the problem.

Also available in: Atom PDF