Opened 15 years ago
Last modified 4 years ago
#14172 assigned enhancement
Implement $scheme in site info in ms-sites edit site
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.0 |
Component: | Networks and Sites | Keywords: | needs-patch dev-feedback https |
Focuses: | multisite | Cc: |
Description
In WordPress 3.0 with Network enabled, if you were to click:
Super Admin -> Sites -> Edit (next to any site) and then change any of the Site Options i.e. wp_2_options the changes don't save.
We're running a secure environment and need Siteurl to be HTTPS instead of HTTP. Changing all the parameters to https and clicking Update doesn't save the changes.
Change History (30)
#1
@
15 years ago
- Component changed from Administration to Multisite
- Keywords needs-patch added
- Milestone changed from Awaiting Review to Future Release
- Severity changed from major to normal
- Type changed from defect (bug) to enhancement
#2
@
15 years ago
- Summary changed from Updating Site Options to Implement $scheme in site info in ms-sites edit site
#5
@
10 years ago
- Milestone changed from Future Release to 4.3
Considering this as part of the UI in #22383 would be a good idea.
This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.
10 years ago
#7
@
10 years ago
- Keywords dev-feedback added
Where does it make the most sense for scheme to live as part of a site's information?
- A new
enum( 'http', 'https' )
field inwp_blogs
? - An option?
get_option( 'scheme' );
I like the first, because it attaches the scheme directly to the site when we look things up during load. We can default to HTTP. The tough part is establishing the scheme for existing sites. The upgrade process could look at existing siteurl
/home
options to establish a good guess. FORCE_SSL_
constants would overwrite any scheme data from the table. A WP_Network()
object could fill its scheme
property based on its main site's WP_Site
object.
An option wouldn't require a DB schema change, which is probably good for large networks. It would be more expensive to establish a site's scheme for $current_blog
(or WP_Site
) when using something like switch_to_blog()
.
This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.
10 years ago
This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.
10 years ago
This ticket was mentioned in Slack in #core by jeremyfelt. View the logs.
10 years ago
This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.
10 years ago
This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.
10 years ago
#14
@
10 years ago
- Milestone changed from 4.3 to Future Release
There will be a lot of other moving parts when this becomes reality. It should happen earlier in the cycle, so I'll try to drum up some interest pre 4.4.
#16
in reply to:
↑ description
;
follow-up:
↓ 17
@
9 years ago
Replying to firmdot:
In WordPress 3.0 with Network enabled, if you were to click:
Super Admin -> Sites -> Edit (next to any site) and then change any of the Site Options i.e. wp_2_options the changes don't save.
This is no longer the case. In WordPress 4.3, you can set the siteurl to a HTTPS URL in wp-admin/network/site-info.php
. When clicking the save button, the changes are applied to both the site URL and the home URL.
When creating a new site in wp-admin/network/site-new.php
, however, the scheme of the site URL and home URL is always HTTP, even if the main site's site URL and home URL are HTTPS URLs. So there is no possibility to set the scheme of new sites upon creation.
This ticket was mentioned in Slack in #core by sergey. View the logs.
9 years ago
#20
@
9 years ago
- Milestone changed from 4.4 to Future Release
- Owner jeremyfelt deleted
I'm no longer confident that tracking scheme in the database is the right answer after a conversation in Slack yesterday. Moving this back to future-release for more thought.
This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.
9 years ago
#23
follow-up:
↓ 26
@
9 years ago
- Keywords changed from needs-patch, dev-feedback, https to needs-patch dev-feedback https
I just looked at this again, and it appears to be fixed to me (unless I didn't get the point of the discussion in this ticket). I don't think we need to save the scheme of a site in an additional field since it's already present in the home
and siteurl
options.
I tried both changing the URL under "Site Info" and change home
and siteurl
individually under "Site Settings" - both changed the scheme accordingly.
This ticket was mentioned in Slack in #core-multisite by flixos90. View the logs.
9 years ago
This ticket was mentioned in Slack in #core-http by johnbillion. View the logs.
8 years ago
#26
in reply to:
↑ 23
@
8 years ago
Replying to flixos90:
I just looked at this again, and it appears to be fixed to me
You're right. Originally, the ticket was about not being able to set the Site URL and home URL to https. That is now possible, probably since #22383.
I tried both changing the URL under "Site Info" and change
home
andsiteurl
individually under "Site Settings" - both changed the scheme accordingly.
I have confirmed this on WordPress 4.6.1 multisite (subdirectory install with Domain Mapping).
#27
@
8 years ago
The site settings page should do a much better job of detecting scheme changes and applying them to both URLs.
One of the "ideal" things I started to look for in this ticket was a single place to use as an indicator of HTTPS support for a site. After going around in circles a few times, it seems that any new indicator (DB field) would really just be another iteration on what's already available as part of the home or site URL.
Really, as long as we pick one of them as our source and document that, then we should be okay to close this out.
There is an update siteurl and home checkbox in the site info metabox that you need to uncheck to change the siteurl & home options.
Having said that, we should look at implementing $scheme for the site info in 3.1.