Opened 10 years ago
Last modified 5 years ago
#31405 assigned defect (bug)
upgrade.php fails with mixed HTTPS (SSL) and simple HTTP sites
Reported by: |
|
Owned by: | |
---|---|---|---|
Milestone: | Priority: | normal | |
Severity: | normal | Version: | 3.0 |
Component: | Upgrade/Install | Keywords: | https has-patch |
Focuses: | multisite | Cc: |
Description
upgrade.php fails with mixed HTTPS (SSL) and simple HTTP sites
The bug is discussed here
http://wordpress.stackexchange.com/questions/156642/how-to-use-wordpress-multisite-with-mixed-http-and-https-sites
I also add a patch that solves the SSL upgrade issue in my case.
Attachments (2)
Change History (22)
#2
@
10 years ago
It seems that the initial patch I made was only a workaround for a much deeper issue. As my knowledge of Wordpress internals are not so good here are some findings:
It seems that switch_to_blog doesn't do a proper job because only one URL function will return the correct value after calling the switch_to_blog.
switch_to_blog( $details['blog_id'] ); $siteurl = site_url(); // will return a bad URL by using the scheme of multisite $z = get_bloginfo('wpurl'); // will return a bad URL using the scheme of multisite $y = get_option('siteurl'); // will return correct URL with the proper scheme, as the one stored in side the database
#3
@
10 years ago
- Keywords dev-feedback has-patch added
- Owner set to dd32
- Status changed from new to assigned
@dd32: Mind taking a look at this?
#5
@
10 years ago
- Keywords dev-feedback has-patch removed
- Version changed from trunk to 3.0
I'm not entirely sure that this should be treated as a bug. Though from experience, it can be pretty annoying.* :)
During the upgrade loop, WordPress looks for the site's stored site_url
. It then uses is_ssl()
via set_url_scheme()
to determine if the URL should be accessed via HTTPS. is_ssl()
determines this based on the current page load only, not the page load that would occur if you had requested the site to be upgraded on its own.
set_url_scheme
is available as a filter here, which would allow you to make the manual decision per domain to use HTTP for an upgrade URL even if the current page load is HTTPS. The admin_url
and site_url
filters could be used as well.
For this to be handled at the core level, we would probably need to introduce an option separate from site_url
that tracked whether a site supported HTTPS. This seems like an outlier scenario, though there are some other tickets floating around with similar issues.
*I manage this through a custom admin interface while waiting for pending cert approvals.
#11
in reply to:
↑ 1
@
9 years ago
Replying to SergeyBiryukov:
We could use set_url_scheme() instead of
str_replace()
.
Since I just detected this ticket, I wanted to mention that I have created a patch using set_url_scheme()
as an attachment in the duplicate ticket #33887 (see https://core.trac.wordpress.org/ticket/33887#comment:5). I wonder what you think about it.
Regardless, I agree that using this function will be a better solution than an "upgrade only" solution because this issue, at least to me, is a general issue which does not only happen on upgrades, but rather everytime you switch sites and then call one of those URL functions.
#13
@
9 years ago
I just stumbled on this problem when upgrading from 4.4.2 to 4.5. The error message I am getting when upgrading my FORCE_SSL_ADMIN multisite is "Peer's Certificate issuer is not recognized". After looking around, I found that wordpress has its own ca-bundle.txt, and does not use the system ca certificate bundle.
After appending my CA certificate to wp-includes/certificates/ca-bundle.crt, upgrading network works flawlessly. I am afraid it might not be a bug.
This ticket was mentioned in Slack in #core-multisite by jeremyfelt. View the logs.
9 years ago
#15
@
9 years ago
- Keywords has-patch added
31405.diff is an approach to fix this problem. It introduces a new possible $scheme
value for set_url_scheme()
. This value is called original
and will keep the original scheme of the URL. Every site should have its current scheme stored in the home
and siteurl
options, so we can rely on that to fix the error.
We could use set_url_scheme() instead of
str_replace()
.