Active plugins filtering for site wide plugin support

[apeatling]

This ticket contains the core changes needed for more robust support for site wide level plugin activation in WordPress MU.

The ticket this relates to is here:
​http://trac.mu.wordpress.org/ticket/1101

By filtering the active_plugins array, we can inject site wide activated plugins into all blogs at include time. This will also allow for site wide plugins to correctly run though activate_ and deactivate_ hooks. This is important to allow the plugin manager to correctly handle site wide plugins on first install or upgrade.

There needs to be a change to the deactivate_plugins() function to accommodate for the fact that site wide plugins will not exist in the $current plugins array.

array_search() will return a value that is interpreted by array_splice() as 0 (zero) when a plugin is not found. This will then perform an incorrect splice on the $current array and cause many problems. By performing an identical check on the array_search() result we can ensure that this doesn't happen.

Patch attached for review and testing.

[markjaquith]

(In [11966]) Active plugin filter, plugin deactivation array_splice() protection. props apeatling. fixes #10839

[dd32]

Is there a reason why this couldnt be applied via the option_active_plugins filter? (Say as a helper function, or in the option sanitization filter list?)

As it is, All items which use the active_plugins list will now have to filter it as well to ensure the correct list..

This changeset also means that a plugin wouldn't show as active on the plugin management screen if it was added via the filter..

[apeatling]

Using the option_active_plugins filter would cause site wide plugins to merge with local blog plugins on activation and deactivation.

See this comment: ​http://trac.mu.wordpress.org/ticket/1101#comment:4

The filter is not intended to be used by anything other than the site wide management code in MU, which will handle the display of plugins on the management screen injected via the filter.

[hakre]

get_option already is filterable. I created a worm that uses that and which is still working as shiny well as on it's first day. I see no problem why wordpress mu plugins (global, hidden, injected, payload or however you like to call such plugins) shouldn't do the same. There is no need to actually change code for such a functionality. This is pretty much tested over various version steps.

If this is done per every request (even such plugins not activated) it is a pretty much overhead for such a simple thing to do.