Improve handling of SUBDOMAIN_INSTALL test coverage

[jeremyfelt]

We have a bunch of tests that run (or are skipped) based on is_subdomain_install(), but our Travis CI configuration never runs the tests in a subdomain configuration.

To run the tests now, you need to setup the environment manually. In its current state, 7 tests fail:

1) Tests_Multisite_Site::test_created_site_details
2) Tests_Multisite_Site::test_new_blog_url_schemes with data set #0 ('https', 'https', false)
3) Tests_Multisite_Site::test_new_blog_url_schemes with data set #1 ('http', 'https', false)
4) Tests_Multisite_Site::test_new_blog_url_schemes with data set #2 ('https', 'http', false)
5) Tests_WP_oEmbed::test_wp_filter_pre_oembed_result_multisite_sub_samesub
6) Tests_WP_oEmbed::test_wp_filter_pre_oembed_result_multisite_sub_othersub
7) Tests_WP_oEmbed::test_wp_filter_pre_oembed_result_multisite_preserves_switched_state

The first is a result of our site factory only creating new subdirectory sites. I believe the test_new_blog_url_schemes should be skipped for is_subdomain_install(), but I haven't verified. I'm not sure yet what the issue is with the oEmbed tests.

I'd like to:

• Clean up the existing tests so that they pass.
• Determine a good way of running these in our Travis CI configuration.

It'd be nice *not* to run the entire set of core/multisite tests again just to account for this. Hopefully there's a creative approach to run only the subdomain specific tests.

Previously: #36567, #36566.

[johnbillion]

Brain dump: Allow is_subdomain_install() return value to be filtered, remove usage of SUBDOMAIN_INSTALL constant from tests, allow both subdomain and subdirectory tests to run during one test suite run.

[johnbillion]

Alternatively, it would be neat if all of the Multisite tests ran once under a subdirectory installation and once under a subdomain installation, to ensure everything works on both.

[jeremyfelt]

Replying to johnbillion:

Alternatively, it would be neat if all of the Multisite tests ran once under a subdirectory installation and once under a subdomain installation, to ensure everything works on both.

This is probably the right answer, though it adds a good amount of time to the total CI run. I guess it's our fault for having all of these possible configurations. :)

I'm going to move this to the 5.0 milestone for now. If we start making some progress, then we can still shift to 4.9 for test changes.

Trac ticket: https://core.trac.wordpress.org/ticket/42093

@desrosj Super low priority, I'm just poking to see if I can get this to work. 😄

Is there a best practice for modifying php-tests-run.yml without changing this line?

​https://github.com/WordPress/wordpress-develop/blob/545748c9d26cad8d1565d1acf90cbd75e9d4df84/.github/workflows/phpunit-tests.yml#L39

Or can I tweak that and then revert to test this PR?

Or can I tweak that and then revert to test this PR?

Unfortunately, no. I usually just change it to point to the version in my fork in the PR's branch. jeremyfelt/wordpress-develop.....@add-subdomain-tests in this case.

Just have to remember to change it back when committing to trunk. Adding a comment to that line in the PR could help serve as a call out for that.