[wp-hackers] Multisite options

[Mika A Epstein]

Paul, WPMU != WordPress Multisite :)

On old WPMU installs (i.e. pre 3.0) you did use the tables wp_1_ for site #1

On current multisite, Site #1 uses wp_ for it's prefix, and site #2 uses 
wp_2_ and so on and so forth.

Mike is correct on that front as well as on the VHOST/MULTISITE define. 
Older installs of WPMU that were upgraded to WordPress Multisite 
generally don't have that MULTISITE define (which is good, because when 
they do, WP bails when it can't find the wp_ tables it wants).

Old upgrades is uglies, man :/

> Paul Menard <mailto:paul at codehooligans.com>
> 20 January, 2014 at 12:13:09PM
> Mike
>
> Actually you do know that 'MULTISITE' is define. When you enable Multisite
> on a regular WordPress install it is one of the new settings you are
> instructed to add to your wp-config.php.
> http://codex.wordpress.org/Create_A_Network see step 4.
>
> MULTISITE is a PHP define you can check using is_defined('MULTISITE').
>
> Paul
>
>
>
>
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
> Paul Menard <mailto:paul at codehooligans.com>
> 20 January, 2014 at 12:10:26PM
>
> Actually that is not accurate. The first install (http://somesite.com) has
> prefix 'wp_'. This is the initial installed site which is also the 
> database
> used by the Network. When you enable Multisite you will see all the 
> network
> table have the same base prefix 'wp_', Then when you create a new blog (
> http://site1.simesite.com) it will have the prefix wp_1_, then the next (
> http://site2.somesite.com) will have prefix wp_2_
>
> P-
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
> Mike Burns <mailto:mike at grady-etc.com>
> 20 January, 2014 at 8:07:06AM
> 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.
>
> 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
> _______________________________________________
> wp-hackers mailing list
> wp-hackers at lists.automattic.com
> http://lists.automattic.com/mailman/listinfo/wp-hackers
> David Anderson <mailto:david at wordshell.net>
> 20 January, 2014 at 2:02:01AM
> Hi,
>
> I am working with code that wants to get the WordPress site's base 
> table prefix on a WPMU install. i.e. The original $table_prefix - not 
> its *current* value (which can be changed due to site switching).
>
> This is available as $wpdb->base_prefix. However, this is only public 
> by default. The class itself does not explicitly mark it as public or 
> private. So, I reasoned that probable $wpdb->get_blog_prefix() is the 
> "proper" way to read it.
>
> The code of that function is as follows:
>
>     function get_blog_prefix( $blog_id = null ) {
>
>         if ( is_multisite() ) {
>
>             if ( null === $blog_id )
>
>                 $blog_id = $this->blogid;
>
>             $blog_id = (int) $blog_id;
>
>             if ( defined( 'MULTISITE' ) && ( 0 == $blog_id || 1 == 
> $blog_id ) )
>
>                 return $this->base_prefix;
>
>             else
>
>                 return $this->base_prefix . $blog_id . '_';
>
>         } else {
>
>             return $this->base_prefix;
>
>         }
>
>     }
>
> It thus looks like $wpdb->get_blog_prefix(0) is the way to get the 
> value I want. However, I am confused about the purpose of the block 
> that begins with if (defined( 'MULTISITE' )).
>
> What is the specific purpose of the defined('MULTISITE') check? One 
> might guess that MULTISITE will always be defined if is_multisite() 
> passed. However, a look at is_multisite() shows that this is not 
> necessarily so:
>
> function is_multisite() {
>
>     if ( defined( 'MULTISITE' ) )
>
>         return MULTISITE;
>
>     if ( defined( 'SUBDOMAIN_INSTALL' ) || defined( 'VHOST' ) || 
> defined( 'SUNRISE' ) )
>
>         return true;
>
>     return false;
>
> }
>
> So, is_multisite() can return true even if MULTISITE is not true; 
> there are the additional situations where any of the 3 constants 
> SUBDOMAIN_INSTALL, VHOST or SUNRISE are defined (regardless of their 
> value).
>
> In that situation, $wpdb->get_blog_prefix() will actually return the 
> value of: $this->base_prefix . '0_'
>
> That doesn't seem like it can be correct. On the other hand, the code 
> seems to be careful to bring about this result. It seems to be 
> deliberately engineered with the possibility that is_multisite() is 
> true but MULTISITE is not true.
>
> Can someone give me a clue with what's going on here? I'm asking 
> because I've just come across a user for whom $wpdb->get_blog_prefix() 
> does actually return $this->base_prefix . '0_' - and he has no tables 
> at all with that prefix. It seems like the wrong result. I've not yet 
> got the information on the value of all those constants from him, but 
> he says it's a WPMU install. I'm looking into whether his install is 
> set up wrongly, but my question to wp-hackers is as to whether the 
> $wpdb->get_blog_prefix() is functioning as intended, or whether this 
> is a subtle bug, or whether I'm simply getting the base prefix in the 
> wrong way and should be using a different strategy.
>
> Many thanks,
> David
>

-- 
Mika A Epstein (aka Ipstenu)
http://ipstenu.org | http://halfelf.org