[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