[wp-hackers] Multisite options
david at wordshell.net
Mon Jan 20 18:28:52 UTC 2014
Thanks very much for the response...
> I don't think there is a cleaner way to access that value then `$wpdb->base_prefix`. I wouldn't use `$wpdb->get_blog_prefix()` --- semantically that method is intended to retrieve the prefix for a specific blog, and passing 0 is a hack that won't always work due to the issue you discovered.
I'm just a bit nervous about the fact that the value of $base_prefix
isn't marked as public. I've been bitten in the past by relying too much
on the current state of the code, running into later problems, and then
getting the feedback "that's not officially supported, you did it
wrong". The get_blog_prefix() function does seem to explicitly cater for
someone passing in the value "0", so that seems a little bit "official".
I suppose I could hedge my bets by testing the WordPress version (since
I know that it's effectively public up to WP 3.8)... and/or perhaps, by
testing for the inconsistency I've discovered in advance. Any further
thoughts? Anyone who works on WPDB in core have a comment on why
base_prefix isn't explicitly marked as public?
Based on your explanation below, if I've understood rightly, a WPMU
install from before 3.0 could legitimately lack the MULTISITE constant,
even after upgrading to a later version. Multisite status is detected
through other variables. However, I'm still unclear from your
explanation upon what exactly the part of the code inside
get_blog_prefix() that I highlighted is intended to be achieving. I'm
thinking it's buggy... let me explain...
if ( defined( 'MULTISITE' ) && ( 0 == $blog_id || 1 == $blog_id ) )
return $this->base_prefix . $blog_id . '_';
In this part of the code, we know that is_multisite() is true. But, we
don't know that MULTISITE is defined. What is the purpose of the
MULTISITE check? Presumably, it is something to do with the legacy
situation, of a site that was upgraded from a pre-3.0 WPMU install. In
such cases, MULTISITE is not set, and the code enforces the outcome of
$this->base_prefix.$blog_id.'_' - even if $blog_id is 0 or 1. Perhaps
the missing piece of the jigsaw puzzle for me is that "in such installs,
$blog_id can never actually be 0 or 1" ???
Now, into the mix, I now have the information from my particular client.
In his situation, his constants (when read from a plugin page on the
network dashboard, on WordPress 3.8) are as follows (this is what he's
So, the values of VHOST and SUNRISE are causing is_multisite() to be
true. But MULTISITE is not set. His list of blogs includes one with ID 1
(that is, when he sent me his list of tables, he's got wp_1_*).
In this scenario, it appears to be impossible to get get_blog_prefix()
to return the base prefix, so my only option is to read
wpdb::base_prefix directly. But I wonder if I should also file a
bug/patch in trac so that the case of $blog_id == 0 always returns
base_prefix, regardless of MULTISITE - because get_blog_prefix() does
seem to want to be able to respond properly to the case $blog_id == 0,
and presently it's only doing so sometimes.
> The logic involving the `SUBDOMAIN_INSTALL` and `VHOST` constants is for backwards compatibility with pre-WP 3.0 installs.
> Prior to WP 3.0 there was a separate code base dedicated to multisite --- WPMU. There was no need for a `MULTISITE` constant as that was the only option you had. Instead, the `VHOST` constant was used to indicate whether or not it was a sub-domain or sub-directory install.
> A fresh install of WPMU used `wp_1_` for the first blog prefix. When the single / MU codebases merged in WP 3.0, a fresh install used `wp_` for the first blog prefix. When converted to multisite (http://codex.wordpress.org/Create_A_Network), `wp_2_` was used for the next blog, so on and so on.
> In order for WPMU-era installs to continue to work post-3.0, there are several places that use the definition of `MULTISITE` to decide which database prefix / uploads directory to use for the main site.
UpdraftPlus - best WordPress backups - http://updraftplus.com
WordShell - WordPress fast from the CLI - http://wordshell.net
More information about the wp-hackers