WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 5 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: needs-testing needs-patch
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 3 years ago.

Download all attachments as: .zip

Change History (19)

#1 @radiok
3 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.

#2 @radiok
3 years ago

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

#3 @johnbillion
3 years ago

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

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

#4 @SergeyBiryukov
3 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.

#5 @johnbillion
3 years 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.

#6 @johnbillion
3 years ago

  • Keywords needs-patch added

@johnbillion
3 years ago

#7 follow-up: @johnbillion
3 years 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?

#8 @SergeyBiryukov
3 years ago

  • Milestone changed from Awaiting Review to 3.7

Moving for review along with #24960.

#9 @johnbillion
3 years 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.

#10 in reply to: ↑ 7 @nacin
3 years 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.

#11 @jeremyfelt
3 years 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.

#12 @jeremyfelt
3 years 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.

#13 @iseulde
2 years 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

#14 @jeremyfelt
2 years ago

  • Component changed from Multisite to Login and Registration
  • Focuses multisite added

#15 @chriscct7
9 months ago

  • Keywords needs-refresh added

#16 @jeremyfelt
9 months ago

Digging a bit more into history on this. https://mu.trac.wordpress.org/ticket/1151 provides a bit more insight, though not much.

Part of me wonders if this is just precautionary, but it's hard to tell. If an activation key is provided, wpmu_create_blog() ends up firing and also ensures that WP_INSTALLING is set to true. That would be after plugins are already loaded if we removed the initial check. I followed the chain and never ran into anything that relied on it.

This still needs some good testing, probably with several popular plugins activated while working the activation process.

#17 @jeremyfelt
7 months ago

  • Keywords needs-patch added; has-patch needs-refresh removed

More info: WP_INSTALLING is set in wp-activate.php so that an activation link can be followed on a new subdomain without that subdomain yet existing in wp_blogs. In ms-settings.php, if WP_INSTALLING is set, then the information for the main site is loaded even though the new site is being activated.

Removing WP_INSTALLING would probably require a slightly refactored activation process.

#18 @jeremyfelt
5 months ago

#35443 was marked as a duplicate.

Note: See TracTickets for help on using tickets.