Network plugins not loaded on wp-activate.php in multisite mode

[sbrajesh]

In wordpress 3.0/3.0.1 when the site is installed as network mode, none of the sitewide active plugins are loaded on the user activation page.

A little test shows the problem is with the "wp_get_active_and_valid_plugins" function in the wp-includes/load.php

It returns empty array if WP_INSTALLING is defined which is the case with the wp-activate.php.

Changing line 470-471 from

if ( empty( $active_plugins ) || defined( 'WP_INSTALLING' ) )
		return $plugins;

to

if ( empty( $active_plugins )  )
		return $plugins;

solves it on the active installation.

The above behavior is in contradiction with the wpmu 2.9.2 behavior where sitewide active plugins were loaded on the activation page.

[nacin]

Looking into this.

In MU, we included sitewide plugins immediately after must-use plugins and even before the muplugins_loaded hook. That's definitely been changed in 3.0, as we grouped them with the loading of regular plugins. I imagine that is my fault.

By combining them with the regular plugins, they also inherited the !WP_INSTALLING check. It makes sense for that only to apply for site plugins.

[nacin]

Looks like it was a regression I introduced in [12930].

[sbrajesh]

Thank you nacin for the quick look through the issue.
Yes, that seems to be a result of [12930]

btw, as you already mentioned, It is also worth to note here, in wpmu, the sitewide plugins were loaded before the regular plugins.

In current wp 3.0 trunk, the loading of network active plugins,regular plugins have no defined order and it does not guarantee that the network active plugins will be loaded before regular plugins. It may lead to conflicts in a few cases.

It may be a better idea to separate the network active plugins from the regular plugins in order to maintain the consistency with wpmu.

[nacin]

Attached patch fixes the regression and splits the inclusion of network plugins from regular plugins.

This means that network plugins are loaded first, are loaded immediately after must-use plugins, and are loaded even when we're not running on a specific blog (i.e. wp-activate.php).

[nacin]

Alternative patch that moves some work into ms-load.php

[scribu]

Replying to nacin:

This means that network plugins are loaded first, are loaded immediately after must-use plugins, and are loaded even when we're not running on a specific blog (i.e. wp-activate.php).

So this covers the new network admin too, right?

[nacin]

Replying to scribu:

So this covers the new network admin too, right?

Good question. The network admin does have the awareness that it is an individual site, specifically the main site for a network. (So blog-level plugins get loaded.) Previously, that was inconsistent as it depended on where the network admin screens was accessed from.

[nacin]

Tempted to close #12022 as a duplicate.

Bumping severity so we patch this.

[ryan]

(In [16558]) Load network plugins for wp-activate.php. Restore MU load order. Props blamenacin. fixes #14718

[plastia]

I noticed that changes made on diff.1 are not the same in diff.3

if ( empty( $active_plugins ) || defined( 'WP_INSTALLING' ) )
		return $plugins;

is still on the code on diff 3 in wp-includes/load.php, and it's causing the error appearing again.

Removing it resolves the issue, and we need to apply it to the actual revision for next upgrades to take effect. So it should be

if ( empty( $active_plugins )  )
		return $plugins;

instead.

[SergeyBiryukov]

Since [16558], network activated plugins are loaded earlier in wp-settings.php:
​http://core.trac.wordpress.org/browser/tags/3.2.1/wp-settings.php#L160

So that line in wp-includes/load.php shouldn't have any difference.

This ticket is fixed as of 3.1 milestone. I've just tested the issue in 3.2.1 and could not reproduce it.

Please open a new ticket with more information if there's still a problem.