WordPress.org

Make WordPress Core

Opened 5 years ago

Closed 5 years ago

Last modified 4 months ago

#27499 closed defect (bug) (wontfix)

When creating new subdomain site, siteurl and home are set to http:// instead of https://

Reported by: tomdxw Owned by: johnbillion
Milestone: Priority: normal
Severity: normal Version: 3.8.1
Component: Networks and Sites Keywords: has-patch
Focuses: multisite Cc:

Description

If WP_HOME and WP_SITEURL are set to https://example.org shouldn't new sites be created with home and siteurl options set to https://site.example.org rather than http://site.example.org?

Attachments (1)

27499.diff (840 bytes) - added by johnbillion 5 years ago.

Download all attachments as: .zip

Change History (16)

#1 @SergeyBiryukov
5 years ago

  • Component changed from General to Networks and Sites
  • Focuses multisite added

#2 @johnbillion
5 years ago

  • Keywords has-patch added
  • Milestone changed from Awaiting Review to 4.0
  • Owner set to johnbillion
  • Status changed from new to accepted

27499.diff tackles this.

When installing the blog it sets the scheme of siteurl and home to match the network settings for siteurl and home respectively.

get_site_option() is used rather than network_site_url()/network_home_url() so things like filters and FORCE_SSL_ADMIN can be used without polluting the URLs.

Moving to 4.0 as part of our improvements to SSL support.

#3 @johnbillion
5 years ago

Oh this also depends on my patch on #28487.

@johnbillion
5 years ago

#4 @johnbillion
5 years ago

  • Keywords commit added

Refreshed patch.

My only slight hesitation on this change is that it affects the scheme used on site signups on open registration networks. If a network's home URL uses https then all new sites will use https. This may not be desired.

Anyone have thoughts on this? I think the benefit does outweigh this potentially unwanted change in behaviour.

#5 @tollmanz
5 years ago

My concern with this patch is that the assumption that subdomains of HTTPS root domains will use HTTPS could potentially lead to a blocked site. If HTTPS is automatically added to the URL, but TLS is not configured for the URL, most modern browsers will block the site due to a TLS configuration error. I'd rather error on the side of caution and make sure that the site is reachable when first set up.

While I agree that trying to add HTTPS in more places is a benefit, the potential of a broken site scares me.

Also, I noticed that get_blogaddress_by_id(), which generates the $url variable that is manipulated in the patch, hardcodes http into the URL path. If we go ahead with changing HTTP to HTTPS, should we address this at a lower level? Will we have more issues with the URL returning the wrong scheme in other parts of WP?

#6 @tollmanz
5 years ago

Related: #14867

#7 @jeremyfelt
5 years ago

  • Keywords dev-feedback added; commit removed

Agreed with tollmanz here. I don't think we can assume that subdomains or other root domains are SSL ready because the primary network domain is.

On our closed network, where we are not using a wildcard certificate, the workflow often includes configuring a new site before a cert has been requested, issued, and then applied to the server.

Additionally, individual sites may have content (e.g. imported from another site) that is not prepped to serve all assets with HTTPS on the front end while others on the network may be able to handle that fine.

As an aside. Outside of core, I'm working on a 3 stage process for sites where they can be checked off as non-SSL, admin-SSL, front-end SSL in the admin as they become ready. This is likely too complex for what we need, but it would be interesting if we could find the right way to mark each site with the level of SSL it supports.

#8 follow-ups: @johnbillion
5 years ago

  • Keywords dev-feedback removed
  • Milestone 4.0 deleted
  • Resolution set to wontfix
  • Status changed from accepted to closed

All good points. There's too much potential for broken sites here.

One thing we could look at in the future is an https checkbox (or scheme dropdown) in various places such as the Add New Site screen and the Edit Site screen.

#9 in reply to: ↑ 8 @tollmanz
5 years ago

Replying to johnbillion:

One thing we could look at in the future is an https checkbox (or scheme dropdown) in various places such as the Add New Site screen and the Edit Site screen.

+1 to this. I think we can play with the UI a bit to get the right UX. I wonder if we could even make an HTTP request to test if TLS is configured and fall back to HTTP if not.

#10 in reply to: ↑ 8 @jeremyfelt
4 years ago

Replying to johnbillion:

One thing we could look at in the future is an https checkbox (or scheme dropdown) in various places such as the Add New Site screen and the Edit Site screen.

See #14172

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


3 years ago

This ticket was mentioned in Slack in #core-http by thomaswm. View the logs.


3 years ago

This ticket was mentioned in Slack in #core-http by johnbillion. View the logs.


3 years ago

#14 @sc0ttkclark
20 months ago

If there was a filter in place for get_blogaddress_by_id(), you could change to https until such a point an arg is added to support setting the default. Any harm in adding a filter until the UI is tackled?

#15 @earnjam
4 months ago

#46407 was marked as a duplicate.

Note: See TracTickets for help on using tickets.