Le mail du client fait deux lignes et signale deux problèmes : le site WordPress semble réclamer une mise à jour de PHP (il est hébergé chez OVH), et l’extension Slider Revolution ne fonctionne plus. Le client demande si je peux intervenir.
Le premier point est une affaire d’hébergement, il se règle dans le manager de l’hébergeur, et il ne se pose même pas quand l’hébergement a été choisi correctement au départ. Le second m’a pris presque trois heures, entre comprendre ce qui est réellement installé sur ce site, faire des tests et finir par trouver le bug, quatre fausses pistes au passage, dans le code source de l’extension. C’est celui que je raconte, parce que Slider Revolution ne s’affiche pas est exactement le type de panne qui ne laisse aucune trace : pas d’erreur PHP, pas d’erreur dans le journal, pas de page blanche, juste un rectangle gris en haut de la page d’accueil. Et pendant qu’on cherche, le site reste en ligne et répond 200 à tout le monde, ce qui est précisément ce qui rend la chose pénible. Si vous préférez que ce genre de recherche soit menée par quelqu’un d’autre, c’est l’objet de la maintenance WordPress.
Slider Revolution, si vous ne connaissez pas. C’est une extension WordPress commerciale, éditée par ThemePunch, qui sert à construire des diaporamas et des en-têtes animés calque par calque, dans un éditeur visuel. L’éditeur revendique plus de 9 millions d’utilisateurs, et une bonne partie d’entre eux ne l’ont jamais choisie : elle est fournie avec quantité de thèmes premium vendus sur ThemeForest, dont The7, le thème de ce site. C’est le point qui compte pour la suite, parce qu’une extension qui arrive avec le thème suit le calendrier de mises à jour du thème, et non le vôtre.
Ce que voit le visiteur quand Slider Revolution ne s’affiche pas
À l’emplacement du diaporama, un rectangle gris et vide. Le reste de la page, construit avec WPBakery, s’affiche normalement, et le visiteur voit donc un site presque normal avec un trou en haut.
La console du navigateur ne dit rien sur la page d’accueil. Le code source montre que les fichiers de l’extension sont bien servis, revslider/public/js/sr7.js en version 6.7.58, donc l’extension est active et chargée. En cherchant les conteneurs du slider dans le DOM, je passe à côté : je cherche les anciens noms (rs-module, rev_slider) alors que la version 7 du moteur produit un sr7-module. Première fausse piste, et elle m’envoie chercher du côté de la configuration.
Côté serveur, même silence. Le journal de débogage activé dans wp-config.php reste vide après un rechargement de la page :
define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); @ini_set( 'display_errors', 0 );
Aucune erreur fatale, seulement des avertissements ou notices sans importance.
Les fausses pistes que tout le monde suit d’abord
La licence expirée. C’est la première chose qu’on suspecte sur une extension premium, et c’est faux : une licence Slider Revolution désactivée bloque les mises à jour automatiques et la bibliothèque de modèles dans l’administration, elle n’empêche pas le rendu des sliders existants côté visiteur. De toute façon, Slider Revolution est souvent inclus avec certains thèmes premium, ce qui était le cas ici.
Le doublon d’extension. Le fichier revslider.php contient un garde-fou explicite qui interrompt le chargement si une autre instance de l’extension est déjà présente, ce qui arrive quand un thème premium embarque sa propre copie. Vérification faite dans les fichiers du thème The7 en version 14.4.8 : aucune classe RevSliderFront n’y est définie, le thème installe l’extension normalement et n’en embarque pas de second exemplaire. Piste écartée.
L’extension compagnon manquante. Dans l’écran des extensions du thème, The7 Elements apparaît en « Not Installed », et comme c’est lui qui fournit les éléments WPBakery propres au thème, l’explication paraissait solide. Elle ne l’est pas : le diaporama de cette page n’est pas inséré par WPBakery. Il est déclaré dans un champ natif du thème, _dt_slideshow_revolution_slider, réglé sur le slider « home », avec un _dt_header_title réglé sur slideshow. La configuration est donc correcte de bout en bout, le slider existe toujours en base, et la page pointe bien dessus.
La mise à jour du thème. Elle a bien précédé la panne, ce qui en fait la coupable naturelle. Sauf que le code du thème, lui, fait exactement ce qu’on lui demande.
Ce que fait le thème, et ce qu’il ne fait pas
Dans inc/template-hooks.php, la fonction qui produit le diaporama est brève :
case 'revolution':
$rev_slider = $config->get( 'slideshow_revolution_slider' );
if ( $rev_slider && function_exists( 'putRevSlider' ) ) {
echo '<div id="main-slideshow">';
putRevSlider( $rev_slider );
echo '</div>';
}
break;
Le thème n’écrit même pas son conteneur si la fonction putRevSlider() de l’extension n’existe pas, ce qui explique pourquoi une extension absente ne laisserait aucune trace dans la page. Mais ici la fonction existe, le <div id="main-slideshow"> est bien présent dans la page, et il contient bien le <sr7-module> attendu. Le HTML est correct. Le problème est donc ailleurs, et il est côté navigateur.
ReferenceError: auto is not defined, la vraie cause est dans sr7.js
Dans la console, sur la page d’accueil :
TypeError: Cannot read properties of undefined (reading 'attr') at SR7.F.getLayer.SR7.F.prepareLayers (sr7.js) at SR7.F.drawSlideProc (sr7.js)
Le <sr7-module> est un composant web, qui n’a d’existence que si sr7.js va jusqu’au bout de son exécution pour l’enregistrer. Ici le script s’arrête en route, le composant n’est jamais déclaré, le navigateur laisse donc dans la page une balise qu’il ne sait pas rendre, et il réserve la place. Le rectangle gris, c’est ça.
Reste à savoir pourquoi le script s’arrête. Plutôt que de toucher au slider existant, je crée un slider neuf et vide, uniquement pour l’aperçu. Il ne rend rien non plus, avec une erreur différente et bien plus parlante :
ReferenceError: auto is not defined
at Object.fn (admin.php?page=revslider&view=slide&id=42)
at SR7.F.init (sr7.js)
Un slider vide, tout neuf, qui ne rend rien : ce n’est plus une histoire de données migrées de travers, c’est l’initialisation du moteur elle-même. Et auto is not defined, en JavaScript, signifie qu’on a écrit le mot auto sans guillemets là où on attendait la chaîne "auto".
Le coupable est dans revslider/includes/output.sr7.class.php, lignes 1269 et 1270 :
$html .= "gh:[". esc_attr($csizes['height']) ."],"; $html .= "gw:[". esc_attr($csizes['width']) ."],";
$csizes['height'] et $csizes['width'] contiennent les hauteurs et largeurs du slider pour chaque point de rupture responsive, assemblées plus haut dans le même fichier par un implode(',', ...) qui n’entoure jamais les valeurs de guillemets. Or auto est une valeur parfaitement légitime pour la hauteur d’un diaporama qui s’adapte à son contenu, et c’est le réglage par défaut d’un slider neuf. Le script produit alors littéralement gh:[auto,auto,auto,auto,auto],, du JavaScript invalide, et le moteur s’interrompt à l’initialisation avant même d’arriver aux calques.
Trente lignes plus bas dans le même fichier, la valeur équivalente pour la hauteur minimale est écrite correctement, avec ses guillemets : mh:'".esc_attr($mheight)."',. C’est donc un oubli, pas un choix, et il concerne la version 6.7.58 de l’extension. La mise à jour du thème n’était pour rien dans l’affaire, elle a simplement amené la mise à jour de l’extension avec elle.
Le correctif, et pourquoi il ne dure pas
Les deux lignes deviennent :
$gh_vals = array_map(function($v){ return "'".esc_attr(trim($v))."'"; }, explode(',', $csizes['height']));
$html .= "gh:[". implode(',', $gh_vals) ."],";
$gw_vals = array_map(function($v){ return "'".esc_attr(trim($v))."'"; }, explode(',', $csizes['width']));
$html .= "gw:[". implode(',', $gw_vals) ."],";
Chaque valeur est entourée de guillemets, auto comme les nombres, et le code qui consomme ensuite ces valeurs fait déjà un parseFloat(), donc les nombres passés en chaîne ne changent rien. Le diaporama est revenu du premier coup.
ATTENTION : c’est un fichier de l’extension, pas du thème. La prochaine mise à jour de Slider Revolution l’écrasera, et le diaporama disparaîtra de nouveau, un matin, sans que personne ne fasse le lien avec la mise à jour de la veille. Un correctif de ce type se note quelque part et se signale à l’éditeur, sinon la panne reviendra sans prévenir.
Ce qu’on en retient pour la suite
Un site en production n’a rien à faire au bout d’une mise à jour d’extension premium non testée, surtout quand cette extension arrive dans les bagages d’un thème. Le calendrier des mises à jour du thème n’est pas le vôtre, celui de ses extensions embarquées encore moins, et une version majeure de WordPress ajoute sa propre couche de régressions possibles. Une copie du site, la mise à jour dessus, un coup d’œil sur les pages qui comptent, et vous savez avant vos visiteurs.
L’autre leçon est plus désagréable : la supervision HTTP ne voit rien de tout ça. Le serveur répond 200, la page fait son poids habituel, les sondes sont vertes, et pourtant le diaporama a disparu de la page d’accueil sans que rien ne le signale. C’est le même angle mort que sur un WordPress piraté qui continue de servir ses pages, ou sur une extension qui expose des clés sans rien signaler. Ce qui rattrape ces cas, ce n’est pas une sonde de plus, c’est quelqu’un qui regarde le site et qui sait lire une console.
Si vous avez un site dans cette situation, avec un thème premium acheté il y a des années, une pile d’extensions sous licence et personne pour arbitrer les mises à jour, écrivez-moi via le formulaire de contact en précisant le thème, l’hébergeur et la dernière date de mise à jour. Je vous dis ce qui se traite tout de suite et ce qui demande un dépannage WordPress en bonne et due forme.
Ceci n’est pas un guide pour modifier seul le code d’une extension sur un site en production.