Corriger le contenu mixte après le passage au HTTPS

Après l’ajout d’un certificat SSL, votre site se charge en https://, mais le navigateur peut encore indiquer « Non sécurisé », afficher un avertissement sur le cadenas ou ne pas charger certaines images et certains styles. Il s’agit généralement de contenu mixte : une page sécurisée qui charge encore certains fichiers en simple http://. Ce guide montre comment trouver ces restes dans WordPress et les remplacer. Il s’adresse aux propriétaires de sites qui viennent de passer leur site au HTTPS.

Qu’est-ce que le contenu mixte ?​

Une page servie en HTTPS est chiffrée. Si cette page charge ensuite une image, un script ou une feuille de style depuis une adresse http://, ce fichier circule sans chiffrement. Les navigateurs réagissent de deux façons :

• Les images, l’audio et la vidéo chargés en http:// sont généralement convertis automatiquement en https:// ou bloqués, et le cadenas peut afficher un avertissement.
• Les scripts, les feuilles de style et les cadres (frames) chargés en http:// sont bloqués, car ils pourraient modifier toute la page. C’est pourquoi un site peut perdre sa mise en page ou certaines fonctions après le passage au HTTPS.

La solution consiste à faire utiliser https:// à toutes les adresses du site.

Trouver le contenu mixte​

L’adresse vous indique où chercher. Un fichier situé dans wp-content/uploads provient généralement du contenu stocké dans la base de données. Un fichier situé dans wp-content/themes ou wp-content/plugins provient généralement d’un thème ou d’une extension. Un fichier sur un autre domaine provient d’un contenu intégré ou d’un service tiers.

Mettre à jour les adresses de WordPress​

Si ces champs sont grisés, les adresses sont définies dans wp-config.php avec WP_HOME et WP_SITEURL. Modifiez-les plutôt à cet endroit.

Remplacer les anciennes adresses dans la base de données​

Les articles, les pages, les widgets et de nombreux réglages d’extensions enregistrent des adresses complètes, comme des liens vers des images, dans la base de données. Changer l’adresse du site ne les met pas à jour.

Avec WP-CLI​

WP-CLI est l’outil officiel en ligne de commande de WordPress. Si votre hébergement vous donne un accès SSH et que WP-CLI y est installé, connectez-vous en SSH, allez dans le dossier de WordPress et lancez d’abord un test :

wp search-replace 'http://example.com' 'https://example.com' --skip-columns=guid --dry-run

--dry-run affiche le nombre de remplacements qui seraient faits dans chaque table, sans rien modifier. Si les chiffres semblent cohérents, relancez la même commande sans --dry-run. Si votre site utilisait aussi http://www.example.com, faites un second passage pour cette adresse.

--skip-columns=guid laisse la colonne guid intacte. WordPress l’utilise comme identifiant permanent des articles, pas comme un lien : elle ne doit donc pas être modifiée.

WP-CLI sait gérer les données sérialisées, un format que WordPress et les extensions utilisent pour enregistrer des réglages. C’est pourquoi vous ne devez jamais modifier les adresses dans la base de données avec un simple rechercher-remplacer de texte : changer la longueur d’une valeur sérialisée sans la mettre correctement à jour casse le réglage.

Avec une extension​

Sans SSH, utilisez une extension de rechercher-remplacer réputée et bien maintenue, issue du répertoire officiel des extensions, qui gère les données sérialisées et propose un essai à blanc. Utilisez-la de la même façon : testez d’abord, remplacez, puis désactivez et supprimez l’extension.

Corriger les adresses codées en dur dans les thèmes et les extensions​

Si la console affiche encore des fichiers http:// provenant de wp-content/themes ou wp-content/plugins, l’adresse est écrite dans le code ou dans les réglages.

• Vérifiez les réglages du thème dans Apparence, comme le logo, l’arrière-plan et les images d’en-tête, et choisissez l’image de nouveau.
• Vérifiez le CSS personnalisé ainsi que les blocs ou widgets HTML personnalisés à la recherche d’adresses http://.
• Si un fichier de thème ou d’extension contient une adresse http:// fixe, mettez d’abord à jour le thème ou l’extension. Si vous maintenez vous-même le code, remplacez l’adresse par https:// dans un thème enfant plutôt que dans les fichiers d’origine.
• Pour les contenus intégrés et les scripts tiers, remplacez http:// par https://. Si un service ne propose pas le HTTPS, remplacez-le ou retirez-le.

Rediriger tous les visiteurs vers le HTTPS​

Une fois que le site fonctionne en HTTPS, envoyez chaque visiteur http:// vers l’adresse sécurisée avec une redirection permanente. De nombreux hébergeurs proposent un réglage pour cela. Sur Apache, vous pouvez aussi ajouter ces lignes dans .htaccess, au-dessus du bloc # BEGIN WordPress :

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

Si votre site se trouve derrière un CDN ou un proxy, utilisez plutôt le réglage HTTPS de ce service, car cette règle risque de ne pas y détecter correctement le HTTPS. Consultez Redirections et .htaccess.

Enfin, videz le cache de votre extension de cache ou de votre CDN, et vérifiez de nouveau la console du navigateur.

Guides associés​

• Les certificats SSL expliqués
• Redirections et .htaccess
• Retrouver l’accès à l’administration WordPress