Cómo mantener menús enormes en Drupal
Una vez abrí un menú de Drupal con varios miles de enlaces y vi cómo el navegador se rendía antes que yo. La página cargó, técnicamente. Luego, cada clic se sentía como pedirle a una impresora vieja que explicara sus sentimientos.
Empieza con BigMenu y Menu Select
Si un sitio Drupal tiene un menú editorial grande, el primer problema normalmente no es la arquitectura. Es la pantalla del editor. La página de administración de menús del núcleo puede volverse dolorosa cuando el menú crece hasta miles de enlaces. BigMenu se encarga de eso cambiando la forma en que los editores exploran y gestionan el menú: en lugar de forzar todo el árbol en la página, permite abrir subárboles mediante AJAX cuando el editor los necesita. https://www.drupal.org/project/bigmenu
Eso suena pequeño hasta que has usado la interfaz de menú predeterminada en un sitio grande. Un árbol colapsado sigue siendo pesado si Drupal tuvo que construirlo completo antes de que la página fuera utilizable. El valor de BigMenu está en que evita esa carga masiva inicial. El editor ve la parte del árbol que pidió, no todo el bosque. https://www.drupal.org/project/bigmenu
Menu Select resuelve una molestia diferente. En los formularios de contenido, los editores a menudo necesitan elegir un elemento de menú padre. Con un menú grande, una lista de selección normal es absurda. Nadie quiere desplazarse por miles de elementos solo para colocar una página bajo el padre correcto. Menu Select reemplaza esa experiencia por una jerarquía más usable y puede añadir autocompletado, de modo que el editor pueda buscar el enlace padre en lugar de recorrer todo el menú manualmente. https://www.drupal.org/project/menu_select
Me gusta esta separación. BigMenu ayuda cuando estás gestionando el menú en sí. Menu Select ayuda cuando estás adjuntando contenido al menú. Es fácil confundirlos porque ambos afectan la experiencia de usuario de los menús, pero solucionan momentos distintos del flujo de trabajo editorial.
Menu Select Ajax: carga la opción cuando el editor la necesita
Menu Select con autocompletado ya es un gran paso adelante. Pero en sitios muy grandes, incluso un widget mejor puede seguir siendo demasiado pesado si el formulario intenta preparar demasiados datos del menú antes de que el editor haga algo. Aquí es donde tiene sentido un patrón de selección de menú basado en AJAX.
La idea es sencilla: el formulario no debería construir un selector completo de padres para un menú enorme durante la carga inicial. Debería esperar. Cuando el editor elige un menú, escribe un término de búsqueda o abre una rama, Drupal puede hacer una pequeña solicitud AJAX y devolver solo la parte coincidente del menú. La API de formularios de Drupal admite este patrón mediante elementos de formulario habilitados para AJAX, donde una acción del usuario desencadena una reconstrucción del lado del servidor y solo se reemplaza la parte elegida del formulario. https://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-forms
En la práctica, una selección de menú AJAX suele tener dos capas. La primera capa es el selector visible: un campo de búsqueda, un selector de padre o una pequeña rama expandible. La segunda capa es el valor almacenado: el ID real del plugin del enlace de menú o la referencia al padre que Drupal necesita cuando se guarda el formulario.
Esta distinción importa. Los editores deberían trabajar con etiquetas, rutas y títulos de página familiares. Drupal debería almacenar valores de máquina estables. Cuando estas dos preocupaciones se mezclan, los widgets de menús grandes se vuelven frágiles. Aparecen etiquetas duplicadas, opciones de padre poco claras y reconstrucciones lentas del formulario.
Un buen flujo de selección de menú AJAX se siente casi aburrido. El editor empieza a escribir parte de un título. Drupal devuelve una lista corta de posibles enlaces padre, preferiblemente con suficiente contexto para distinguir títulos idénticos. El editor elige uno. El formulario almacena el enlace de menú seleccionado en segundo plano. Sin una lista de selección gigantesca. Sin renderizar el árbol completo. Sin colapso del navegador.
El mismo patrón funciona para ramas expandibles. Muestra primero el nivel superior. Cuando el editor abre un padre, obtiene los hijos de ese padre. Si abre otro hijo, obtiene el siguiente nivel. Así es como debería comportarse la interfaz cuando el conjunto de datos es grande: solicitud pequeña, respuesta pequeña, siguiente acción clara.
Con 10.000 elementos de menú, deja de cargar hacia adelante
Una vez que un menú alcanza algo como 10.000 elementos, dejo de pensar en él como un menú normal de Drupal. Técnicamente, sigue siendo un menú. Operativamente, se parece más a un índice de contenido con forma de árbol.
El error común es empezar desde la raíz, cargar todo el árbol, expandir la ruta activa y luego descartar la mayor parte del resultado. Eso funciona en menús pequeños. En un menú enorme, es hacerlo al revés.
El mejor enfoque que usé fue la carga hacia atrás. Empieza con el enlace de menú activo de la página actual. Desde ahí, carga solo sus padres. Eso te da la ruta activa sin pedirle a Drupal que construya todas las ramas no relacionadas. Las API de menú de Drupal admiten esta dirección de recorrido: el gestor de enlaces de menú puede encontrar enlaces por ruta y también expone los ID de padres para un plugin de enlace de menú. 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
Esto cambia por completo el perfil de coste. Un menú enorme puede tener 10.000 elementos, pero la ruta activa de una página suele ser corta. Tal vez cinco niveles. Tal vez siete. Incluso un catálogo profundo rara vez tiene docenas de ancestros para un solo elemento. Así que, en lugar de cargar 10.000 enlaces para descubrir una ruta, cargas el elemento activo y avanzas hacia arriba.
Después de eso, puedes decidir cuánta navegación circundante necesita realmente la página. A veces la ruta de padres es suficiente. A veces también necesitas los hijos del elemento activo. A veces necesitas hermanos en un nivel para un menú de sección. Perfecto. Carga esos fragmentos deliberadamente. No permitas que “necesitamos navegación” se convierta silenciosamente en “carga todo el árbol en cada solicitud”.
El sistema de árboles de menú de Drupal ya piensa en términos de parámetros de árbol, rutas activas y transformaciones. El enfoque habitual de carga de árboles puede expandir enlaces a lo largo de la ruta activa actual, lo cual es útil en menús normales. https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21MenuLinkTreeInterface.php/interface/MenuLinkTreeInterface/8.2.x Sin embargo, en un menú muy grande, prefiero ser más estricto. Primero encuentra el enlace activo. Luego carga sus padres. Después carga solo la rama necesaria para la página actual.
La verdadera regla de mantenimiento: nunca hagas que los editores paguen por todo el menú
Los menús enormes de Drupal no son solo un problema de renderizado. Son un problema editorial, un problema de construcción de formularios, un problema de caché y, a veces, un problema de arquitectura de la información que alguien pospuso durante tres años.
BigMenu ayuda a los editores a trabajar con árboles grandes sin abrirlo todo de una vez. https://www.drupal.org/project/bigmenu Menu Select hace tolerable la selección de padres, especialmente con autocompletado. https://www.drupal.org/project/menu_select La selección AJAX evita que los formularios preparen miles de opciones antes de que el editor haya hecho el primer clic significativo. https://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-forms
Para la navegación del front-end, la carga hacia atrás es la parte que protegería con más firmeza. Empieza desde el enlace de menú activo. Carga solo los padres. Añade hijos o hermanos solo cuando el diseño realmente los necesita. Ese único hábito evita que un menú de 10.000 elementos convierta cada solicitud en un castigo.
El navegador nunca debería tener que cargar con todo el menú solo porque una página necesita saber dónde vive.
¿Buscas la mejor empresa de desarrollo Drupal del mercado? Acabas de encontrarla.
Somos la agencia digital enfocada en Drupal más grande, creada para entregar plataformas rápidas, seguras y escalables, sin concesiones. Desde nuevas construcciones y rediseños hasta migraciones y soporte a largo plazo, nuestros expertos en Drupal entregan resultados de nivel empresarial con atención de boutique.
Reserva una llamada hoy y convirtamos tu hoja de ruta de Drupal en una realidad de alto rendimiento.
Ivan Abramenko, Arquitecto Principal de Drupal
ivan.abramenko@drupalbook.org
projects@drupalbook.org