Le problème : des iframes entièrement vides dans l’interface d’administration WordPress
Depuis mon passage à HTTPS, j’ai constaté que lorsqu’un plugin possédait une mise à jour et que l’on cliquait sur le lien “voir les détails de la version x.x”, j’avais droit à une jolie lightbox (ThickBox sous WordPress) toute vide.
C’était également le cas lors de la mise à jour des plugins, des thèmes ou de WordPress même : je n’obtenais jamais la ligne qui confirmait que le plugin avait bel et bien été réactivé.
Cette situation a duré des mois : j’ai d’abord soupçonné une mise à jour de WordPress qui aurait abimé un fichier donc j’ai ré-uploadé tous les fichiers, procédé à de multiples mises à jour mineures puis majeures.
J’ai ensuite jeté un œil aux plugins, en désactivant quelques uns pour essayer de trouver celui qui perturbait le système. Rien. Et visiblement, personne n’a jamais été confronté à ce problème sur la toile.
Et puis cette semaine, eurêka !
La solution : la configuration Apache du serveur
J’ai trouvé la solution un jour que je travaillais sur autre chose, en analysant les messages de l’inspecteur de code. Ce dernier me renvoyait de multiples avertissements lorsqu’un message a attiré mon attention :
Load denied by X-Frame-Options.... X-Frame-Options does not permit framing.Et là, banco, j’ai immédiatement compris ce qui clochait. Lors de la bascule vers la version chiffrée du site, j’avais effectivement ajouté un nouvel entête X-Frame-Options comme ceci :
Header always set X-Frame-Options DENYCode language: JavaScript (javascript)Cela est bien trop restrictif puisque la valeur DENY empêche l’affichage du site dans un cadre (frame).
Or le back-office de WordPress charge effectivement les messages relatifs aux mises à jour dans un cadre, sous la forme d’une lightbox: il faut donc utiliser la valeur SAMEORIGIN.
