Depuis WordPress 5.9, le bloc Navigation s’est installé au cœur de l’éditeur de site comme la brique de référence pour construire un menu. Fini le détour obligé par Apparence → Menus : il est désormais possible de glisser des liens, des pages, des sous-menus et même des icônes de réseaux sociaux directement dans le canevas, avec un aperçu fidèle au rendu final. Sur le papier, c’est un vrai confort pour qui construit un thème de blocs de A à Z.
Dans la pratique, ce bloc est aussi l’un de ceux qui génèrent le plus de tickets de support. Entre l’overlay qui ne s’affiche pas comme prévu, les styles CSS d’un thème classique qui débordent sur le rendu, ou la confusion entre un menu « bloc » et un menu « classique », il vaut mieux connaître les pièges avant de livrer un site à un client. C’est l’objet de cet article : un tour de réglages concrets, testés en production sur plusieurs sites clients ces derniers mois.
Créer un menu directement en blocs
Quand on ajoute un bloc Navigation dans l’éditeur de site (typiquement dans le template part header.html), WordPress propose trois options : créer un nouveau menu vide, importer un menu classique existant, ou sélectionner un menu de blocs déjà créé. Le menu de blocs est alors stocké comme un wp_navigation, un type de contenu à part entière visible dans Apparence → Éditeur → Navigation.
Concrètement, chaque élément du menu devient un bloc Élément de navigation, avec ses propres réglages : ouverture dans un nouvel onglet, description pour l’accessibilité, ou transformation en sous-menu par un simple glisser-déposer vers l’intérieur d’un autre élément. On peut aussi insérer des blocs qui n’ont rien d’un lien classique : un champ de recherche, un bloc Réseaux sociaux ou même du texte libre.
Régler l’overlay responsive sans mauvaise surprise
Le réglage le plus mal compris reste sans doute l’overlay mobile. Dans le panneau des réglages du bloc, l’option Menu déroulant permet de forcer l’apparition d’une icône burger même sur desktop, ou au contraire de la limiter à un point de rupture. Deux sous-réglages méritent une attention particulière :
- Couleur de l’overlay : si elle n’est pas définie explicitement, elle hérite parfois de la couleur de fond du site, ce qui rend le menu illisible sur un thème sombre.
- Icône du menu : trois choix (chevron, bars, croix) dont le rendu diffère fortement selon la taille de la zone de clic définie par le thème.
La synchronisation avec les menus classiques
Un point qui surprend souvent en migration : un menu créé via wp_nav_menu() dans un thème classique n’est pas automatiquement converti en bloc Navigation. Il faut passer par l’option d’import proposée au moment de l’insertion du bloc, qui duplique la structure du menu classique en un nouveau menu de blocs. Résultat : deux menus coexistent en base, l’un sous forme de taxonomie nav_menu, l’autre sous forme de wp_navigation. Sur un site avec plusieurs emplacements de menu, il n’est pas rare de devoir fusionner deux ou trois menus à la main après l’import, faute de correspondance automatique entre les emplacements de thème classique et les blocs Navigation.
Les pièges rencontrés en production
Voici les quatre pièges les plus fréquents constatés sur des projets réels, avec la solution appliquée à chaque fois.
- Styles CSS qui débordent : un thème classique conserve souvent des règles
ul.menu liou.nav-menu ahéritées de son fichierstyle.css. Ces sélecteurs, très larges, s’appliquent aussi aux nouveaux blocs Navigation et cassent leur mise en page. La solution consiste à restreindre ces sélecteurs à leur contexte d’origine, ou à surcharger localement via le panneau de styles du bloc. - Sous-menus invisibles : quand un thème enfant charge un ancien script jQuery de menu déroulant (pensé pour
wp_nav_menu()), celui-ci masque endisplay: noneles sous-menus du bloc Navigation sans jamais les réafficher au survol, puisque le script ne reconnaît pas la structure HTML générée par le bloc. Il faut désactiver ce script sur les pages utilisant l’éditeur de site. - Conflit avec un thème classique hybride : certains thèmes ajoutent un
header.phpclassique en parallèle d’un template part de bloc. Les deux s’affichent alors l’un sous l’autre. Il faut choisir clairement son camp : thème classique complet, ou thème de blocs complet, rarement un mélange viable sur la durée. - Perte des réglages au changement de thème : comme le menu de blocs est stocké en tant que contenu (
wp_navigation), il survit à un changement de thème, contrairement aux réglages d’apparence liés au thème précédent. Bonne nouvelle pour la portabilité, mais à vérifier avant toute bascule.
Un exemple de correctif CSS ciblé
Pour neutraliser un ancien sélecteur trop large sans toucher au thème enfant existant, on peut ajouter ce correctif dans le fichier de styles additionnels du thème de blocs :
.wp-block-navigation .wp-block-navigation-submenu {
box-shadow: none;
border: 1px solid var(--wp--preset--color--contrast);
}
.wp-block-navigation__submenu-container {
min-width: 220px;
}Sur un projet récent, le simple fait d’inspecter la structure HTML générée par le bloc (des
<li>imbriqués très différents d’un menu classique) a suffi à comprendre pourquoi l’ancien script de menu déroulant ne fonctionnait plus. Avant de chercher un bug côté bloc, comparez toujours le HTML réellement rendu à celui que votre script attend.
En résumé
Le bloc Navigation tient ses promesses pour construire un menu visuellement, sans repasser par l’administration classique. Mais il ne fait pas disparaître par magie les habitudes héritées des thèmes classiques : scripts jQuery obsolètes, sélecteurs CSS trop larges, ou coexistence malheureuse entre deux systèmes de menu. La règle qui a le mieux fonctionné jusqu’ici : partir d’un thème de blocs propre, sans reliquat de functions.php orienté menu classique, et tester systématiquement l’overlay mobile sur un vrai téléphone avant la mise en ligne.
