[wp-trac] [WordPress Trac] #24760: Creating default object from empty value in wp-includes/ms-settings.php on line 111

[WordPress Trac]

#24760: Creating default object from empty value in wp-includes/ms-settings.php on
line 111
---------------------------------------+-----------------------------
 Reporter:  conner_bw                  |       Owner:
     Type:  defect (bug)               |      Status:  reopened
 Priority:  normal                     |   Milestone:  Future Release
Component:  Multisite                  |     Version:  3.0
 Severity:  normal                     |  Resolution:
 Keywords:  needs-testing needs-patch  |     Focuses:  multisite
---------------------------------------+-----------------------------
Changes (by jeremyfelt):

 * keywords:  reporter-feedback needs-testing => needs-testing needs-patch
 * focuses:   => multisite
 * milestone:  Awaiting Review => Future Release


Comment:

 I'm able to confirm the current manifestation of this in trunk thanks to
 the info provided in the last few comments.

 1. Subdomain configuration of multsite with site registration enabled.
 2. Signup for a new site at `site.foo.bar/wp-signup.php`.
 3. Follow the activation link sent via email to `new.site.foo.bar/wp-
 signup.php`.

 {{{
 Notice: Undefined property: stdClass::$domain in .../src/wp-includes/ms-
 settings.php on line 189
 Notice: Undefined property: stdClass::$public in .../src/wp-includes/ms-
 settings.php on line 199
 }}}

 As `new.site.foo.bar` is not yet added as a row in `wp_blogs`, the given
 domain is not able to match an existing site. Normally, this would
 redirect to a signup page or follow `NOBLOGREDIRECT`. But there's this:

 {{{
 // @todo Investigate when exactly this can occur.
 if ( empty( $current_blog ) && wp_installing() ) {
         $current_blog = new stdClass;
         $current_blog->blog_id = $blog_id = 1;
 }
 }}}

 That todo has made me laugh for a couple years now and I've never properly
 traced it through. `wp-activate.php` sets the `WP_INSTALLING` constant as
 true and then loads `wp-load.php`, which starts the bootstrap process and
 runs into this block.

 We can ''probably'' set the path, domain, and public properties of
 `$current_blog` to `$domain, $path, and 1` respectively to ensure a more
 full object is provided.

 We can also update that todo line. :)

--
Ticket URL: <https://core.trac.wordpress.org/ticket/24760#comment:17>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform