[wp-trac] [WordPress Trac] #26855: get_blogaddress_by_id used in wp-activate.php limits functionality in MU Domain Mapped Sites

WordPress Trac noreply at wordpress.org
Fri Jan 17 04:11:05 UTC 2014


#26855: get_blogaddress_by_id used in wp-activate.php limits functionality in MU
Domain Mapped Sites
-----------------------------------+------------------------------
 Reporter:  boboudreau             |       Owner:
     Type:  defect (bug)           |      Status:  new
 Priority:  normal                 |   Milestone:  Awaiting Review
Component:  Multisite              |     Version:  trunk
 Severity:  normal                 |  Resolution:
 Keywords:  2nd-opinion has-patch  |
-----------------------------------+------------------------------

Comment (by boboudreau):

 Right, I hadn't thought that the two values for `siteurl` in
 `wp_#_options` and `domain` + `path` in `wp_blogs` represent two different
 things and depending on your site setup you might want each.

 For a site using domain mapping, neither of those matter, at all, and
 which blog to use depends on the domain mapping table which maps a domain
 to a blog_id.

 I've been working on a database that's been in production since WP2.x, so
 I'm not 100% sure what a normal setup looks like when you create a child
 site (as a subdirectory), and then do whatever is necessary to map it to a
 domain (or not, if you aren't domain mapping).  As I mentioned, the
 sunrise.php file from the domain mapping plugin just matches the HTTP_HOST
 of the server to the domain making the request, and changes the
 `$current_site` and `$current_blog` as appropriate.

 In any case, for '''THIS''' patch in particular it's not necessary to look
 through the 26 instances of `get_blogaddress_by_id()` across 12 files to
 see what they do, just whether or not it's safe to make the change
 '''HERE'''.

 If I were to use the `blog_details` filter then I'd need to make sure I
 understand the implications everywhere else (since `$details` is also
 hashed and cached for usage elsewhere).  Unfortunately, in this situation
 I can't even use that filter, because `get_blogaddress_by_id` calls
 `get_blog_details` with the `$get_all` parameter as FALSE, and so the
 `apply_filter` for `blog_details` is never executed.  I'm stuck modifying
 core no matter what.

 Lines 205-223 in ms-blogs.php in SVN:

 {{{
         if ( ! $get_all ) {
                 wp_cache_set( $blog_id . $all, $details, 'blog-details' );
                 return $details;
         }

         switch_to_blog( $blog_id );
         $details->blogname              = get_option( 'blogname' );
         $details->siteurl               = get_option( 'siteurl' );
         $details->post_count    = get_option( 'post_count' );
         restore_current_blog();

         /**
          * Filter a blog's details.
          *
          * @since MU
          *
          * @param object $details The blog details.
          */
         $details = apply_filters( 'blog_details', $details );
 }}}


 In my setup, the patch appears to works well (multi-site with
 subdirectory).  Would have to confirm the same with multi-site subdomain,
 and single-site setups.

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


More information about the wp-trac mailing list