WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 13 months ago

#23197 reopened defect (bug)

wp-activate.php, without explanation, does not load site plugins

Reported by: radiok Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version: 3.0
Component: Login and Registration Keywords: has-patch needs-testing
Focuses: multisite Cc:

Description

I am the developer of a Wordpress plugin that modifies the Registration process. I am porting my code to Wordpress Multisite and am running into an odd obstacle. During the signup process, I store meta data in the signups table. I intend to restore that data after the user has activated their account using hooks located in wp-activate.php. I learned the hard way that wp-activate is altering the load sequence with the following flag.

define( 'WP_INSTALLING', true );

The preceding comment says "Define ABSPATH as this file's directory", which to me does not entirely jive up. Regardless, with this flag in place, when Wordpress would normally determine what plugins to load in wp_get_active_and_valid_plugins, instead it returns an empty array. I do not believe this is the desired behavior.

My solution has to been to create a small "must-use" plugin simply for my activation related code. This however, is not a desirable solution since must-use plugins must be manually installed. I cannot determine much of an alternate solution; I cannot modify that flag in a plugin at any level since my plugin would never be loaded for it to get a chance to modify the flag. It is a bit of a chicken and the egg problem.

Attachments (1)

23197.diff (591 bytes) - added by johnbillion 18 months ago.

Download all attachments as: .zip

Change History (15)

comment:1 @radiok2 years ago

  • Severity changed from normal to trivial

OK, I figured out how to load my plugin, it must be Network Activated, however, I still think the comment and the code on wp-activate.php aren't completely in sync. A silly, trivial bug, but not without merit, and very little impact to resolve. That is, for someone who truly understands why the WP_INSTALLING flag is being thrown.

comment:2 @radiok2 years ago

  • Summary changed from wp-activate does not load plugins to wp-activate, without explanation, does not load site plugins

comment:3 @johnbillion2 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to duplicate
  • Status changed from new to closed

Yep, this is frustrating. See #18278 and #17948.

comment:4 @SergeyBiryukov2 years ago

The preceding comment says "Define ABSPATH as this file's directory", which to me does not entirely jive up.

Created #23211 to remove the comment.

comment:5 @johnbillion18 months ago

  • Resolution duplicate deleted
  • Status changed from closed to reopened

I'm going to reopen this for reconsideration separate from #17948. This is a silly bug for silly people and I think it needs to be fixed regardless of what's happening (or not happening) on #17948.

comment:6 @johnbillion18 months ago

  • Keywords needs-patch added

@johnbillion18 months ago

comment:7 follow-up: @johnbillion18 months ago

  • Keywords has-patch dev-feedback added; needs-patch removed
  • Milestone set to Awaiting Review
  • Severity changed from trivial to normal
  • Version set to 3.0

23197.diff removes the definition of WP_INSTALLING from wp-activate.php so plugins are now loaded on this URL.

The addition of the wp_no_robots action on the wp_head hook and the $wp_query->is_404 are both copied from wp-signup.php.

I think this should go in as a stop-gap solution until #17948 is ready for inclusion (which may be a fair way off yet). It's ridiculous that we have this one URL that does not load plugins.

Any opponents?

comment:8 @SergeyBiryukov18 months ago

  • Milestone changed from Awaiting Review to 3.7

Moving for review along with #24960.

comment:9 @johnbillion17 months ago

  • Keywords dev-feedback removed
  • Milestone changed from 3.7 to 3.8

Punting to 3.8 so we can get it in early in a cycle.

comment:10 in reply to: ↑ 7 @nacin17 months ago

Replying to johnbillion:

23197.diff removes the definition of WP_INSTALLING from wp-activate.php so plugins are now loaded on this URL.

This is surely here for other reasons. No idea what, as blaming this will take you to http://mu.trac.wordpress.org/changeset/543. WP_INSTALLING does quite a bit of weird stuff throughout core. If I had to guess, it was/is there for multisite installation purposes. I have no idea if it is still necessary now, but this needs a lot of testing to be sure.

comment:11 @jeremyfelt16 months ago

I'm still grokking this and will test some more later, but at first glance it looks like the biggest chance of breakage is around assigning $current_blog and $current_site in ms-settings.php once the WP_INSTALLING definition is removed.

comment:12 @jeremyfelt15 months ago

  • Keywords needs-testing added
  • Milestone changed from 3.8 to Future Release

I think we need to push this back to the next cycle. Not worth the chance in beta.

comment:13 @iseulde14 months ago

  • Cc jannekevandorpe@… added
  • Summary changed from wp-activate, without explanation, does not load site plugins to wp-activate.php, without explanation, does not load site plugins

comment:14 @jeremyfelt13 months ago

  • Component changed from Multisite to Login and Registration
  • Focuses multisite added
Note: See TracTickets for help on using tickets.