siteurl is missing WordPress path when creating a new site

[danielbachhuber]

Our setup is a single subdomain network. WordPress is installed to /wp, and we don't have rewrites configured to mask the subdirectory.

On the initial install, wp_install() sets the value of siteurlbased on wp_guess_url(). The main site ends up with these expected values:

• siteurl: domain.com/wp
• home: domain.com

On subsequent creation of a new site, install_blog() incorrectly sets the option values for the new site to:

• siteurl: domain.com
• home: domain.com

This means the admin loads, but CSS and resources are broken, until I update the siteurl option value to be "domain.com/wp".

I'd expect install_blog() to follow the same behavior as wp_install_blog().

#23221 is related, although this suggested fix doesn't also fix that.

[thewebists]

I've come across this issue when using Bedrock (and the same would apply to Mark Jaquith's Skeleton).

For those seeing this problem, my quick fix for this is to define a CORE_DIR constant in wp-config to specify an optional subdirectory location for the core WordPress files. Then I run the following in a mu-plugin:

/**
 * Temporary fix for issue #27287 for multisite blogs with WordPress in it's own subdirectory
 * for use with projects such as https://github.com/roots/bedrock and 
 * https://github.com/markjaquith/WordPress-Skeleton
 * 
 * @see https://core.trac.wordpress.org/ticket/27287
 */
add_action( 'wpmu_new_blog', function( $blog_id ){
	if (defined('SUBDOMAIN_INSTALL') && SUBDOMAIN_INSTALL && defined('CORE_DIR') && !empty(CORE_DIR)) {
		switch_to_blog($blog_id);
		$siteurl = untrailingslashit(get_option('siteurl'));
		if (!(strpos($siteurl, CORE_DIR) + strlen(CORE_DIR) === strlen($siteurl))) {
			update_option( 'siteurl', $siteurl . '/' . CORE_DIR );
		}
		restore_current_blog();
	}
});

If you're seeing this, then you've probably also come across issue #23221. See the OP's solution here: https://core.trac.wordpress.org/ticket/23221#comment:27

[Compute]

Adding a filter for the meta wpmu_create_blog #28540 would make this task even easier.

Just adding:

$meta['siteurl'] = esc_url( $domain . '/wp );

To this filter would do the trick.

[flixos90]

I use the following to ensure that all home / site URLs work properly (given my WordPress directory is called core, but a constant could obviously be used as well):

<?php
class URLFixer {
        public function run() {
                add_filter( 'option_home', array( $this, 'fix_home_url' ) );
                add_filter( 'sanitize_option_home', array( $this, 'fix_home_url' ) );

                add_filter( 'option_siteurl', array( $this, 'fix_site_url' ) );
                add_filter( 'sanitize_option_siteurl', array( $this, 'fix_site_url' ) );
        }

        public function fix_home_url( $value ) {
                if ( '/core' === substr( $value, -5 ) ) {
                        $value = substr( $value, 0, -5 );
                }
                return $value;
        }

        public function fix_site_url( $value ) {
                if ( '/core' !== substr( $value, -5 ) ) {
                        $value .= '/core';
                }
                return $value;
        }
}

There are still quite a few areas on multisite which assume that home and siteurl have the same value or that show one of the two values in the wrong context (see #35632). I wonder if we should create a centralized ticket for these issues.

[realloc]

Current state

install_blog() was deprecated in 5.1.0. Site initialization now runs through wp_initialize_site() in wp-includes/ms-site.php:

'home'    => untrailingslashit( $home_scheme . '://' . $site->domain . $site->path ),
'siteurl' => untrailingslashit( $siteurl_scheme . '://' . $site->domain . $site->path ),

Both values come from the same source. The only distinction is the scheme, and only for subdirectory installs. A separate directory for the WordPress files is still not accounted for.

Why there is no patch

The information does not exist anywhere the function could read it. The blogs table stores domain and path, and no option records that core lives in a subdirectory. That detail is determined once by wp_guess_url() during the initial install and ends up only in the main site's siteurl. A fix would have to reconstruct it from the difference between home and siteurl of the main site, or store it explicitly.

Current workaround

The approaches suggested above can be replaced. Since 5.1.0, wp_initialize_site_args allows setting $args['options']['siteurl'] before populate_options() runs, so no post-creation correction is needed. Installs defining WP_SITEURL and WP_HOME in wp-config.php are unaffected, since constants take precedence.

Open question

Should multisite support home and siteurl pointing to different locations at all? Several places assume they are interchangeable, see comment 4 and #35632. Answering that decides whether this is a small fix in wp_initialize_site() or part of a larger effort.