Make WordPress Core

Opened 14 years ago

Closed 13 years ago

#14718 closed defect (bug) (fixed)

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

Reported by: sbrajesh's profile sbrajesh Owned by: nacin's profile nacin
Milestone: 3.1 Priority: normal
Severity: blocker Version: 3.0.1
Component: Multisite Keywords: has-patch
Focuses: Cc:

Description

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.

Attachments (3)

14718.diff (399 bytes) - added by anthonycole 13 years ago.
14718.2.diff (2.9 KB) - added by nacin 13 years ago.
14718.3.diff (3.1 KB) - added by nacin 13 years ago.
Alternative patch that moves some work into ms-load.php

Download all attachments as: .zip

Change History (17)

#1 @sbrajesh
14 years ago

  • Cc sbrajesh added

#2 @scribu
14 years ago

  • Component changed from Plugins to Multisite

#3 @nacin
14 years ago

  • Cc wpmuguru added
  • Milestone changed from Awaiting Review to 3.1
  • Owner set to nacin
  • Status changed from new to accepted
  • Summary changed from Plugins Not loaded on wp-activate.php in multisite mode to Network plugins not loaded on wp-activate.php in multisite mode

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.

#4 @nacin
14 years ago

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

#5 @sbrajesh
14 years ago

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.

@anthonycole
13 years ago

#6 @anthonycole
13 years ago

  • Keywords has-patch added

@nacin
13 years ago

#7 follow-up: @nacin
13 years ago

  • Milestone changed from 3.1 to 3.0.2

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
13 years ago

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

#8 in reply to: ↑ 7 ; follow-up: @scribu
13 years ago

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?

#9 in reply to: ↑ 8 @nacin
13 years ago

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.

#10 @nacin
13 years ago

  • Severity changed from major to blocker

Tempted to close #12022 as a duplicate.

Bumping severity so we patch this.

#11 @ryan
13 years ago

  • Milestone changed from 3.0.2 to 3.1

#12 @ryan
13 years ago

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

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

#13 @plastia
13 years ago

  • Keywords needs-refresh added
  • Resolution fixed deleted
  • Status changed from closed to reopened
  • Version changed from 3.0.1 to 3.2.1

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.

#14 @SergeyBiryukov
13 years ago

  • Keywords needs-refresh removed
  • Resolution set to fixed
  • Status changed from reopened to closed
  • Version changed from 3.2.1 to 3.0.1

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.

Note: See TracTickets for help on using tickets.