# Le bloc Navigation dans l’éditeur de site : réglages, pièges et pratiques

> Le bloc Navigation promet de remplacer les menus classiques sans PHP. En production, il réserve quelques surprises. Tour d'horizon des réglages et des pièges.

- Auteur : Clément Hadrot
- Publié le : 2022-05-17
- Mis à jour le : 2022-05-17
- Catégorie : FSE
- URL : https://wpmoderne.dev.wordpress-developpement.fr/fse/bloc-navigation-editeur-site-reglages-pieges/

## L’essentiel

- Créer et éditer un menu directement en blocs, sans wp_nav_menu()
- Régler l'overlay responsive sans casser le design mobile
- Éviter les 4 pièges les plus fréquents en production

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.

> L'essentiel à retenir : Créer et éditer un menu directement en blocs, sans wp_nav_menu() ; Régler l'overlay responsive sans casser le design mobile ; Éviter les 4 pièges les plus fréquents en production

## 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 li` ou `.nav-menu a` héritées de son fichier `style.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 en `display: none` les 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.php` classique 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.