WordPress.org

Make WordPress Core

Opened 4 years ago

Closed 4 years ago

#33621 closed defect (bug) (wontfix)

If FORCE_SSL_ADMIN is true, the scheme of the siteurl option should reflect this

Reported by: johnbillion Owned by:
Milestone: Priority: normal
Severity: normal Version: 3.0
Component: Administration Keywords: needs-patch dev-feedback
Focuses: Cc:
PR Number:

Description (last modified by johnbillion)

When FORCE_SSL_ADMIN is defined and set to true, the "WordPress Address (URL)" option on the General Settings screen still shows an http scheme unless the site was installed over https or the scheme was manually changed.

The siteurl option should either be filtered to show an https scheme, or be corrected to have an https scheme when the option is saved.

Change History (10)

#1 @thomaswm
4 years ago

wp_attachment_url() inherits the scheme from the siteurl, so this would probably bring back the problems described in #32112.

Some people use self-signed certificates for the admin backend. They want to force SSL on the admin area, but images should be embedded via HTTP on the frontend. That would not work if the Site URL had an HTTPS scheme.

#2 @johnbillion
4 years ago

This shouldn't affect wp_attachment_url(), and the tests that were added in [31614] should cover us.

#3 follow-up: @peterwilsoncc
4 years ago

I'm a little ambivalent on this, siteurl is a front end artefact and used by a number of resources as such.

What is the advantage of overriding the setting in the DB rather than when true === is_admin()?

#4 in reply to: ↑ 3 ; follow-up: @johnbillion
4 years ago

Replying to peterwilsoncc:

I'm a little ambivalent on this, siteurl is a front end artefact and used by a number of resources as such.

Can you provide some examples? If a resource is using siteurl (via get_option('siteurl') instead of home_url() or site_url()) then it's doing it wrong, and it's currently receiving a URL with an incorrect scheme anyway.

What is the advantage of overriding the setting in the DB rather than when true === is_admin()?

The main reason I'm proposing this is that it's possible for a user to change the scheme of the siteurl option on the General Settings screen anyway. This means that for sites with FORCE_SSL_ADMIN set to true, there's disparity between those with a siteurl option that has an https scheme and those with an http scheme.

#5 @johnbillion
4 years ago

In addition, a site which was installed over (and runs exclusively on) HTTPS contains an https scheme in its siteurl option. This is correct, and should be the case for all sites that use https for the admin area, regardless of the front end scheme.

#6 in reply to: ↑ 4 ; follow-up: @peterwilsoncc
4 years ago

Replying to johnbillion:

Can you provide some examples? If a resource is using siteurl (via get_option('siteurl') instead of home_url() or site_url()) then it's doing it wrong, and it's currently receiving a URL with an incorrect scheme anyway.

This is part of the reason for my ambivalence, the option's scheme is benign as it's overridden in site_url. Changing the value on save could confuse the user for no reason, especially if they expect home & site URLs to match.

What is the advantage of overriding the setting in the DB rather than when true === is_admin()?

The main reason I'm proposing this is that it's possible for a user to change the scheme of the siteurl option on the General Settings screen anyway. This means that for sites with FORCE_SSL_ADMIN set to true, there's disparity between those with a siteurl option that has an https scheme and those with an http scheme.

In addition, a site which was installed over (and runs exclusively on) HTTPS contains an https scheme in its siteurl option. This is correct, and should be the case for all sites that use https for the admin area, regardless of the front end scheme.

Both siteurl and homeurl are set to HTTPS in this instance, as it's benign I think consistent rules for both are more user friendly.

#7 in reply to: ↑ 6 ; follow-up: @johnbillion
4 years ago

  • Description modified (diff)

Just realised that I typo'd the field name in the ticket description. siteurl is represented by the "WordPress Address" field, not the "Site Address" field (yay naming).

Replying to peterwilsoncc:

Changing the value on save could confuse the user for no reason, especially if they expect home & site URLs to match.

Why would a user expect the URLs to match if FORCE_SSL_ADMIN is set to true but their home URL uses http? Displaying the incorrect scheme is the confusing behaviour.

Related: [28674]

#8 in reply to: ↑ 7 ; follow-up: @peterwilsoncc
4 years ago

Replying to johnbillion:

Why would a user expect the URLs to match if FORCE_SSL_ADMIN is set to true but their home URL uses http? Displaying the incorrect scheme is the confusing behaviour.

Related: [28674]

Because they changed it to match (HTTP) and the dashboard changed it back. I'm trying to think about how this affects the very new user, one that doesn't understand schemes.

The common install is for both the WordPress and site URL to match, the codex describes it as such:

The Site address (URL) is identical to the WordPress address (URL) (above) unless you are giving WordPress its own directory.

If the setting was admin URL, I'd feel differently about this.

#9 in reply to: ↑ 8 @dmchale
4 years ago

Replying to peterwilsoncc:

The common install is for both the WordPress and site URL to match, the codex describes it as such:

The Site address (URL) is identical to the WordPress address (URL) (above) unless you are giving WordPress its own directory.

If the setting was admin URL, I'd feel differently about this.

I have to agree with the logic here. FORCE_SSL_ADMIN is affecting /wp-admin but the WordPress Address field != the admin area, just the root of the WP installation.

#10 @johnbillion
4 years ago

  • Milestone Awaiting Review deleted
  • Resolution set to wontfix
  • Status changed from new to closed

I've been giving this some thought recently and I concur that altering this would result in the same problems that were introduced in [31614] and reverted in [32342].

Note: See TracTickets for help on using tickets.