The `home` option not equivalent to the WP_HOME constant value in multisite and single instance

[jlambe]

Hi,

for this issue, I'm running a multisite instance with custom WordPress and wp-content directory paths where I set the constants WP_SITEURL and WP_HOME values as follow:

• WP_HOME: ​http://mydomain.com/
• WP_SITEURL: ​http://mydomain.com/cms (where WordPress is installed)

All the process during the installation is working perfectly and the multisite instance is installed as expected...except when you click on the admin toolbar button Visit site for example.

Here is the issue, the site URL is set as ​http://mydomain.com/cms where it should be ​http://mydomain.com. This issue is becoming a user experience issue because both URLs with and without the cms URI are working. But all anchor tags href attribute have the wrong value.

When looking at the database wp_options table, we can see that both home and siteurl options have a value of ​http://mydomain.com/cms which should only be siteurl with this value.

I'm filling this issue mainly for multisite because the anchor tags used to visit the site have the wrong value but note that even for single WordPress installation, the options values are wrong in the wp_options table. Both have the same value where only the siteurl should get cms URI in this example. But when you're on a single instance all anchor tags href attributes have the correct URL in order to visit the site where in multisite they are wrong.

So there are 2 things to look at here probably:

• First why the wp_options values are not equal to the set constants WP_HOME and WP_SITEURL?
• Second, why in a single instance URLs are correct (even if values in the database are wrong) and not on multisite?

Best regards

[fgirardey]

Hi,

I've juste found that bug for the exactly same use case.

I think the problem comes directly from the installation process, because after installing WordPress if you change the wp_options.home to the correct value and then you install a network, the value of wp_blogs.domain is correct.

It seems that at installation the wp_options.siteurl and wp_options.home relies on the same function which is wp_guess_url() which is an error because this function only use WP_SITEURL when the constant is defined.

[kraftbj]

This is intended behavior. The constants have no impact on Multisite: https://core.trac.wordpress.org/changeset/14517

[jlambe]

Even if it's intended to not use the constants, the values inside the wp_options table are still wrong and do no reflect the project structure.

Also, as written, the issue is still available on a single instance installation so the constants should have an impact in single instance installation?

[fgirardey]

Replying to kraftbj:

This is intended behavior. The constants have no impact on Multisite: https://core.trac.wordpress.org/changeset/14517

The intended behavior is : WP_HOME and WP_SITEURL should not have any effect in MS

Fine, so MS rely on the values inserted in the database, but when you perform a fresh install of WordPress, the value of wp_options.home is wrong.

The only case it is broken is when you install a single instance of WordPress with defined WP_HOME and WP_SITEURL and then you install a network.

[fgirardey]

I found two things about this problem :

1) The single site installation process

There is a problem with the wp_guess_url() function because it only relies on the WP_SITEURL constant. We need to introduce a way for the installation process to request the WP_HOME value in the populate_options() function.

Maybe we can introduce an argument in that function to choose the type of URL we need (home or siteurl).

2) The blog installation process

When we install a new blog in a network, WP_SITEURL and WP_HOME are always the same which is wrong…

For that case, it is a bit more complicated because it involves changes in the multisite installation process…

---

Anyway if somebody want to work closer on that, let me know, i want to help :)

[kraftbj]

Replying to fgirardey:

The only case it is broken is when you install a single instance of WordPress with defined WP_HOME and WP_SITEURL and then you install a network.

That does seem like a bug. I didn't track that was the original issue being reported.

Some code links:
The options are populated by populate_options, including both home/site URL by wp_guess_url, here: https://core.trac.wordpress.org/browser/tags/4.3.1/src/wp-admin/includes/schema.php#L347

wp_guess_url uses only the siteurl constant, here: https://core.trac.wordpress.org/browser/tags/4.3.1/src/wp-includes/functions.php#L3806

With the exception of this case, wp_guess_url is only used in the context of needing the site_url, so what about a check for the constant in populate_options?

cc @jeremyfelt for his multisite expertise.

[kraftbj]

Add check for home constant in populate_options().

[kraftbj]

Complete version of the 1st patch.

[fgirardey]

Use rtrim on WP_HOME as wp_guess_url() does.

[fgirardey]

Fix tab indent

[fgirardey]

Uuh something is weird with the code I attached haha '

[fgirardey]

Fix the installation process for WP_HOME and fix the blog installation for the siteurl

[jeremyfelt]

I need to grok this a bit more, but I don't believe it's a regression against trunk.

[fgirardey]

I didn't tested this bug against trunk since 8 weeks, i know that there is a lot of Multisite related changes in 4.4, maybe it has been resolved in an another patch…

[jackreichert]

Replying to fgirardey:

I didn't tested this bug against trunk since 8 weeks, i know that there is a lot of Multisite related changes in 4.4, maybe it has been resolved in an another patch…

I just tested this in the trunk. It's still an issue. All admin links in a multisite where WP_HOME != WP_SITEURL the link does not take the change into consideration.

[silb3r]

Would love to see some movement on this because it's still an issue. Thank you!