It is unclear what the two URL settings mean.

[billpg]

There are two settings that accept a URL on the General Settings page: "WordPress Address (URL)" and "Site Address (URL)".

To me, those two labels both mean exactly the same thing. It isn't clear if/when I should configure different values in these fields.

If the two settings do actually mean the same thing, then one should be removed and code looking-up its value should be modified to read the remaining setting instead.

If the two settings serve different purposes, then each one should have a note describing what it is used for and the labels should be changed to reflect those different purposes.

[peterwilsoncc]

Hi @billpg and welcome to trac!

The settings do server different purposes but, you are correct, the explanation could be clearer.

It's possible for WordPress to be installed at a different address than the home page, most commonly it's in a sub-directory:

WordPress address: example.com/wp
Site address: example.com

In this example, the admin would be at example.com/wp/wp-admin/

Do you have any thoughts on the explanatory text WordPress could add to make this clearer?

[billpg]

Is "Site Address" to make the post/page permalink URLs, while "WordPress Address" is to construct the "wp-admin", "wp-content", etc URLs?

It would be useful to understand a use-case for keeping those two as separate settings with different values. My own website was in a sub-folder (​https://billpg.com/site/) until I found a .htaccess setting to deal with requests that don't have a corresponding file in my public_html folder by silently rewriting URLs into my "site" folder. Before and after that reconfiguration, both URL settings inside WP had the same value as each other. "​https://billpg.com/site" before and "​https://billpg.com" after.

[peterwilsoncc]

Replying to billpg:

Is "Site Address" to make the post/page permalink URLs, while "WordPress Address" is to construct the "wp-admin", "wp-content", etc URLs?

Yes, that is correct.

It would be useful to understand a use-case for keeping those two as separate settings with different values. My own website was in a sub-folder (​https://billpg.com/site/) until I found a .htaccess setting to deal with requests that don't have a corresponding file in my public_html folder by silently rewriting URLs into my "site" folder. Before and after that reconfiguration, both URL settings inside WP had the same value as each other. "​https://billpg.com/site" before and "​https://billpg.com" after.

The use case is that it allows site owners to put three files in the site's root directory (site URL) and refer to the sub-directory directory (WordPress URL). It saves the effort of modifying the .htaccess file to rewrite URLs.

I've set up a gist with the ​three files in my site's root directory.

[sabernhardt]

Related: #50886

[SergeyBiryukov]

The help text for the WordPress URL and Site URL settings has been improved in [55452] / #50886.

Is that clarification good enough for now? Are any further adjustements needed?

[oglekler]

I am suggesting short and clear explanation right on the places where we need them (the mockup is above). We have another ticket with proposal to add tooltips #51006, and I believe that they will help us immensely to make clear but informative design.

This fields still confusing me, because
Site Address (URL) = home_url()
WordPress Address (URL) = site_url()

And with regard to the Help, I am suggesting to make bold subtitles according to settings part it referenced to, to make it easier to navigate/read (the mockup is above as well).

[SergeyBiryukov]

Adding the accessibility focus for the tooltips suggested in comment:7.

[joedolson]

If we want to add tooltips, we'll just need to land on an implementation for use in core. Related: #51006

[ZaneMatthew]

Theres existing help text providing guidance on the two links, along with a URL that leads to substantial detail regarding the difference (​https://wordpress.org/documentation/article/giving-wordpress-its-own-directory/) any additional text/tooltip/etc., would create documentation redundancy forcing us to maintain two areas of explanation. Ticket is marked as resolved.