Distinguer une interaction inactive d’un panneau invisible
Le bouton du menu mobile est bien visible, mais rien ne semble se passer lorsque vous le touchez. Trois situations peuvent produire ce résultat : un élément intercepte l’action, le code d’ouverture ne s’exécute pas, ou le panneau s’ouvre tout en restant masqué. La correction dépend de cette distinction.
Le but est de retrouver une ouverture et une fermeture fiables, avec des liens accessibles. Forcer le panneau à rester visible par CSS ne répare pas son fonctionnement : vous pourriez perdre le bouton de fermeture, le défilement ou le retour du focus. Ajouter une seconde extension de menu sans identifier la première peut aussi produire deux commandes concurrentes.
Choisissez une page publique et reproduisez l’échec au premier toucher, puis après quelques secondes. Notez si un second toucher fonctionne. Comparez avant et après défilement, car un en-tête compact peut utiliser un autre bouton. Si le défaut apparaît uniquement après un changement de page interne, gardez également cette séquence.
Conservez les réglages actuels et travaillez sur une copie pour les essais qui modifient l’optimisation ou les extensions. Un diagnostic dans le navigateur commence sans changement du site. Vous pourrez ainsi séparer une preuve d’interaction, une erreur de ressource et une modification réellement responsable du rétablissement.
Identifier le composant et reproduire le contexte visiteur
Avec un thème de blocs, retrouvez Navigation dans la partie d’en-tête du modèle concerné, depuis Apparence → Éditeur. Avec un thème classique ou un constructeur, identifiez le composant qui produit le bouton mobile. Le même dessin à trois lignes peut correspondre à des systèmes totalement différents ; leurs scripts et réglages ne sont pas interchangeables.
Comparez la même adresse déconnecté et connecté. Les outils d’optimisation peuvent traiter surtout les visiteurs, et la session d’administration peut contourner une partie du cache. Un menu fonctionnel pour l’administrateur ne suffit donc pas à conclure qu’il fonctionne pour le public. Refaites le contrôle dans un autre navigateur, en gardant les mêmes conditions.
Notez aussi l’état du bandeau de consentement et la présence d’un bloqueur dans le navigateur. Une fenêtre privée n’exclut pas automatiquement toutes les extensions : certaines peuvent y être autorisées. Il s’agit d’identifier le contexte, pas de demander aux visiteurs de retirer leurs protections pour utiliser le site.
Ce repérage demande seulement un navigateur au départ. Les corrections de modèle, de CSS ou d’extension exigent ensuite les droits correspondants. Sur WordPress.com et dans un réseau multisite, ces droits peuvent être limités. Ne changez pas les rôles ni toute la configuration de sécurité pour rendre un bouton interactif.
Observer l’état du bouton avant et après activation
Faites un clic droit sur le bouton dans Chrome et choisissez Inspecter. Sélectionnez le véritable élément button plutôt que son dessin interne. Si le composant utilise aria-expanded, cet attribut décrit un état replié ou développé. Observez sa valeur avant puis après l’activation, sans la modifier manuellement.
Un passage de false à true indique que le composant annonce une ouverture, mais ne prouve pas que le panneau est visible ou utilisable. Si l’état change, regardez plutôt les styles et la disposition du panneau. Si l’état reste identique, examinez le clic, les erreurs et l’initialisation. Un composant personnalisé peut employer un autre mécanisme ; l’absence de cet attribut ne donne pas à elle seule la cause.
Essayez également le clavier à petite largeur : Tab pour atteindre le bouton, puis Entrée ou Espace selon son fonctionnement. Si le clavier ouvre le panneau alors que le pointeur ne le fait pas, un recouvrement ou une règle de pointeur devient une piste utile. Ce résultat reste à confirmer par l’inspection.
- Relevez l’élément sélectionné et son état initial.
- Actionnez le bouton une fois puis observez l’état et le panneau.
- Refermez si possible et vérifiez le retour à l’état replié.
- Gardez ces observations pour choisir entre présentation et interaction, sans fabriquer l’état ouvert dans le HTML.
Corriger un recouvrement ou un panneau déjà ouvert mais masqué
Si l’état change après activation, inspectez le panneau associé. Cherchez un parent avec une hauteur trop faible, un débordement masqué, une transparence ou un positionnement qui le place hors de l’écran. Si le pointeur semble toucher un autre élément, inspectez aussi le bandeau ou le groupe qui occupe la même zone que le bouton.
Décochez temporairement la déclaration suspecte dans Styles pour vérifier son effet. Le rechargement annule cet essai. Une règle pointer-events peut empêcher le bouton de recevoir l’action du pointeur tout en laissant certains usages au clavier possibles. Ne l’appliquez pas à tout l’en-tête pour rendre un bouton accessible : vous risqueriez de neutraliser les autres liens.
Corrigez ensuite la source confirmée. Dans votre CSS additionnel, conservez le texte initial puis retirez seulement la déclaration responsable. Le chemin est Apparence → Personnaliser → CSS additionnel pour un thème classique, ou Styles → menu à trois points → CSS additionnel dans l’éditeur de site pour un thème de blocs. Pour un réglage du constructeur, utilisez son propre panneau de disposition.
Le résultat attendu est un bouton actionnable et un panneau visible uniquement dans l’état ouvert. Vérifiez sa fermeture et la page derrière lui. Pour annuler, remettez la déclaration ou la valeur conservée. Si aucune modification de présentation ne change le résultat, revenez aux scripts plutôt que d’ajouter des valeurs d’empilement extrêmes.
Relever une erreur JavaScript reproductible
Ouvrez la Console du navigateur avant de recharger la page. Effacez les anciens messages si nécessaire, rechargez, puis actionnez une fois le bouton. Notez le message exact, le fichier concerné et le moment de son apparition. Une erreur au chargement n’a pas la même chronologie qu’une erreur déclenchée au clic.
Une ligne rouge peut provenir d’une publicité ou d’un service sans lien avec le menu. Elle devient une piste lorsqu’elle concerne le composant ou lorsqu’un essai ciblé relie sa disparition au retour du fonctionnement. N’attribuez pas automatiquement tout le défaut à la première erreur visible et ne collez pas une commande proposée par un message inconnu.
WordPress utilise notamment des modules JavaScript pour l’interactivité de certains blocs, dont Navigation. Une correction qui ne tient compte que d’un ancien fichier jQuery peut donc manquer le mécanisme réel. N’ajoutez pas une bibliothèque ou un gestionnaire de clic improvisé avant d’avoir identifié le composant actif.
Vous n’avez pas besoin d’activer l’affichage public des erreurs PHP pour cette première vérification. Conservez seulement le message pertinent et l’URL du fichier, en retirant les informations privées. Si la console reste vide, cela n’exclut ni un clic intercepté ni un code qui n’a jamais été chargé ; poursuivez avec Réseau et la comparaison des réglages.
Vérifier que les scripts attendus arrivent bien
Dans Réseau, rechargez la page avec les outils ouverts puis regardez les ressources JavaScript et les erreurs de chargement. Consultez aussi la liste complète si un module ne figure pas dans le filtre prévu. Relevez l’adresse de la ressource, son statut et le composant dont elle provient.
Une réponse 404 peut correspondre à un ancien nom conservé dans une page mise en cache après une mise à jour. Une réponse 403 signale un refus. Un statut 200 peut malgré tout contenir une page HTML au lieu du JavaScript attendu ; vérifiez les en-têtes et la réponse quand l’erreur évoque un type de contenu ou une syntaxe inattendue.
Si la page demande encore une ancienne ressource, actualisez le cache concerné puis vérifiez l’URL demandée avant de remplacer des fichiers. Si la ressource actuelle manque réellement, conservez l’état du composant et rétablissez sa version officielle complète sur une copie selon son mécanisme de mise à jour. Ne récupérez pas un fichier isolé d’une autre version : ses dépendances peuvent différer.
Une erreur CSP nomme une règle de sécurité qui refuse une ressource ou une exécution. Identifiez la source prévue avec le gestionnaire de cette politique ; ne désactivez pas toute la protection. Le résultat doit être une ressource correcte et exécutée dans le contexte de la page, puis une interaction fonctionnelle. Le téléchargement seul n’est pas une preuve d’ouverture du menu.
Tester un retard JavaScript dans LiteSpeed Cache déjà installé
Si LiteSpeed Cache est déjà utilisé et que le défaut concerne surtout les visiteurs ou le premier toucher, testez son traitement JavaScript sur une copie. Ne l’installez pas pour réparer un menu. La version 7.9.3 de LiteSpeed Technologies vérifiée déclare WordPress 6.0 et PHP 7.4 minimum, avec un test déclaré jusqu’à WordPress 7.1.4.
Conservez les réglages, éventuellement par LiteSpeed Cache → Toolbox → Import/Export → Export Settings. Le report de JavaScript peut différer l’exécution jusqu’à la fin du HTML ou attendre une activité utilisateur selon le mode choisi. Ce comportement mérite un essai ciblé, sans désactiver d’emblée toutes les fonctions de l’extension.
Si l’essai rétablit l’ouverture, poursuivez vers une exception ciblée. Une amélioration observée après plusieurs modifications simultanées ne permettrait pas d’identifier ce réglage comme cause. Gardez donc les autres valeurs identiques pendant cette comparaison.
- Ouvrez LiteSpeed Cache → Page Optimization → JS Settings.
- Notez la valeur de Load JS Deferred, puis choisissez OFF.
- Enregistrez les modifications.
- Dans Toolbox → Purge, utilisez Purge All - CSS/JS si des fichiers optimisés doivent être renouvelés ; actualisez aussi la page mise en cache concernée.
- Retestez déconnecté, dès le premier toucher.
- Remettez la valeur initiale si cela ne change rien.
Conserver une correction ciblée plutôt qu’un arrêt global d’optimisation
Lorsque le test confirme l’effet d’un traitement JavaScript, identifiez les ressources réellement concernées et leurs dépendances. Un menu peut charger un fichier principal puis d’autres modules. Exclure un nom deviné ou un dossier entier peut être inutile ou retirer largement les optimisations sans nécessité.
Dans LiteSpeed Cache → Page Optimization → Tuning, JS Deferred/Delayed Excludes permet de lister une ressource à exclure du report, une entrée par ligne, sous forme d’URI ou de fragment distinctif, sans joker. JS Excludes concerne d’autres traitements comme la minification et la combinaison. Choisissez le contrôle correspondant à l’essai qui a rétabli le menu.
Conservez la liste initiale, ajoutez l’exception justifiée puis réactivez le réglage testé. Enregistrez, actualisez les caches concernés et vérifiez une première visite. Si les fichiers ne sont pas traités par cet outil, une exception dans cet outil n’aura pas d’effet. N’ajoutez pas de liste universelle de scripts à partir d’un autre site.
Le résultat attendu est un menu fonctionnel avec les autres réglages conservés. Pour annuler, retirez la seule exception ajoutée et restaurez le mode précédent. Si une exception fiable ne peut être établie, un réglage moins agressif documenté peut rester temporairement préférable, en attendant une correction du composant ; consignez alors exactement ce compromis.
Choisir un diagnostic par session avec Troubleshooting
Troubleshooting est une extension autonome de Marius L. J., connu sous le nom Clorith. Sa version 1.0.2 vérifiée demande WordPress 6.4 et PHP 7.2 minimum et déclare un test jusqu’à WordPress 7.1.4. Elle permet de comparer des chargements de thèmes et d’extensions dans la session connectée, sans devoir désactiver manuellement tout le site pour les visiteurs.
Utilisez de préférence une copie si elle est disponible. L’outil ne remplace pas une sauvegarde et n’isole pas les écritures : un réglage ou un contenu modifié pendant le diagnostic peut rester modifié après sa désactivation. Les extensions obligatoires, dites mu-plugins, ne sont pas toutes retirées de ce contexte. Des caches agressifs peuvent aussi ne pas respecter l’isolement prévu.
Installez l’extension depuis Extensions → Ajouter une extension, en vérifiant le nom et l’auteur. Ouvrez Outils → Santé du site → Troubleshooting, puis Enable Troubleshooting Mode, ou sa traduction. Le site peut alors employer un thème par défaut et présenter les extensions comme inactives pour votre session.
Ce premier état ne constitue pas encore un test de votre menu : il faut conserver le composant qui le produit. Ne concluez pas à la disparition d’un conflit simplement parce que le menu d’origine a lui-même disparu. La section suivante décrit la comparaison à effectuer sans modifier les contenus ni les réglages du site.
Comparer les extensions sans perdre le composant du menu
Dans la barre d’administration, utilisez le menu Troubleshooting Mode pour remettre votre thème d’origine dans le contexte de diagnostic. Si le menu dépend d’une extension ou d’un constructeur, activez aussi ce composant dans ce même contexte. Rechargez la page publique dans cette session et vérifiez qu’il s’agit bien du menu à diagnostiquer.
Réintroduisez ensuite les autres extensions une par une, en testant l’ouverture après chaque changement. Notez le premier ajout qui fait réapparaître le défaut. Refaite en sens inverse, la comparaison doit montrer que son retrait du contexte de diagnostic rétablit le fonctionnement. Cette répétition limite les conclusions fondées sur un simple rechargement ou sur un cache différent.
La sortie du mode rétablit le chargement normal, mais n’annule pas des réglages que vous auriez édités. N’en modifiez donc pas pendant cette recherche. Si le problème ne se produit que pour les visiteurs, cette comparaison connectée fournit une piste, pas la preuve finale : reproduisez la correction sur une copie dans le contexte visiteur.
- Conservez le thème et les dépendances indispensables au menu.
- Vérifiez le bouton avec ce minimum réellement comparable.
- Ajoutez une extension à la fois dans le mode de diagnostic.
- Notez le résultat et revenez au dernier état fonctionnel pour confirmer.
- Terminez par Disable Troubleshooting Mode dans la barre d’administration.
- Contrôlez le site dans sa configuration normale et dans une session déconnectée.
Tester le premier chargement et la navigation entre pages
Certains défauts ne se produisent pas au même moment. Un menu peut fonctionner après une actualisation complète puis cesser de répondre après un lien interne. À l’inverse, un code retardé peut manquer la première interaction et fonctionner ensuite. Gardez ces deux scénarios dans vos contrôles afin de ne pas valider un résultat trop partiel.
Sur un site équipé d’une navigation côté client, le navigateur peut changer le contenu sans refaire tout le chargement habituel. Les composants doivent rester compatibles avec ce mécanisme. La documentation WordPress distingue les modules nécessaires et les scripts qui ne sont pas réexécutés de la même manière dans ce parcours.
Ouvrez donc directement une page, testez le bouton, suivez un lien interne puis recommencez. Comparez ensuite avec une actualisation complète de cette seconde page. Si seul le parcours interne échoue, consignez la séquence et le composant qui gère cette navigation. N’ajoutez pas un second gestionnaire de clic à chaque changement de page : il pourrait produire des ouvertures et fermetures doubles.
La correction doit intervenir dans le composant ou dans le réglage d’optimisation confirmé. Le développeur aura besoin du trajet exact et des erreurs observées pour vérifier son initialisation. Ce cas ne justifie pas de modifier les permaliens ni de désactiver globalement les interactions WordPress.
Valider l’ouverture complète et transmettre une preuve utile
Après la correction, vérifiez plusieurs ouvertures et fermetures, au toucher puis au clavier. Le focus doit rester repérable, les liens accessibles et le défilement possible si le panneau est plus haut que l’écran. Vérifiez aussi la fermeture et le retour à l’usage normal de la page, avec les sous-menus nécessaires.
Refaites les essais déconnecté, lors d’une première visite et après un changement de page. Contrôlez une largeur intermédiaire et le téléphone concerné. Si vous avez changé une optimisation, vérifiez que le résultat reste bon après reconstruction du cache, pas seulement pendant un diagnostic connecté. Gardez les paramètres de départ pour annuler la seule correction appliquée.
Un compte rendu utile contient la page, la largeur, la séquence exacte, l’état observé du bouton, l’éventuel message de console et l’URL de la ressource pertinente. Ajoutez le réglage dont le changement rétablit le fonctionnement et indiquez si cet effet a été confirmé en sens inverse. Retirez les cookies et données de session avant tout partage.
La prévention consiste à conserver ces quelques tests après une mise à jour de thème, de constructeur ou d’optimisation. Un menu mobile est une fonction de navigation, pas seulement une icône : sa présence visuelle ne suffit pas. Gardez une seule source de commande et documentez les exceptions de scripts réellement nécessaires au site.
Comparer le point touché et le bouton qui reçoit le focus
Dans la copie WordPress, le bloc Navigation affiche son bouton à une largeur de 390 pixels. Une couche transparente du gabarit de test occupe le même emplacement. Au centre du bouton, l’inspection du navigateur désigne cette couche comme élément qui reçoit l’interaction. Le clic et le toucher émulé laissent le panneau fermé. Avec Tab, le focus atteint pourtant le bouton. Entrée ouvre le panneau et Échap le ferme en restituant le focus au bouton.
Ce contraste permet de tester votre propre en-tête sans remplacer le menu. Ouvrez la page publique à la largeur concernée. Gardez le pointeur hors de l’en-tête et utilisez Tab jusqu’au bouton. Ouvrez et fermez le panneau au clavier. Activez ensuite le sélecteur d’élément des outils de développement et visez le centre du bouton visible. Dans Éléments, vérifiez si l’élément sélectionné appartient au bouton ou à une zone qui passe devant lui. Un clic effectué dans le sélecteur sert à inspecter. Désactivez le sélecteur avant de refaire le vrai clic.
Dans la console du navigateur, ce contrôle en lecture seule renvoie l’élément qui occupe le centre du bouton du bloc Navigation natif. Si l’en-tête comporte plusieurs menus, identifiez le bouton concerné dans l’inspecteur avant de comparer. Faites le relevé à la largeur où le bouton est visible, puis recommencez après avoir retiré temporairement la couche suspecte dans les styles de la copie.
(() => {
const bouton = document.querySelector('.wp-block-navigation__responsive-container-open');
if (!bouton) return null;
const {left, top, width, height} = bouton.getBoundingClientRect();
return document.elementFromPoint(left + width / 2, top + height / 2);
})()Confirmer la règle avec une modification temporaire
Dans la recette, le retrait de la couche a fait revenir le bouton comme cible au même point. Un clic et un toucher émulé ont ouvert le panneau, et sa commande de fermeture l’a refermé. Le parcours clavier a continué à fonctionner. Les mesures portent sur le bloc Navigation natif rendu par WordPress et sur une couche ajoutée au gabarit de test.
Sur votre copie, masquez temporairement la seule couche suspecte dans l’inspecteur, ou décochez la règle qui la place devant le bouton. Refaites l’essai au même point. Si le clic fonctionne, identifiez le bloc ou la feuille de style à l’origine du recouvrement. Corrigez la position ou les dimensions de cet élément dans sa source. Si la zone contient un lien ou un bouton utile, vérifiez aussi que ce contrôle reste actionnable. Un rechargement annule l’essai de l’inspecteur. Pour annuler une correction enregistrée, rétablissez la seule règle ou la révision du bloc que vous avez modifiée.
Refaire le parcours sur le panneau réellement servi
Après la correction, ouvrez une page de la copie en visiteur anonyme à la largeur qui posait problème. Vérifiez le premier clic, l’apparition des liens et l’action de fermeture. Ouvrez ensuite une seconde page utilisant le même en-tête. Recommencez au clavier, sans déplacer la souris sur le menu. Le bouton doit recevoir le focus, le panneau doit s’ouvrir et la fermeture doit permettre de reprendre la navigation.
Le toucher de la recette est émulé dans Chrome. Pour le contrôle final d’un site, vérifiez aussi le même enchaînement sur le téléphone et le navigateur concernés. Si la zone sélectionnée par l’inspecteur était déjà le bouton et que le panneau reste fermé, passez aux contrôles de la Console et de Réseau décrits plus haut. Relevez l’erreur ou la ressource manquante avant d’essayer un changement de cache ou de script.
