WordPress.org

Make WordPress Core

Opened 2 years ago

Last modified 17 months ago

#33909 new defect (bug)

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

Reported by: jlambe Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.0
Component: Upgrade/Install Keywords: 2nd-opinion has-patch reporter-feedback dev-feedback
Focuses: multisite Cc:

Description

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:

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

Attachments (6)

33909.diff (616 bytes) - added by kraftbj 2 years ago.
Add check for home constant in populate_options().
33909.2.diff (852 bytes) - added by kraftbj 2 years ago.
Complete version of the 1st patch.
33909.3.diff (919 bytes) - added by fgirardey 2 years ago.
Use rtrim on WP_HOME as wp_guess_url() does.
33909.4.diff (17.7 KB) - added by fgirardey 2 years ago.
Fix tab indent
33909.5.diff (904 bytes) - added by fgirardey 2 years ago.
33909.6.diff (2.6 KB) - added by fgirardey 2 years ago.
Fix the installation process for WP_HOME and fix the blog installation for the siteurl

Download all attachments as: .zip

Change History (20)

#1 @fgirardey
2 years ago

  • Component changed from Networks and Sites to Database
  • Keywords 2nd-opinion added

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.

#2 follow-up: @kraftbj
2 years ago

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

#3 @jlambe
2 years ago

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?

#4 @SergeyBiryukov
2 years ago

  • Component changed from Database to Upgrade/Install

#5 in reply to: ↑ 2 ; follow-up: @fgirardey
2 years ago

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.

#6 @fgirardey
2 years ago

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

#7 in reply to: ↑ 5 @kraftbj
2 years ago

  • Keywords has-patch added

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
2 years ago

Add check for home constant in populate_options().

@kraftbj
2 years ago

Complete version of the 1st patch.

@fgirardey
2 years ago

Use rtrim on WP_HOME as wp_guess_url() does.

@fgirardey
2 years ago

Fix tab indent

#8 @fgirardey
2 years ago

Uuh something is weird with the code I attached haha '

Last edited 2 years ago by fgirardey (previous) (diff)

@fgirardey
2 years ago

@fgirardey
2 years ago

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

This ticket was mentioned in Slack in #core by fgirardey. View the logs.


2 years ago

#10 @fgirardey
2 years ago

  • Keywords reporter-feedback dev-feedback added

#11 @jeremyfelt
2 years ago

  • Version changed from trunk to 3.0

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

#12 follow-up: @fgirardey
2 years ago

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…

#13 in reply to: ↑ 12 @jackreichert
19 months ago

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.

#14 @silb3r
17 months ago

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

Note: See TracTickets for help on using tickets.