Deprecate VHOST in favor of a boolean

[Denis-de-Bernardy]

or maybe change the checks to something like this, so as to give plugin authors the time to update their code:

if ( VHOSTS && VHOSTS != 'no' )

Or maybe add some kind of function call that returns true|false so that plugin devs don't need to worry about the constant's value.

[andrea_r]

Just an explanation so you know wher eit comes from:

the vhost check is set on install in MU to determine the type of sub-blogs. VHOST=yes is for subdomain blogs via wildcard subdomains set on the server. VHOST=no is for subdirectory blogs.

[filosofo]

But the question is whether VHOST ever has more than two possible values. In core it doesn't.

"yes" and "no" are better expressed by a boolean, as Denis suggests.

[wpmuguru]

(In [12674]) Add is_subdomain_install() to ms code - Fixes #11796

[nacin]

As Denis suggested, I think it would makea lot of sense to standardize this on define('VHOST', true) and define('VHOST', false), instead of keeping "yes" and "no".

is_subdomain_install() should be switched to this:
if ( defined('VHOST') && VHOST && VHOST != 'no' )

[Denis-de-Bernardy]

adding to nacin's comment, maybe the function ought to be called is_vhost_enabled() or something. is_subdomain_install() makes it sound like we're on a subdomain.

[nacin]

Replying to Denis-de-Bernardy:

adding to nacin's comment, maybe the function ought to be called is_vhost_enabled() or something. is_subdomain_install() makes it sound like we're on a subdomain.

Possibly, but in the context of MU alone, this makes sense. VHOST is for a subdomain install, otherwise MU operates with subdirectories. Perhaps is_ms_vhost(), is_multisite_subdomain(), is_multisite_on_vhost(), etc.

[nacin]

Patch attached to convert VHOSTS to a boolean.

This will break any plugins (including super cache etc.) that rely on a straight VHOST = 'yes' or VHOST == 'no' check, but 3.0 is the best time to do that. An MU config file will still work, as is_subdomain_install() is adjusted to account for the deprecated 'yes' and 'no' value.

I'm thinking we should possibly throw a deprecated argument warning if they're defining VHOST as 'yes' or 'no' in config.

[wpmuguru]

Replying to nacin:

Patch attached to convert VHOSTS to a boolean.

This will break any plugins (including super cache etc.) that rely on a straight VHOST = 'yes' or VHOST == 'no' check, but 3.0 is the best time to do that. An MU config file will still work, as is_subdomain_install() is adjusted to account for the deprecated 'yes' and 'no' value.

Please have consideration for plugin authors when requesting semantic changes. In addition, backward compatibility, the MU plugin API, etc. were discussed in the meetup on January 7, 2010.

​https://irclogs.wordpress.org/chanlog.php?channel=wordpress-dev&day=2010-01-07#m51727

[nacin]

As an MU administrator I am fully prepared for my blog to break on the next upgrade, but you're right.

The more I think about this, I think we should deprecate the VHOST constant all together. We'll create a new boolean SUBDOMAIN_INSTALL constant and encourage use of the API, is_subdomain_install().

If VHOST is defined, we'll throw a deprecated warning and inform them of SUBDOMAIN_INSTALL and is_subdomain_install(). We'll also define VHOST for back compat when we're using the new constant. If both is defined for some reason, we'll use SUBDOMAIN_INSTALL and throw a deprecated warning, unless of course they are set to different things, in which case we pick SUBDOMAIN_INSTALL and throw a louder error.

Not only does this get us away from yes/no to a bool, it also will encourage very quickly the use of is_subdomain_install().

Let me put together a patch.

[dd32]

I think we should deprecate the VHOST constant all together

That'd be my preference as well.

Simply for the fact its using yes/no, which should be avoided for cleaner typed bools and/or the API.

Breaking backwards compatibility for a simple constant change doesnt seem worth it to me, but a better constant name & value is still needed

[nacin]

Would introduce SUBDOMAIN_INSTALL and deprecate VHOST

[nacin]

A backwards compatible patch is attached.

It relies on some constant mapping in default-constants.php, to ensure that both end up being defined.

If VHOST and SUBDOMAIN_INSTALL are both already defined and they conflict, then a warning is triggered (and it uses SUBDOMAIN_INSTALL). Otherwise, a notice is triggered if VHOST is already defined.

[wpmuguru]

(In [12836]) Change VHOST check to is_subdomain_install(), See #11796

[wpmuguru]

This constant is being included in the merge for backward compatability with WordPress MU. The terminology changes being made as part of the merge reflect change in the range and scope of architectural implementations of MU (and multiple sites).

The VHOST constant imposes a limitation on what can be done with the WP network code. I'm not introducing a second constant to be worked around, and, potentially have to deprecate out in the future.

Changing the milestone so that this can be discussed at the next multisite component scope meeting.

[nacin]

The VHOST constant imposes a limitation on what can be done with the WP network code. I'm not introducing a second constant to be worked around, and, potentially have to deprecate out in the future.

Can you explain that a little further? The subdirectory route (VHOST = no) is a choice some make even if they have the capability to implement subdomains. We're not dealing with a limitation or workaround, we're dealing with an option. I'm not sure why it would need to be deprecated out -- are you saying the thought is that the option between subdomains and subdirectories might eventually be stored at the database level?

[xibe]

First try at updated patch.

[nacin]

(In [14452]) Deprecate VHOST in favor of a boolean, SUBDOMAIN_INSTALL. Core will keep VHOST defined for plugins' sake, but you should only define SUBDOMAIN_INSTALL. Throws a notice if VHOST is defined, and a warning if they somehow conflict. Sunrise can still handle them. fixes #11796.