Cum să forțezi resursele statice cu surse HTTP să se încarce prin HTTPS?

Dacă resursele sunt încărcate corect, ele folosesc exact URL-ul cu care au fost înregistrate. Dacă protocolul din URL este hardcodat, aceasta poate cauza probleme de nepotrivire pe care le observați.

Pentru o suportare corectă a protocolului, URL-urile încărcate trebuie să fie fie:

• create cu funcții API din WordPress care sunt conștiente de protocol (majoritatea, dacă nu toate funcțiile care produc URL-uri sunt)
• folosind formatul relativ la protocol, precum //exemplu.com/stylesheet.css

Dacă link-urile provin din codul unei terțe părți, va trebui să dezînregistrați și să reînregistrați resursa în consecință sau (în cel mai rău caz, dacă coada nu este utilizată) să rescrieți codul / să solicitați dezvoltatorului original să o facă.

Dacă utilizați AWS Load Balancers cu SSL Termination, iată ce am făcut eu:

Presupunând că aveți AWS ELB configurat să facă terminare SSL și să direcționeze traficul către grupul țintă Wordpress:

În wp-config.php:

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

// Actualizare 8-Aprilie-2018: Am mutat redirecționarea https din configurația virtual server Apache în wp-config.php folosind acest fragment de cod.
if (strpos($_SERVER['HTTP_X_FORWARDED_PROTO'], 'https') !== false)
   $_SERVER['HTTPS']='on';

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

Iată ce am făcut pentru a configura SSL pentru unul dintre clienți.

1: Am adăugat acest cod în wp-config.php pentru a activa SSL în partea de administrare.

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

2: Asigurați-vă că în Setări -> Generale URL-ul din ambele câmpuri începe cu https://.

3: Am introdus acest fragment de cod (modificat după acest tutorial) în functions.php pentru a redirecționa toate linkurile interne non-HTTPS către echivalentele lor 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 );

Aș recomanda editarea fișierului .htaccess sau crearea unuia.

Exemplu care include codul implicit WordPress:

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

Redirecționarea HTTP către HTTPS la nivel de server (de exemplu, în blocul serverului Nginx sau în fișierul .htaccess dacă utilizați servere de tip Apache) este întotdeauna un punct de plecare bun pentru această problemă.

De asemenea, dacă utilizați un proxy precum Cloudflare, puteți forța redirecționarea tuturor cererilor către HTTPS din pagina lor de setări SSL. Dacă trebuie să rescrieți situații neobișnuite, cum ar fi unele resurse vechi de tip http://cdn.example.com pe care serverul dvs. web nu le poate manipula, atunci puteți utiliza funcția Page Rules din Cloudflare și să redirecționați acele cereri cu o regulă de genul:

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

Dar niciuna dintre aceste soluții nu rezolvă problema legăturilor interne hardcodate sau a resurselor statice care încă pot fi încărcate prin HTTP, cu cod de tipul <script src="http://example.com/foo.js">.

Cu timpul, echipa dvs. va trebui probabil să actualizeze manual astfel de resurse oriunde acestea sunt încărcate, fie în fișierele de șablon ale temei, în articole sau pagini etc. Căutarea/înlocuirea URL-urilor absolute în baza de date poate ajuta parțial, dar tot nu va repara resursele hardcodate în fișierele de șablon și ar putea să rateze și șirurile de date serializate în MySQL dacă nu acordați atenție.

În majoritatea cazurilor, rescrierea forțată a acestor resurse „încăpățânate” necesită o combinație de javascript executat din mers și/sau direcționarea încărcării acestor resurse prin intermediul WordPress. Dar, deoarece mulți designeri web nu urmează cele mai bune practici, uneori javascript este singura soluție cu adevărat eficientă.

Aceasta este de fapt ceea ce fac unele pluginuri gratuite, cum ar fi Force HTTPS (pluginul echipei mele, deși nu a fost actualizat de ceva timp) și multe altele.