[20525] breaks commonly used plugin technique for network activation

[iandunn]

[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.

[SergeyBiryukov]

​https://www.google.com/search?q=site%3Aplugins.svn.wordpress.org+%22networkwide%22

[scribu]

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.

[scribu]

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
  }
}

[iandunn]

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.

[scribu]

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 $_GET['networkwide'].

[scribu]

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

​http://wpdevel.wordpress.com/2010/10/27/plugin-activation-hooks/

[WPReady]

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.

[nacin]

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?

[WPReady]

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

[nacin]

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

[nacin]

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.

[nacin]

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.