Le menu principal d’un site associatif reposait depuis six ans sur un widget de menu proposé par une extension tierce autrefois populaire, dont le développement s’est arrêté silencieusement, sans annonce officielle, aux alentours de la version 8.0 de PHP. Le site tournait encore sous PHP 7.4 jusqu’à ce que l’hébergeur impose une migration vers une version plus récente pour des raisons de sécurité, révélant au passage que le widget de menu ne survivait pas au changement.
Ce scénario, loin d’être isolé, mérite une méthode claire plutôt qu’une improvisation dans l’urgence. Le widget Nav Menu natif d’Elementor Pro, souvent perçu comme trop rigide au moment du choix initial du widget tiers, des années plus tôt, couvre en réalité la grande majorité des besoins de mise en forme rencontrés en pratique.
Étape 1 : documenter précisément le rendu existant avant de toucher à quoi que ce soit
Avant toute suppression, une capture d’écran détaillée du menu dans ses différents états (fermé, ouvert, sous-menu déployé, version mobile) constitue la seule référence fiable une fois le widget tiers désinstallé, puisque son panneau de réglages disparaît avec lui. Sur ce projet, le menu comportait un sous-menu à deux niveaux avec une mise en forme en colonnes pour la rubrique « Nos actions », un détail facilement oublié sans documentation visuelle préalable.
Étape 2 : recréer la structure avec le widget Nav Menu natif
Le widget Nav Menu natif d’Elementor Pro s’appuie directement sur les menus WordPress classiques, déjà existants et inchangés puisque le widget tiers ne faisait que les afficher différemment. La recréation de la structure de navigation elle-même ne demandait donc aucun travail : seule la mise en forme visuelle devait être reconstruite depuis les réglages natifs du widget.
Le cas du sous-menu en colonnes
Le widget natif ne propose pas nativement un sous-menu en colonnes multiples pour une seule rubrique, fonctionnalité propre au widget tiers abandonné. La solution retenue a consisté à accepter un sous-menu en liste simple, plus sobre visuellement mais parfaitement lisible, plutôt que de complexifier la migration avec un développement de widget custom pour reproduire à l’identique un détail esthétique mineur au regard du risque de maintenance à long terme qu’il représenterait.
Étape 3 : ajuster le CSS personnalisé
Le widget tiers générait ses propres classes CSS, référencées par plusieurs règles de style personnalisé accumulées au fil des années dans le CSS additionnel du site. Chaque référence à ces anciennes classes a dû être identifiée et adaptée aux classes générées par le widget Nav Menu natif, sous peine de conserver du code mort inoffensif mais aussi de perdre certains ajustements visuels fins (espacement, couleur au survol) sans s’en rendre compte immédiatement.
/* Ancien widget tiers, à retirer */
.tiers-menu-widget .tiers-sous-menu { column-count: 2; }
/* Widget Nav Menu natif, équivalent adapté */
.elementor-nav-menu--dropdown .elementor-nav-menu__container {
min-width: 220px;
}Étape 4 : tester avant de retirer définitivement l’ancien widget
- Publier le nouveau menu natif sur un environnement de préproduction, en parallèle de l’ancien, désactivé mais pas encore supprimé.
- Vérifier chaque état du menu (survol desktop, tap mobile, focus clavier) sur au moins deux navigateurs différents.
- Comparer visuellement, capture par capture, avec la documentation établie en étape 1.
- Désinstaller le widget tiers uniquement après validation complète, jamais avant, pour garder une option de retour arrière rapide en cas de problème imprévu.
Un widget tiers abandonné n’annonce jamais sa propre fin. Il continue de fonctionner jusqu’au jour où son environnement change sous ses pieds, souvent au pire moment, lors d’une migration technique déjà stressante pour d’autres raisons.
En résumé
La migration d’un menu construit avec un widget tiers abandonné vers le widget Nav Menu natif d’Elementor Pro est presque toujours possible sans perte fonctionnelle majeure, à condition d’accepter de renoncer à quelques détails esthétiques très spécifiques au profit d’une solution durable et maintenue. Documenter le rendu existant avant de commencer reste l’étape la plus souvent négligée, et la plus coûteuse à sauter.
