web-dev-qa-db-fra.com

SSL rompt le personnaliseur: la page n'est pas renvoyée par ajax

J'ai une installation WordPress utilisant un certificat SSL Comodo. J'ai le plugin WordPress HTTPS installé et j'utilise le thème AZ, et l'administrateur est configuré pour se charger via HTTPS. Jusqu'ici tout va bien.

Sur le personnalisateur de thème, je reçois une icône de chargement perpétuel (à ne pas confondre avec un WSOD). L'appel AJAX qui ramène le contenu de la page d'accueil est vide, à l'exception du jeton WP_CUSTOMIZER_SIGNATURE. C'est tout ce que la réponse comprend. Lorsque je désactive le plugin WordPress HTTPS (ou que je désactive le chargement de l'administrateur via SSL), le personnalisateur fonctionne parfaitement. Désactiver/activer d'autres plugins n'a aucun effet. Cela se produit également avec le thème Twenty Fifteen (illustré ci-dessous).

Voici une capture d'écran de ce que je vois dans Firebug (et qui est reproductible sur les navigateurs, ainsi que sur les ordinateurs virtuels de Browserstack):

Screenshot of Firebug console in customizer view

Le cas échéant, le site est hébergé sur un droplet DigitalOcean, à l'aide de ServerPilot. J'ai d'autres sites WordPress hébergés sur le même droplet, et l'autre, compatible SSL, présente le même comportement. ModSecurity n'est pas installé, à ma connaissance, et j'obtiens un code d'état 200, donc je ne pense pas que ce soit ce problème .

En outre, la messagerie SHA-1 semble être un faux positif, pour autant que je sache (et je ne pense pas que Firefox est encore sur le point de bloquer le contenu basé sur l'utilisation de SHA-1 de toute façon?). Je ne pense pas que ce soit zlib.output_compression bug non plus, car je l’ai explicitement désactivé pour tester et tenter le correctif indiqué dans ce ticket, qui ne fonctionnait pas.

Je n'ai rien trouvé qui corresponde parfaitement à mon problème, ce qui me fait penser qu'il y a quelque chose de stupide que j'ai négligé. Toute aide est grandement appréciée, et merci de me faire savoir quelles informations supplémentaires peuvent être utiles.

ajaxtheme-customizersslhttps
6
Kelly Carter

Sur la base de votre question, je suppose que c’est le plug-in que vous utilisez pour activer SSL: WordPress HTTPS .

Étant donné que le plug-in n'a pas été mis à jour depuis deux ans et que ses questions d'assistance n'ont pas été résolues, il est possible que des problèmes de compatibilité se posent avec la dernière version de WordPress (4.6 au moment de la rédaction de cet article). Ma recommandation pour m'assurer que l'URL de votre site Web exécute HTTPS partout.

Cela peut être fait en exécutant la requête SQL suivante dans votre base de données ( phpMyAdmin ):

UPDATE wp_options SET option_value = replace(option_value, 'HTTP_URL', 'HTTPS_URL') WHERE option_name = 'home' OR option_name = 'siteurl';
UPDATE wp_posts SET guid = replace(guid, 'HTTP_URL','HTTPS_URL');
UPDATE wp_posts SET post_content = replace(post_content, 'HTTP_URL', 'HTTPS_URL');
UPDATE wp_postmeta SET meta_value = replace(meta_value,'HTTP_URL','HTTPS_URL');

Remplacez les valeurs par les suivantes:

  • HTTP_URL> votre lien HTTP (http://some.site)
  • HTTPS_URL votre lien HTTPS (https://some.site)

De cette façon, il empêche tout lien mixte contenu de casser des choses. J'ai également trouvé un fil de discussion WordPress présentant un problème similaire et je ne sais pas si vous l'avez déjà examiné:

Problème de personnalisation de thème

1
Ethan Jinks O'Sullivan

ANSWER: cela est dû à une incohérence dans vos URL globales

Je suppose qu'à un moment donné, le personnaliseur de chaîne de votre plugin ne reconnaît pas certains éléments toujours appelés via http au lieu de https vous pouvez faire ce qui suit.

  1. Installez un plugin appelé WP Migrate DB
  2. Une fois installé et activé, allez dans Outils -> Migrer la base de données
  3. La nouvelle URL doit être la même, et donc le chemin du fichier.
  4. Téléchargez la sauvegarde (pourquoi vous ai-je dit cela au lieu d'exporter directement votre phpmyadmin ou vos dbms?, Car c'est un moyen plus sûr d'obtenir ces informations, c'est tout, dans l'exportation, vous pouvez éviter certaines sauvegarde "une méthode de preuve d'erreur).
  5. Enregistrez-le dans un répertoire spécifique, seul, en une copie non compressée.
  6. Dans terminal allez dans ce répertoire et exécutez la commande suivante:

Sudo find . -type f -name '*.sql' -exec sed -i '' s,http://yoursite,https://yoursite,g {} +

  1. Téléchargez le nouveau fichier en l'important sur votre phpmyadmin ou votre dbms web.

  2. L'erreur doit avoir disparu.

IMPORTANT.

Au cas où cela ne fonctionnerait pas, vous avez votre copie intacte restante de l’étape 5.

INFORMATIONS COMPLEMENTAIRES . Avez-vous vérifié que l'URL racine du site Web commence par https au lieu de http?

Vous pouvez vérifier cela dans Paramètres -> Général

Adresse WordPress (URL)

Adresse du site (URL)

Bonne chance.

0
luis