Make WordPress Core

Opened 4 years ago

Last modified 8 weeks ago

#31405 reopened defect (bug)

upgrade.php fails with mixed HTTPS (SSL) and simple HTTP sites

Reported by: intersol Owned by:
Milestone: Awaiting Review Priority: normal
Severity: normal Version: 3.0
Component: Upgrade/Install Keywords: https, has-patch, bulk-reopened
Focuses: multisite Cc:


upgrade.php fails with mixed HTTPS (SSL) and simple HTTP sites

The bug is discussed here

I also add a patch that solves the SSL upgrade issue in my case.

Attachments (2)

network_upgrade_ssl.patch (984 bytes) - added by intersol 4 years ago.
31405.diff (2.5 KB) - added by flixos90 3 years ago.
fix using set_url_scheme()

Download all attachments as: .zip

Change History (24)

#1 follow-up: @SergeyBiryukov
4 years ago

  • Component changed from General to Upgrade/Install

We could use set_url_scheme() instead of str_replace().

#2 @intersol
4 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 @DrewAPicture
4 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?

#4 @dd32
4 years ago

  • Owner dd32 deleted

#5 @jeremyfelt
4 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.

#7 @jeremyfelt
4 years ago

Related #14172 for a scheme option.

#8 @here
4 years ago

Related to #26056 -- Database is not upgraded in multisite if loopback is disabled

#9 @johnbillion
3 years ago

  • Keywords https added

#10 @thomaswm
3 years ago

I think this is a duplicate of #33887.

#11 in reply to: ↑ 1 @flixos90
3 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.

#12 @johnbillion
3 years ago

#33887 was marked as a duplicate.

#13 @wenzhuo
3 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.

3 years ago

3 years ago

fix using set_url_scheme()

#15 @flixos90
3 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.

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

3 years ago

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

3 years ago

#18 @jeremyfelt
3 years ago

#33887 was marked as a duplicate.

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

3 years ago

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

2 years ago

#21 @iseulde
4 months ago

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

This ticket has not seen any activity in over *two* years, so I'm closing it as "wontfix".

The ticket may lack decisiveness, may have become irrelevant, or may not have gathered enough interest.

If you think this ticket does deserve some attention again, feel free to reopen.

For bugs, it would be great if you could provide updated steps to reproduce against the latest version of WordPress (5.0.2 at the time of writing). Remember images or a video can be superior to explain a problem. At the very least, quickly test again to make sure the bug still exists.

If it’s an enhancement or feature, some extra motivation may help.

Thank you for your contributions to WordPress! <3

#22 @JeffPaul
8 weeks ago

  • Keywords bulk-reopened added
  • Milestone set to Awaiting Review
  • Resolution wontfix deleted
  • Status changed from closed to reopened

A decision was made to reopen tickets that were closed in the bulk edit that this ticket was affected by. This ticket is being placed back into the Awaiting Review milestone so it can be individually evaluated and verified to determine if it is still relevant/valid or reproducible.

Note: See TracTickets for help on using tickets.