Make WordPress Core

Opened 10 years ago

Last modified 5 years ago

#27287 new defect (bug)

siteurl is missing WordPress path when creating a new site

Reported by: danielbachhuber's profile danielbachhuber Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Networks and Sites Keywords: needs-patch needs-unit-tests
Focuses: multisite Cc:


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:
  • home:

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

  • siteurl:
  • home:

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

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.

Change History (5)

#1 @thewebists
10 years ago

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 and 
 * @see
add_action( 'wpmu_new_blog', function( $blog_id ){
	if (defined('SUBDOMAIN_INSTALL') && SUBDOMAIN_INSTALL && defined('CORE_DIR') && !empty(CORE_DIR)) {
		$siteurl = untrailingslashit(get_option('siteurl'));
		if (!(strpos($siteurl, CORE_DIR) + strlen(CORE_DIR) === strlen($siteurl))) {
			update_option( 'siteurl', $siteurl . '/' . CORE_DIR );

If you're seeing this, then you've probably also come across issue #23221. See the OP's solution here:

#2 @Compute
10 years ago

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.

Last edited 10 years ago by Compute (previous) (diff)

#3 @chriscct7
9 years ago

  • Keywords needs-unit-tests added

#4 @flixos90
8 years ago

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):

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.

This ticket was mentioned in Slack in #core-multisite by flixos90. View the logs.

8 years ago

Note: See TracTickets for help on using tickets.