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

[tomdxw]

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?

[johnbillion]

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.

[johnbillion]

Oh this also depends on my patch on #28487.

[johnbillion]

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.

[tollmanz]

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?

[tollmanz]

Related: #14867

[jeremyfelt]

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.

[johnbillion]

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.

[tollmanz]

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.

[jeremyfelt]

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

[sc0ttkclark]

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?

[earnjam]

#46407 was marked as a duplicate.

[johnbillion]

#49210 was marked as a duplicate.

[SergeyBiryukov]

#49992 was marked as a duplicate.

[mauricev2]

Are you aware that by doing it this way and all the sites in question are reachable via https, the browser will block the mixed content request and result in this obscure error:

"Publishing failed. You are probably offline."

[SergeyBiryukov]

Replying to mauricev2:

Are you aware that by doing it this way and all the sites in question are reachable via https, the browser will block the mixed content request and result in this obscure error:

"Publishing failed. You are probably offline."

Good catch! Yes, that error seems too generic and can happen for various reasons, that are generally support requests. We could probably display a better error for the mixed content issue.

Looks like it was already mentioned on GitHub, but not in the context of improving the message:
​https://github.com/WordPress/gutenberg/issues/23942

Maybe creating a new GitHub issue for improving the message in case of mixed content would be the way to go.

[SergeyBiryukov]

#52227 was marked as a duplicate.

[SergeyBiryukov]

#52248 was marked as a duplicate.

[kpetrilli]

Hi, I came here from #52248. Thanks @SergeyBiryukov for your reply :)
Is there a way to set the default protocol for new sites? Possibly by setting a variable on wp-config, or similar. That would be very cool and handy.
Right now, in order to have a new site fully functional, a string substitution on the database is required every time the protocol is changed. If not, issues like those I listed on #52248 might happen.