Allow overriding constants in testing framework

[rmccue]

bootstrap.php in our testing harness sets some constants, and it's impossible to override these (without warnings, at least). In particular, you can define WP_TESTS_MULTISITE to set multisite, but you can't set SUBDOMAIN_INSTALL. This makes it impossible to test sites which need multisite, or to test plugins which do subdomain-specific things (such as domain mapping and aliasing).

These should only be defined if not already, rather than forcing them.

[rmccue]

Allow overriding constants in config

[rmccue]

Attached patch splits the conditional into a more readable form using the variable directly, and allows defining MULTISITE and SUBDOMAIN_INSTALL in your wp-config.php directly.

[jeremyfelt]

Yeah.

If you define SUBDOMAIN_INSTALL as true in wp-tests-config.php:

• wp-tests-config.php is passed to the the test installer, which loads wp-settings.php.
• In wp-settings.php, wp_not_installed() fires, which checks is_multisite().
• is_multisite() falls back to SUBDOMAIN_INSTALL if MULTISITE has not been defined, so passes.
• is_blog_installed() is then checked.
• $wpdb->options is wptests_1_options, because $wpdb->get_blog_prefix() checks MULTISITE, not SUBDOMAIN_INSTALL.
• wptests_1_options doesn't exist, nor do any of the wptests_1_* tables, and so dead_db() is fired.
• A bunch of HTML outputs to show the error page, which is more annoying than anything because the tests work just fine if you've already run everything once before setting SUBDOMAIN_INSTALL.

So I guess the first question is: Why do we not use is_multisite() in $wpdb->get_blog_prefix, because changing that appears to fix this and allows the tests to install fresh if you recreate the DB.

[rmccue]

You can define it without any issues by wrapping in a WP_INSTALLING check:

if ( ! defined( 'WP_INSTALLING' ) ) {
	define( 'MULTISITE', true );
	define( 'SUBDOMAIN_INSTALL', true );
}

Sub-optimal, I agree, and I get bitten by that every time.

[jeremyfelt]

Oh, heh. I thought I tried that.

We've required more sub-optimal than that... :)

[pento]

Replying to jeremyfelt:

So I guess the first question is: Why do we not use is_multisite() in $wpdb->get_blog_prefix, because changing that appears to fix this and allows the tests to install fresh if you recreate the DB.

​This became that when MU was merged, then @nacin added an is_multisite() check, then nothing has changed since then, because we're all too scared to touch that code.

[jeremyfelt]

For the most part, tests work with SUBDOMAIN_INSTALL enabled. There are 4 failing tests in tests/multisite/site.php due to the way our blog factory assumes a subdirectory configuration and how tests handle that. We should be able to fix this as part of #36566.

[jeremyfelt]

In 37266:

Tests: Allow override of MULTISITE and SUBDOMAIN_INSTALL constants

Props rmccue.
Fixes #36567.

[rmccue]

Replying to jeremyfelt:

For the most part, tests work with SUBDOMAIN_INSTALL enabled. There are 4 failing tests in tests/multisite/site.php due to the way our blog factory assumes a subdirectory configuration and how tests handle that. We should be able to fix this as part of #36566.

FWIW, I'm happy for core tests to fail; the main issue was that this occurred any time you use core's bootstrapping, i.e. for plugin or site testing. So long as the framework works, rmccue-likes.