Make WordPress Core

Opened 3 years ago

Closed 3 years ago

#20995 closed defect (bug) (fixed)

[20525] breaks commonly used plugin technique for network activation

Reported by: iandunn Owned by: nacin
Milestone: 3.4.1 Priority: normal
Severity: normal Version: 3.4
Component: Multisite Keywords: has-patch commit
Focuses: Cc:


[20525] removed $_GET[ 'networkwide' ] during activation/de-activation, which is commonly used by plugins to hook into the process as described in a popular post by Shiba. This was discovered and documented by WPGetReady.

Instead of being immediately removed without warning, I think it should have followed the standard deprecation process so that developers can have time to update their plugins. $_GET[ 'networkwide' ] should be re-introduced in 3.4.1 in a deprecated fashion, and then completely removed in the future.

Change History (15)

comment:1 @iandunn3 years ago

  • Cc ian_dunn@… added

comment:3 @scribu3 years ago

  • Keywords close added

Actually, since [16011], activation hooks receive an explicit parameter that indicates if it's a network activation or not.

Note that that flag has been in WordPress since version 3.1.

comment:4 @scribu3 years ago

Example usage:

register_activation_hook( __FILE__, 'my_plugin_activation' );

function my_plugin_activation( $network_wide ) {

  if ( $network_wide ) {
    // it's a network activation
  } else {
    // it's a normal activation
Last edited 3 years ago by scribu (previous) (diff)

comment:5 @iandunn3 years ago

  • Keywords 2nd-opinion added

Thanks for pointing that out scribu, that looks like the best way to detect it going forward.

Where is that documented, though? How were plugin authors supposed to know about it? It isn't mentioned on the codex or the 3.4 field guide. I still think $_GET[ 'networkwide' ] should be reintroduced in 3.4.1 until plugin authors can be properly notified of the change and given time to update their code.

comment:6 @scribu3 years ago

I guess it was not documented because there's still debate about how to handle network activation.

And, as is always the case when there's no clear way to do something, plugin authors have found workarounds, such as checking $_GETnetworkwide?.

Version 0, edited 3 years ago by scribu (next)

comment:7 @scribu3 years ago

But, to answer your question about "how were plugin authors supposed to know", there was a notice (and a big discussion afterwards):


comment:8 @WPReady3 years ago

We want to point out some observations about this discussion:

Reading http://wpdevel.wordpress.com/2010/10/27/plugin-activation-hooks-no-longer-fire-for-updates/ we interpreted no hook is reliable to detect updates.

We almost thought that activation hook was an ideal place to detect updates. We were wrong.

So, we followed the recommendation about the right way to do it. The current strategy rests over another hook(plugins_loaded) which supposedly it fires when the plugins are loaded, and also an option value to check if there were changes. This concept worked fine.

From the moment we knew updates couldn't trigger activation we also assumed there is no deactivation trigger . It is like the plugin passed through the updating process
without triggering hooks.

Trying to reuse the actual solution, we ended up parsing the url referrer to decide what to do. In this scenario $network_wide variable isn't useful, because we discarded the hooks.

What it would be the current recommendation? Thanks.

comment:9 @nacin3 years ago

We probably should have kept $_GET['networkwide'] around in case plugins were using it.

For an activation, you can use the $network_wide argument that is passed to the activation hook. This replaces checking 'networkwide'.

For upgrades, I don't understand how networkwide would have ever helped you. Can you explain some more?

comment:10 @WPReady3 years ago

We are not using that variable for any task related with upgrades.

comment:11 @nacin3 years ago

We probably can do $_GET['networkwide'] = 1; in activate_plugins().

comment:12 @nacin3 years ago

  • Owner set to nacin
  • Status changed from new to assigned

comment:13 @nacin3 years ago

In [21104]:

Back compat for plugins looking for networkwide=1 during a plugin activation hook.

Proper way to detect this: An activation hook callback receives (bool) $network_wide as the first argument.

see #20995 for trunk.

comment:14 @nacin3 years ago

  • Keywords has-patch commit added; close 2nd-opinion removed

comment:15 @nacin3 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In [21130]:

Back compat for plugins looking for networkwide=1 during a plugin activation hook.

Proper way to detect this: An activation hook callback receives (bool) $network_wide as the first argument.

fixes #20995 for 3.4.

Note: See TracTickets for help on using tickets.