Come forzare il caricamento delle risorse statiche con sorgenti HTTP tramite HTTPS?

Se gli asset vengono accodati correttamente, utilizzano esattamente l'URL con cui sono stati accodati. Se il protocollo nell'URL è hardcodato, ciò causa i problemi di mancata corrispondenza che stai riscontrando.

Per un corretto supporto del protocollo, gli URL accodati devono essere:

• creati con funzioni API di WordPress che tengono conto del protocollo (la maggior parte, se non tutte, le funzioni che producono URL lo fanno)
• utilizzare il formato relativo al protocollo come //example.com/stylesheet.css

Se i link provengono da codice di terze parti, dovrai annullare la registrazione e registrare nuovamente la risorsa di conseguenza o (nel peggiore dei casi se la coda non viene utilizzata) riscrivere il codice / far sì che lo sviluppatore originale lo faccia.

Se stai utilizzando i bilanciatori di carico AWS con terminazione SSL, ecco cosa ho fatto:

Supponendo che tu abbia configurato il tuo ELB AWS per gestire la terminazione SSL e inoltrare il traffico al tuo Target Group Wordpress:

Su wp-config.php:

define('WP_HOME','https://YOUR_WORDPRESS_WEBSITE');
define('WP_SITEURL','https://YOUR_WORDPRESS_WEBSITE');

// Aggiornamento 8-Aprile-2018: Ho spostato il reindirizzamento HTTPS dalla configurazione del server virtuale Apache a wp-config.php utilizzando questo snippet.
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
   $_SERVER['HTTPS']='on';

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

Ecco cosa ho fatto per configurare SSL per uno dei clienti.

1: Ho inserito questo nel file wp-config.php per abilitare SSL nella parte amministrativa.

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

2: Assicurarsi che in Impostazioni -> Generali l'URL in entrambi i campi sia preceduto da https://

3: Ho inserito questo snippet (modificato da questo tutorial) nel file functions.php per reindirizzare tutti i link interni non-HTTPS alle loro versioni HTTPS.

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 );

Ti consiglio di modificare il file .htaccess o di crearne uno nuovo.

Esempio incluso il codice predefinito di WordPress:

RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301,NE] 

# INIZIO 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>
# FINE WordPress

Reindirizzare HTTP a HTTPS a livello di server (ad esempio nel blocco del server Nginx, o nel file .htaccess se utilizzi server di tipo Apache) è sempre un buon punto di partenza.

Allo stesso modo, se utilizzi un proxy come Cloudflare, puoi forzare il reindirizzamento di tutte le richieste a HTTPS dalla pagina delle impostazioni SSL. Se hai bisogno di riscrivere situazioni meno comuni, come alcuni vecchi asset http://cdn.example.com che il tuo server web non può manipolare, puoi utilizzare la funzionalità Page Rules di Cloudflare e reindirizzare quelle richieste con una regola come questa:

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

Ma nessuna di queste soluzioni risolve il problema dei link interni hardcoded o degli asset statici che potrebbero ancora essere richiamati tramite HTTP, con codice come <script src="http://example.com/foo.js">

Con il tempo, il tuo team dovrà probabilmente aggiornare manualmente tali asset ovunque siano caricati, che si tratti di file template del tema, post e pagine, ecc. Sostituire tramite ricerca nel database gli URL assoluti può aiutare un po', ma non risolverà gli asset hardcoded nei file template e potrebbe anche mancare stringhe di dati serializzati in MySQL se non fai attenzione.

Nella maggior parte dei casi, forzare la riscrittura di questi asset "ostinati" richiede una combinazione di javascript on-the-fly e/o il targeting del caricamento di questi asset da parte di WordPress. Ma, poiché molti web designer non seguono le best practice, a volte significa che ad esempio javascript è l'unica soluzione veramente efficace.

Questo è ciò che fanno alcuni plugin gratuiti, come Force HTTPS (il plugin del mio team, anche se non è stato aggiornato da un po') e diversi altri.