[wp-hackers] Multisite options

[David Anderson]

Hi Mike,

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;
else
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 
sent me):
MULTISITE: (undefined)
SUBDOMAIN_INSTALL: (undefined)
VHOST: no
SUNRISE: on

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.

David

> 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.
>
> Best,
> Mike

-- 
UpdraftPlus - best WordPress backups - http://updraftplus.com
WordShell - WordPress fast from the CLI - http://wordshell.net