A Quick Heads Up About a WordPress 3 Bug

Update 25th Aug. 2011: the bug discussed here is still present. I recommend all WordPress Multi Site users install the Proper Network Activation plugin that is available here at the WordPress site.

I noticed a compatibility bug between WordPress 3 Multi Site and Greg’s High Performance SEO so reported the issue to Greg who very quickly took a look at it. It turns out that WordPress Multi Site does not like it when plugins are Network Activated. So, as a warning to all WordPress Multi Site users, do not Network Activate plugins. Not yet, anyway.

To paraphrase Greg’s explanation:

When a plugin is Network Activated, WordPress 3.0 ignores the activation hook that plugins register to run whenever they are first activated. Consequently a plugin’s default options do not get set-up on subdomains when a plugin is Network Activated. It also appears, according  Greg, that WordPress does not fully remove plugins that fail to setup across subdomains when Network Activation fails – the database does not get properly cleansed.

I recommend WP 3 MS users do not Network Activate plugins until the WordPress developers fix their oversight.

In the meantime, if, like me, you need to remove a Network Activated plugin that only half installed then you must delve into your WordPress database and remove its settings manually before you re-install it. Affected plugins must then be reactivated on a per site basis. For Greg’s High Performance SEO, this means you must drop the single “ghpseo_settings” entry in “wp_n_options”, where ‘n’ represents the site’s number (it will be repeated in your database almost as many times as you have sites).

In case you’re wondering, the bug with Greg’s High Performance SEO plugin was that its options could not be enabled within subdomain sites – the options screen displayed but no options could be set.

Greg has issued an update to his plugin (version 1.4.3) which addresses the installation issue but if you’ve Network Activated it prior to this update then you will need to get your hands dirty with your sites’ database. I need to stress here that the fault is with WordPress Multi Site not Greg’s plugin.

This WordPress Multi Site Network Activation bug will affect the functioning and installation of thousands of plugins. Please be careful when you activate them.

Special thanks to Greg for amending his plugin so that it works around this bug and for highlighting this surprising WordPress 3 Multi Site issue. Cheers Greg, I still highly recommend your plugin.

14
Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

  Subscribe  
newest oldest most voted
Notify of
Lloyd Pearson

I find the claim to be false. I have plenty of network activated plugins installed on my multi network multi site setup on my site with no problems.

RavanH

In fact, it can not be called a “bug” as much as a design decision. It has been like that in WPMU before it merged with regular WP into WP3.0 MS. The thing is that activation (normal or network wide) actually DOES call the register_activation hook but ONLY for the site the activation took place. So when doing a network wide activation from – say – the main site, will not do the register_activation routine for all the other sites on the network. Neither will the register_activation hook be called when a new site is created AFTER a plugin has… Read more »

ericjt

Thanks for the warning, but you don’t give a date on when this was posted and I was wondering if this bug has been fixed yet.

Granville Raper

I am developing on the Beta Version of 3.2 right now.  Here it is June of 2011 and the beta version still exhibits the described behavior.  I looked at the code in the GHPSEO plugin you mentioned and he placed a check in a function called by the admin_init action, I put mine in a admin_menu function which I had.  If an option is not set, just call the activate function.  It adds some cycles but very minimal for a work around.  Now to figure out what action to use for a deactivate replacement.

Thank you very much for pointing this out. I’ve sent Greg an email to keep him updated. I have confidence that he will find a solution for the deactivation routine. Cheers :)

I received a reply from Greg. He said that as the bug has resurfaced in WordPress then it’s for the developer community to be more vocal with the WordPress development team to get them to fix the WordPress code to make it compatible with older plugins. I’m not a plugin developer but I tend to agree with Greg on that. I can’t speak for Greg because I don’t know him. We’ve only exchanged a couple of emails in relation to the original bug as mentioned in the above post. However, I suspect he won’t make any changes to his code… Read more »

Granville Raper

I am developing on the Beta Version of 3.2 right now.  Here it is June of 2011 and the beta version still exhibits the described behavior.  I looked at the code in the GHPSEO plugin you mentioned and he placed a check in a function called by the admin_init action, I put mine in a admin_menu function which I had.  If an option is not set, just call the activate function.  It adds some cycles but very minimal for a work around.  Now to figure out what action to use for a deactivate replacement.

Free to your inbox

Join our mailing list to receive the latest news and updates from JournalXtra.

You have Successfully Subscribed!