# Menu de navigation cassé après une mise à jour WordPress

> Le menu s’affiche vide, mal stylé, ou le bouton hamburger mobile ne réagit plus après une mise à jour de thème ou d’extension : le menu WordPress dépend d’un emplacement déclaré par le thème et d’une classe walker qui génère son HTML, et une mise à jour peut modifier l’un des deux sans prévenir.

- Source canonique : [https://allaux.fr/wordpress-woocommerce/problemes/menu-navigation-casse](https://allaux.fr/wordpress-woocommerce/problemes/menu-navigation-casse)
- Langue : FR
- Dernière mise à jour : 2026-08-03

## Réponse directe

> Videz d’abord le cache de page, puis ouvrez Apparence > Menus et contrôlez l’onglet Gérer les emplacements : une mise à jour peut renommer l’emplacement attendu par le thème, et le menu se retrouve rattaché à rien. Si l’emplacement est bon et le menu toujours vide, activez un thème par défaut le temps d’un test pour trancher entre thème et extension.

## Comment je procède

1. **Élimination du cache** — Je vide le cache de page, plugin de cache et cache serveur, avant toute autre vérification : un menu modifié récemment mais servi depuis une version en cache est la cause la plus simple et la plus fréquente.
2. **Vérification de l’emplacement de menu** — Je vérifie dans Apparence > Menus que l’emplacement attendu par le thème existe toujours et que le bon menu y est assigné ; une mise à jour de thème peut renommer ou supprimer un emplacement.
3. **Inspection du HTML généré** — Je compare le HTML produit par le menu à ce que le thème, ou son mega-menu personnalisé, attend : une classe walker modifiée par la mise à jour change parfois la structure attendue par le CSS ou le JavaScript.
4. **Test du menu mobile séparément** — Je vérifie le comportement du bouton hamburger indépendamment du menu desktop : un conflit de version jQuery ou deux scripts qui gèrent le même clic cassent souvent uniquement le menu mobile.
5. **Vérification du constructeur de pages** — Si un widget menu Elementor est utilisé dans l’en-tête, je vérifie qu’il pointe vers le même menu, car il suit un chemin de rendu distinct de l’emplacement natif du thème.

## Ce que je traite régulièrement

- Le menu du site n’affiche plus rien après une mise à jour de thème
- Le menu s’affiche mais perd tout son style, mise en page cassée
- Le bouton hamburger mobile ne réagit plus au clic alors que le menu desktop fonctionne
- Un menu modifié dans Apparence > Menus n’apparaît pas côté visiteur
- Le menu affiché diffère entre la page d’accueil et les autres pages

## Ce qui casse un menu

Un menu WordPress repose sur un emplacement déclaré par le thème via register_nav_menu(), et sur une classe walker — souvent Walker_Nav_Menu ou une classe personnalisée pour un mega-menu ou un menu mobile off-canvas — qui transforme la structure du menu en HTML. Une mise à jour de thème peut renommer ou supprimer un emplacement existant, ou changer la structure attendue par le walker : le menu assigné sous l’ancienne version cesse alors de s’afficher ou perd son comportement.

Un cache de page qui sert encore l’ancienne version après une modification du menu est une cause plus fréquente qu’un vrai bug : ça vaut la peine de l’écarter en premier.

Les menus hamburger mobiles dépendent du JavaScript, souvent jQuery. Une montée de version apportée par une mise à jour, ou deux scripts qui gèrent le même clic, cassent le bouton sans toucher au menu desktop. Un widget menu Elementor placé en en-tête suit un chemin de rendu distinct de l’emplacement natif du thème : les deux peuvent diverger après une mise à jour.

## Vider le cache avant de chercher plus loin

> Réassigner un emplacement de menu ou vider un cache se fait en quelques minutes, en configuration. Reconstruire une classe walker ou le script JavaScript du menu mobile pour la version actuelle du thème est un travail de développement, à ne pas confondre avant diagnostic.

## Pages liées

- **Site WordPress lent** — Un cache mal vidé après une modification touche aussi les temps de chargement perçus. ([/wordpress-woocommerce/site-lent](/wordpress-woocommerce/site-lent))
- **Extension sur mesure** — Reconstruire un walker ou un mega-menu personnalisé pour une nouvelle version de thème. ([/wordpress-woocommerce/extension-sur-mesure](/wordpress-woocommerce/extension-sur-mesure))
- **Erreur 404 après migration** — Un autre type de casse fréquente après une mise à jour ou une migration. ([/wordpress-woocommerce/problemes/erreur-404-apres-migration](/wordpress-woocommerce/problemes/erreur-404-apres-migration))

## FAQ

### Le menu a disparu juste après une mise à jour automatique, c’est lié ?

Très probablement. Je vérifie en premier si l’emplacement de menu déclaré par le thème a changé de nom ou a été supprimé dans la nouvelle version.

### J’ai vidé le cache et rien n’a changé, que faire ensuite ?

C’est le signe que le problème n’est pas un simple cache : je passe alors à la vérification de l’emplacement de menu et de la structure HTML générée par le walker.

### Pourquoi le menu desktop fonctionne mais pas le menu mobile ?

Le menu mobile dépend d’un script JavaScript séparé, souvent jQuery : un conflit de version ou deux scripts qui gèrent le même bouton cassent uniquement ce comportement, sans toucher au HTML du menu desktop.

### J’utilise Elementor pour mon en-tête, est-ce différent ?

Oui : un widget menu Elementor ne passe pas par l’emplacement natif du thème, il suit son propre chemin de rendu. Les deux peuvent afficher des menus différents après une mise à jour si l’un des deux n’a pas suivi.

### Combien de temps pour remettre le menu en état ?

Un cache ou un emplacement mal assigné se corrige en quelques minutes. Reconstruire le walker ou le script mobile dépend de la complexité du menu d’origine.