Come mantenere menu enormi in Drupal
Una volta ho aperto un menu Drupal con diverse migliaia di link e ho guardato il browser arrendersi prima di me. La pagina si è caricata, tecnicamente. Poi ogni clic sembrava come chiedere a una vecchia stampante di spiegare i propri sentimenti.
Inizia con BigMenu e Menu Select
Se un sito Drupal ha un grande menu editoriale, di solito il primo problema non è l’architettura. È la schermata dell’editor. La pagina di amministrazione dei menu del core può diventare dolorosa quando il menu cresce fino a contenere migliaia di link. BigMenu affronta questo problema cambiando il modo in cui gli editor navigano e gestiscono il menu: invece di forzare l’intero albero nella pagina, consente di aprire i sottoalberi tramite AJAX quando l’editor ne ha bisogno. https://www.drupal.org/project/bigmenu
Sembra una cosa da poco finché non hai usato l’interfaccia menu predefinita su un sito grande. Un albero collassato fa comunque male se Drupal ha dovuto costruirlo tutto prima che la pagina diventasse utilizzabile. Il valore di BigMenu sta nel fatto che evita quel caricamento massiccio iniziale. L’editor vede la parte dell’albero che ha richiesto, non l’intera foresta. https://www.drupal.org/project/bigmenu
Menu Select risolve un fastidio diverso. Nei form dei contenuti, gli editor devono spesso scegliere una voce di menu padre. Con un menu grande, una normale lista di selezione è assurda. Nessuno vuole scorrere migliaia di elementi solo per posizionare una pagina sotto il padre corretto. Menu Select sostituisce quell’esperienza con una gerarchia più usabile e può aggiungere l’autocompletamento, così l’editor può cercare il link padre invece di andare a caccia manualmente nell’intero menu. https://www.drupal.org/project/menu_select
Mi piace questa separazione. BigMenu aiuta quando si gestisce il menu stesso. Menu Select aiuta quando si collega il contenuto al menu. È facile confonderli perché entrambi toccano la UX dei menu, ma risolvono momenti diversi del flusso di lavoro editoriale.
Menu Select Ajax: caricare la scelta quando serve all’editor
Menu Select con autocompletamento è già un grande passo avanti. Ma su siti molto grandi, anche un widget migliore può essere ancora troppo pesante se il form prova a preparare troppi dati del menu prima che l’editor faccia qualsiasi cosa. È qui che ha senso un modello di selezione menu basato su AJAX.
L’idea è semplice: il form non dovrebbe costruire un selettore completo dei padri per un menu enorme al caricamento iniziale. Dovrebbe aspettare. Quando l’editor sceglie un menu, digita un termine di ricerca o apre un ramo, Drupal può effettuare una piccola richiesta AJAX e restituire solo la parte corrispondente del menu. La Form API di Drupal supporta questo modello tramite elementi di form abilitati ad AJAX, in cui un’azione dell’utente attiva una ricostruzione lato server e viene sostituita solo la parte scelta del form. https://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-forms
In pratica, una selezione menu AJAX di solito ha due livelli. Il primo livello è il selettore visibile: un campo di ricerca, un selettore del padre o un piccolo ramo espandibile. Il secondo livello è il valore memorizzato: l’effettivo ID del plugin del link di menu o il riferimento al padre di cui Drupal ha bisogno quando il form viene salvato.
Questa distinzione conta. Gli editor dovrebbero lavorare con etichette, percorsi e titoli di pagina familiari. Drupal dovrebbe memorizzare valori macchina stabili. Quando queste due esigenze si mescolano, i widget per menu grandi diventano fragili. Compaiono etichette duplicate, scelte del padre poco chiare e ricostruzioni lente del form.
Un buon flusso di selezione menu AJAX sembra quasi noioso. L’editor inizia a digitare parte di un titolo. Drupal restituisce una breve lista di possibili link padre, preferibilmente con abbastanza contesto da distinguere titoli identici. L’editor ne sceglie uno. Il form memorizza il link di menu selezionato dietro le quinte. Nessuna lista di selezione gigantesca. Nessun rendering dell’intero albero. Nessun collasso del browser.
Lo stesso modello funziona per i rami espandibili. Mostra prima il livello superiore. Quando l’editor apre un padre, recupera i figli di quel padre. Se apre un altro figlio, recupera il livello successivo. È così che l’interfaccia dovrebbe comportarsi quando il set di dati è grande: piccola richiesta, piccola risposta, prossima azione chiara.
A 10.000 voci di menu, smetti di caricare in avanti
Quando un menu raggiunge qualcosa come 10.000 voci, smetto di considerarlo un normale menu Drupal. Tecnicamente, è ancora un menu. Operativamente, è più vicino a un indice di contenuti con forma ad albero.
L’errore comune è partire dalla radice, caricare l’intero albero, espandere il percorso attivo e poi buttare via la maggior parte del risultato. Funziona sui menu piccoli. Su un menu enorme, è il contrario di ciò che serve.
L’approccio migliore che ho usato è stato il caricamento all’indietro. Parti dal link di menu attivo per la pagina corrente. Da lì, carica solo i suoi padri. Questo ti dà il percorso attivo senza chiedere a Drupal di costruire ogni ramo non correlato. Le API dei menu di Drupal supportano questa direzione di navigazione: il gestore dei link di menu può trovare i link per route ed espone anche gli ID dei padri per un plugin di link di 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
Questo cambia completamente il profilo dei costi. Un menu enorme può avere 10.000 voci, ma il percorso attivo di una pagina di solito è breve. Magari cinque livelli. Magari sette. Anche un catalogo profondo raramente ha decine di antenati per un singolo elemento. Quindi, invece di caricare 10.000 link per scoprire un percorso, carichi l’elemento attivo e risali verso l’alto.
Dopo, puoi decidere di quanta navigazione circostante abbia davvero bisogno la pagina. A volte il percorso dei padri è sufficiente. A volte servono anche i figli dell’elemento attivo. A volte servono i fratelli a un livello per un menu di sezione. Va bene. Carica quei frammenti deliberatamente. Non lasciare che “ci serve la navigazione” diventi silenziosamente “carica l’intero albero a ogni richiesta”.
Il sistema degli alberi di menu di Drupal ragiona già in termini di parametri dell’albero, percorsi attivi e trasformazioni. Il normale approccio di caricamento dell’albero può espandere i link lungo il percorso attivo corrente, cosa utile sui menu normali. https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21MenuLinkTreeInterface.php/interface/MenuLinkTreeInterface/8.2.x Su un menu molto grande, però, preferisco essere più rigoroso. Prima trova il link attivo. Poi carica i suoi padri. Poi carica solo il ramo necessario per la pagina corrente.
La vera regola di manutenzione: non far mai pagare agli editor il costo dell’intero menu
I menu Drupal enormi non sono solo un problema di rendering. Sono un problema editoriale, un problema di costruzione dei form, un problema di cache e a volte un problema di architettura dell’informazione che qualcuno ha rimandato per tre anni.
BigMenu aiuta gli editor a lavorare con alberi grandi senza aprire tutto in una volta. https://www.drupal.org/project/bigmenu Menu Select rende tollerabile la selezione del padre, specialmente con l’autocompletamento. https://www.drupal.org/project/menu_select La selezione AJAX impedisce ai form di preparare migliaia di scelte prima che l’editor abbia fatto il primo clic significativo. https://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-forms
Per la navigazione front-end, il caricamento all’indietro è la parte che proteggerei con più decisione. Parti dal link di menu attivo. Carica solo i padri. Aggiungi figli o fratelli solo quando il design ne ha davvero bisogno. Questa singola abitudine impedisce a un menu da 10.000 voci di trasformare ogni richiesta in una punizione.
Il browser non dovrebbe mai dover portare l’intero menu solo perché una pagina deve sapere dove si trova.
Cerchi la migliore azienda di sviluppo Drupal sul mercato? L’hai appena trovata.
Siamo la più grande agenzia digitale focalizzata su Drupal, creata per realizzare piattaforme veloci, sicure e scalabili, senza compromessi. Da nuove realizzazioni e redesign a migrazioni e supporto a lungo termine, i nostri esperti Drupal consegnano risultati di livello enterprise con un’attenzione da boutique.
Prenota una chiamata oggi e trasformiamo la tua roadmap Drupal in una realtà ad alte prestazioni.
Ivan Abramenko, Principal Drupal Architect
ivan.abramenko@drupalbook.org
projects@drupalbook.org