This was another fix that we needed to pursue when working with a site using a reverse proxy with WordPress.
The problem occurs since the originating site for the reverse proxy cannot be secured with an SSL. The final site will be secured with an SSL but all the functions that use the “is_ssl()” conditional for generating the default scheme are run on our originating site and will always return false.
This means that any plugin resources that correctly use the “set_url_scheme” for loading resources will be served via “http” on our final “https” site and cause mixed content warnings.
To get around this, we can filter the “set_url_scheme” function to force an “https” scheme on any URL that is processed through the reverse proxy. This snippet utilizes our reverse proxy conditional.
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| <?php | |
| add_filter( 'set_url_scheme', 'lc_force_secure_scheme', 10, 3 ); | |
| /** | |
| * Force all URLs run through the set_url_scheme to always be https if they're | |
| * being accessed through our reverse proxy. | |
| * | |
| * @param string $url The complete URL including scheme and path. | |
| * @param string $scheme Scheme applied to the URL. One of 'http', 'https', or 'relative'. | |
| * @param string|null $orig_scheme Scheme requested for the URL. One of 'http', 'https', 'login', | |
| * 'login_post', 'admin', 'relative', 'rest', 'rpc', or null. | |
| */ | |
| function lc_force_secure_scheme( $url, $scheme, $orig_scheme ) { | |
| if ( ! lc_is_reverse_proxy() ) | |
| return $url; | |
| $scheme = 'https'; | |
| $url = trim( $url ); | |
| if ( substr( $url, 0, 2 ) === '//' ) | |
| $url = 'http:' . $url; | |
| $url = preg_replace( '#^\w+://#', $scheme . '://', $url ); | |
| return $url; | |
| } |
