How to force static assets with HTTP sources to load over HTTPS?

5 comments

1. If assets are enqueued properly they are using the exact URL they are enqueued with. If the protocol in URL is hardcoded that causes mismatch issues you are seeing.

   For proper protocol support enqueued URLs need to be either:

   • created with protocol-aware API function from WP API (most if not all functions that produce URLs are)
   • using protocol-relative format like //example.com/stylesheet.css

   If you the links are coming from third party code you’ll have to unregister and re-register resource accordingly or (worst case scenario if queue is not used) rewrite the code / have original developer do it.

2. Here’s what I did to set up SSL for one of the clients.

   1: Put this into wp-config.php in order to enable SSL on the admin side.

   define('FORCE_SSL_ADMIN', true);
   define('FORCE_SSL_LOGIN', true);
   

   2: Make sure in Settings -> General the URL in both fields is preceeded by https://

   3: Put this snippet (modified from this tutorial) into functions.php in order for all the internal non-HTTPS links to be redirected to their HTTPS equivalents.

   function wpse_ssl_template_redirect() {
       if ( !is_ssl() ) {
           if ( 0 === strpos($_SERVER['REQUEST_URI'], 'http') ) {
               wp_redirect(preg_replace('|^http://|', 'https://', $_SERVER['REQUEST_URI']), 301 );
               exit();
           } else {
               wp_redirect('https://' . $_SERVER['HTTP_HOST'] . $_SERVER['REQUEST_URI'], 301 );
               exit();
           }
       }
   }
   
   add_action( 'template_redirect', 'wpse_ssl_template_redirect', 1 );
   

3. I would recommend editing the .htaccess file or creating one.

   Example including the default WordPress code:

   RewriteEngine On
   RewriteCond %{HTTPS} !=on
   RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE] 
   
   # BEGIN WordPress
   <IfModule mod_rewrite.c>
   RewriteEngine On
   RewriteBase /
   RewriteRule ^index.php$ - [L]
   RewriteCond %{REQUEST_FILENAME} !-f
   RewriteCond %{REQUEST_FILENAME} !-d
   RewriteRule . /index.php [L]
   </IfModule>
   # END WordPress
   

4. If you are using AWS Load Balancers with SSL Termination this is what I did:

   Assuming you have your AWS ELB configured to do SSL termination and forwarding traffic to your WordPress Target Group:

   On wp-config.php:

   define('WP_HOME','https://YOUR_WORDPRESS_WEBSITE');
   define('WP_SITEURL','https://YOUR_WORDPRESS_WEBSITE');
   
   // Update 8-April-2018: I moved https redirection from the Apache virtual server config to wp-config.php using this snippet.
   if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
      $_SERVER['HTTPS']='on';
   

   Source: https://blog.lawrencemcdaniel.com/wordpress-aws-elb-ssl/

5. Redirecting HTTP to HTTPS at the server-level (e.g. Nginx server block, or .htaccess if you’re using Apache-like servers) is always a good starting point for this.

   Likewise, if you’re using a proxy such as Cloudflare, you can also force redirect all requests to HTTPS within their SSL settings page. If you need to rewrite uncommon situations, such as some old http://cdn.example.com assets that your web server can’t manipulate, then you can use the Page Rules feature of Cloudflare and redirect those requests with such a rule:

   http://cdn.example.com/* >>> 301 REDIRECT >>> https://example.com/wp-content/$1
   

   But none of these solutions address the problem of hardcoded internal hyperlinks or static assets that might still be called over HTTP, with code like <script src="http://example.com/foo.js">

   Over time, your team will probably need to manually update such assets wherever they are loading from, whether it be in theme template files, posts and pages, etc. Search/replacing the database for the absolute URLs can also help a bit, but will still fail to fix hardcoded assets in template files, and might also miss serialized data strings in MySQL if you’re not paying attention.

   In most cases, force rewriting such “stubborn” assets requires a combination of on-the-fly javascript and/or targeting the enqueuing of these assets by WordPress. But, because so many web designers don’t follow best practices, it means that sometimes e.g. javascript is the only truly effective solution.

   This is what some free plugins do, actually, such as Force HTTPS (my team’s plugin, although it hasn’t been updated in a while) and several others.

Comments are closed.