Comment maintenir d’énormes menus dans Drupal
J’ai un jour ouvert un menu Drupal contenant plusieurs milliers de liens et j’ai vu le navigateur abandonner avant moi. La page s’est chargée, techniquement. Ensuite, chaque clic donnait l’impression de demander à une vieille imprimante d’expliquer ses sentiments.
Commencez avec BigMenu et Menu Select
Si un site Drupal possède un grand menu éditorial, le premier problème n’est généralement pas l’architecture. C’est l’écran de l’éditeur. La page d’administration des menus du cœur de Drupal peut devenir pénible lorsque le menu atteint des milliers de liens. BigMenu résout cela en modifiant la façon dont les éditeurs parcourent et gèrent le menu : au lieu de forcer l’arborescence complète à s’afficher sur la page, il permet d’ouvrir des sous-arbres via AJAX lorsque l’éditeur en a besoin. https://www.drupal.org/project/bigmenu
Cela semble mineur jusqu’à ce que vous ayez utilisé l’interface de menu par défaut sur un grand site. Une arborescence repliée reste pénible si Drupal a dû tout construire avant que la page ne devienne utilisable. La valeur de BigMenu est d’éviter ce chargement massif initial. L’éditeur voit la partie de l’arborescence qu’il a demandée, pas toute la forêt. https://www.drupal.org/project/bigmenu
Menu Select résout une autre irritation. Dans les formulaires de contenu, les éditeurs doivent souvent choisir un élément de menu parent. Avec un grand menu, une liste de sélection classique devient absurde. Personne ne veut faire défiler des milliers d’éléments simplement pour placer une page sous le bon parent. Menu Select remplace cette expérience par une hiérarchie plus utilisable et peut ajouter l’autocomplétion, afin que l’éditeur puisse rechercher le lien parent au lieu de fouiller manuellement dans tout le menu. https://www.drupal.org/project/menu_select
J’aime cette séparation. BigMenu aide lorsque vous gérez le menu lui-même. Menu Select aide lorsque vous rattachez du contenu au menu. Il est facile de les confondre parce qu’ils touchent tous deux à l’expérience utilisateur des menus, mais ils corrigent des moments différents du flux de travail éditorial.
Menu Select Ajax : charger le choix lorsque l’éditeur en a besoin
Menu Select avec autocomplétion est déjà un grand pas en avant. Mais sur de très grands sites, même un meilleur widget peut rester trop lourd si le formulaire essaie de préparer trop de données de menu avant que l’éditeur ne fasse quoi que ce soit. C’est là qu’un modèle de sélection de menu basé sur AJAX prend tout son sens.
L’idée est simple : le formulaire ne devrait pas construire un sélecteur parent complet pour un menu massif lors du chargement initial. Il devrait attendre. Lorsque l’éditeur choisit un menu, saisit un terme de recherche ou ouvre une branche, Drupal peut effectuer une petite requête AJAX et ne renvoyer que la partie correspondante du menu. L’API Form de Drupal prend en charge ce modèle grâce à des éléments de formulaire compatibles AJAX, où une action utilisateur déclenche une reconstruction côté serveur et seule la partie choisie du formulaire est remplacée. https://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-forms
En pratique, une sélection de menu AJAX comporte généralement deux couches. La première couche est le sélecteur visible : un champ de recherche, un sélecteur de parent ou une petite branche extensible. La deuxième couche est la valeur stockée : l’ID réel du plugin de lien de menu ou la référence au parent dont Drupal a besoin lorsque le formulaire est enregistré.
Cette distinction est importante. Les éditeurs devraient travailler avec des libellés, des chemins et des titres de pages familiers. Drupal devrait stocker des valeurs machine stables. Lorsque ces deux préoccupations se mélangent, les widgets de grands menus deviennent fragiles. On voit apparaître des libellés en double, des choix de parents peu clairs et des reconstructions de formulaire lentes.
Un bon flux de sélection de menu AJAX paraît presque ennuyeux. L’éditeur commence à saisir une partie d’un titre. Drupal renvoie une courte liste de liens parents possibles, de préférence avec suffisamment de contexte pour distinguer les titres identiques. L’éditeur en choisit un. Le formulaire stocke le lien de menu sélectionné en arrière-plan. Pas de liste de sélection gigantesque. Pas de rendu complet de l’arborescence. Pas de navigateur qui s’effondre.
Le même modèle fonctionne pour les branches extensibles. Affichez d’abord le niveau supérieur. Lorsque l’éditeur ouvre un parent, récupérez les enfants de ce parent. S’il ouvre un autre enfant, récupérez le niveau suivant. C’est ainsi que l’interface devrait se comporter lorsque l’ensemble de données est volumineux : petite requête, petite réponse, prochaine action claire.
À 10 000 éléments de menu, arrêtez de charger vers l’avant
Lorsqu’un menu atteint quelque chose comme 10 000 éléments, je cesse de le considérer comme un menu Drupal normal. Techniquement, c’est toujours un menu. Opérationnellement, cela ressemble davantage à un index de contenu en forme d’arbre.
L’erreur courante consiste à partir de la racine, charger toute l’arborescence, développer le chemin actif, puis jeter la majeure partie du résultat. Cela fonctionne sur les petits menus. Sur un menu immense, c’est faire les choses à l’envers.
La meilleure approche que j’ai utilisée était le chargement à rebours. Commencez par le lien de menu actif de la page actuelle. À partir de là, ne chargez que ses parents. Cela vous donne le chemin actif sans demander à Drupal de construire toutes les branches sans rapport. Les API de menu de Drupal prennent en charge cette direction de parcours : le gestionnaire de liens de menu peut trouver des liens par route, et il expose également les ID parents pour un plugin de lien de menu. https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21MenuActiveTrail.php/11.x https://api.drupal.org/api/drupal/core%21lib%21drupal%21core%21menu%21menulinkmanagerinterface.php/function/menulinkmanagerinterface%3A%3Agetparentids/9
Cela change complètement le profil de coût. Un menu énorme peut compter 10 000 éléments, mais le chemin actif d’une page est généralement court. Peut-être cinq niveaux. Peut-être sept. Même un catalogue profond comporte rarement des dizaines d’ancêtres pour un seul élément. Ainsi, au lieu de charger 10 000 liens pour découvrir un chemin, vous chargez l’élément actif et remontez.
Ensuite, vous pouvez décider de la quantité de navigation environnante dont la page a réellement besoin. Parfois, le chemin parent suffit. Parfois, vous avez aussi besoin des enfants de l’élément actif. Parfois, vous avez besoin des éléments frères à un niveau donné pour un menu de section. Très bien. Chargez ces portions délibérément. Ne laissez pas « nous avons besoin de navigation » devenir discrètement « charge toute l’arborescence à chaque requête ».
Le système d’arborescence de menu de Drupal pense déjà en termes de paramètres d’arbre, de chemins actifs et de transformations. L’approche habituelle de chargement d’arbre peut développer les liens le long du chemin actif courant, ce qui est utile sur les menus normaux. https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21MenuLinkTreeInterface.php/interface/MenuLinkTreeInterface/8.2.x Sur un très grand menu, cependant, je préfère être plus strict. Trouvez d’abord le lien actif. Chargez ensuite ses parents. Puis ne chargez que la branche nécessaire pour la page actuelle.
La vraie règle de maintenance : ne faites jamais payer tout le menu aux éditeurs
Les énormes menus Drupal ne sont pas seulement un problème de rendu. Ils sont un problème éditorial, un problème de construction de formulaire, un problème de cache et parfois un problème d’architecture de l’information que quelqu’un a repoussé pendant trois ans.
BigMenu aide les éditeurs à travailler avec de grands arbres sans tout ouvrir d’un coup. https://www.drupal.org/project/bigmenu Menu Select rend la sélection du parent supportable, surtout avec l’autocomplétion. https://www.drupal.org/project/menu_select La sélection AJAX empêche les formulaires de préparer des milliers de choix avant que l’éditeur n’ait effectué son premier clic significatif. https://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-forms
Pour la navigation front-end, le chargement à rebours est la partie que je protégerais le plus fermement. Commencez par le lien de menu actif. Ne chargez que les parents. Ajoutez des enfants ou des frères uniquement lorsque le design en a réellement besoin. Cette seule habitude empêche un menu de 10 000 éléments de transformer chaque requête en punition.
Le navigateur ne devrait jamais avoir à porter tout le menu simplement parce qu’une page a besoin de savoir où elle se trouve.
Vous cherchez la meilleure entreprise de développement Drupal du marché ? Vous venez de la trouver.
Nous sommes la plus grande agence digitale spécialisée Drupal, conçue pour livrer des plateformes rapides, sécurisées et évolutives, sans compromis. Des nouvelles créations et refontes aux migrations et au support à long terme, nos experts Drupal livrent des résultats de niveau entreprise avec une attention digne d’une agence boutique.
Réservez un appel dès aujourd’hui et transformons votre feuille de route Drupal en une réalité hautement performante.
Ivan Abramenko, architecte Drupal principal
ivan.abramenko@drupalbook.org
projects@drupalbook.org