Project

General

Profile

Actions
Copy link

Bug #6755

open

Cannot Deactivate Plugin

Added by Laura Kane almost 6 years ago. Updated almost 6 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.

Actions
Copy link
 #1

Updated by Boone Gorges almost 6 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.

Actions
Copy link
 #2

Updated by Laura Kane almost 6 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.

Actions
Copy link

Also available in: Atom PDF