Wie man riesige Menüs in Drupal pflegt
Einmal öffnete ich ein Drupal-Menü mit mehreren tausend Links und sah zu, wie der Browser vor mir aufgab. Die Seite wurde technisch gesehen geladen. Danach fühlte sich jeder Klick an, als würde man einen alten Drucker bitten, seine Gefühle zu erklären.
Beginnen Sie mit BigMenu und Menu Select
Wenn eine Drupal-Website ein großes redaktionelles Menü hat, ist das erste Problem meistens nicht die Architektur. Es ist die Editor-Oberfläche. Die Menüverwaltungsseite des Drupal-Kerns kann schmerzhaft werden, wenn das Menü auf Tausende von Links anwächst. BigMenu löst das, indem es die Art verändert, wie Redakteure das Menü durchsuchen und verwalten: Statt den vollständigen Baum auf die Seite zu zwingen, können Teilbäume per AJAX geöffnet werden, wenn der Redakteur sie braucht. https://www.drupal.org/project/bigmenu
Das klingt nach einer Kleinigkeit, bis man die Standard-Menüoberfläche auf einer großen Website benutzt hat. Ein eingeklappter Baum tut trotzdem weh, wenn Drupal ihn vollständig aufbauen musste, bevor die Seite nutzbar wurde. Der Wert von BigMenu liegt darin, dass diese frühe Massenladung vermieden wird. Der Redakteur sieht den Teil des Baums, den er angefordert hat, nicht den gesamten Wald. https://www.drupal.org/project/bigmenu
Menu Select löst ein anderes Ärgernis. In Inhaltsformularen müssen Redakteure häufig einen übergeordneten Menüpunkt auswählen. Bei einem großen Menü ist eine normale Auswahlliste absurd. Niemand möchte durch Tausende von Einträgen scrollen, nur um eine Seite unter dem richtigen übergeordneten Punkt zu platzieren. Menu Select ersetzt diese Erfahrung durch eine besser nutzbare Hierarchie und kann Autovervollständigung hinzufügen, sodass der Redakteur nach dem übergeordneten Link suchen kann, statt das gesamte Menü von Hand zu durchforsten. https://www.drupal.org/project/menu_select
Ich mag diese Trennung. BigMenu hilft, wenn man das Menü selbst verwaltet. Menu Select hilft, wenn man Inhalte mit dem Menü verknüpft. Sie werden leicht verwechselt, weil beide die Menü-UX betreffen, aber sie beheben unterschiedliche Momente im redaktionellen Arbeitsablauf.
Menu Select Ajax: die Auswahl laden, wenn der Redakteur sie braucht
Menu Select mit Autovervollständigung ist bereits ein großer Schritt nach vorn. Aber auf sehr großen Websites kann selbst ein besseres Widget noch zu schwergewichtig sein, wenn das Formular versucht, zu viele Menüdaten vorzubereiten, bevor der Redakteur überhaupt etwas tut. Genau hier ergibt ein AJAX-basiertes Muster für die Menüauswahl Sinn.
Die Idee ist einfach: Das Formular sollte beim ersten Laden keinen vollständigen übergeordneten Selektor für ein riesiges Menü aufbauen. Es sollte warten. Wenn der Redakteur ein Menü auswählt, einen Suchbegriff eingibt oder einen Zweig öffnet, kann Drupal eine kleine AJAX-Anfrage stellen und nur den passenden Teil des Menüs zurückgeben. Drupals Form API unterstützt dieses Muster durch AJAX-fähige Formularelemente, bei denen eine Benutzeraktion einen serverseitigen Neuaufbau auslöst und nur der ausgewählte Teil des Formulars ersetzt wird. https://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-forms
In der Praxis hat eine AJAX-Menüauswahl normalerweise zwei Ebenen. Die erste Ebene ist der sichtbare Selektor: ein Suchfeld, eine übergeordnete Auswahl oder ein kleiner aufklappbarer Zweig. Die zweite Ebene ist der gespeicherte Wert: die tatsächliche Plugin-ID des Menülinks oder die übergeordnete Referenz, die Drupal benötigt, wenn das Formular gespeichert wird.
Diese Unterscheidung ist wichtig. Redakteure sollten mit Labels, Pfaden und vertrauten Seitentiteln arbeiten. Drupal sollte stabile maschinenlesbare Werte speichern. Wenn diese beiden Anliegen vermischt werden, werden Widgets für große Menüs fragil. Man sieht doppelte Labels, unklare übergeordnete Auswahlmöglichkeiten und langsame Formular-Neuaufbauten.
Ein guter AJAX-Menüauswahl-Flow fühlt sich fast langweilig an. Der Redakteur beginnt, einen Teil eines Titels einzugeben. Drupal gibt eine kurze Liste möglicher übergeordneter Links zurück, idealerweise mit genügend Kontext, um identische Titel auseinanderzuhalten. Der Redakteur wählt einen aus. Das Formular speichert den ausgewählten Menülink im Hintergrund. Keine riesige Auswahlliste. Kein Rendern des vollständigen Baums. Kein Browser-Zusammenbruch.
Dasselbe Muster funktioniert für aufklappbare Zweige. Zuerst wird die oberste Ebene angezeigt. Wenn der Redakteur einen übergeordneten Punkt öffnet, werden dessen untergeordnete Elemente abgerufen. Wenn er ein weiteres Kindelement öffnet, wird die nächste Ebene abgerufen. So sollte sich die Oberfläche verhalten, wenn die Datenmenge groß ist: kleine Anfrage, kleine Antwort, klare nächste Aktion.
Bei 10.000 Menüpunkten: nicht mehr vorwärts laden
Sobald ein Menü etwa 10.000 Einträge erreicht, denke ich nicht mehr daran wie an ein normales Drupal-Menü. Technisch gesehen ist es immer noch ein Menü. Operativ ist es eher ein Inhaltsindex mit Baumstruktur.
Der häufige Fehler besteht darin, an der Wurzel zu beginnen, den gesamten Baum zu laden, den aktiven Pfad aufzuklappen und dann den größten Teil des Ergebnisses wegzuwerfen. Das funktioniert bei kleinen Menüs. Bei einem riesigen Menü ist es der falsche Weg herum.
Der bessere Ansatz, den ich verwendet habe, war rückwärts gerichtetes Laden. Beginnen Sie mit dem aktiven Menülink der aktuellen Seite. Laden Sie von dort aus nur dessen übergeordnete Elemente. Das liefert den aktiven Pfad, ohne Drupal aufzufordern, jeden nicht verwandten Zweig aufzubauen. Drupals Menü-APIs unterstützen diese Bewegungsrichtung: Der Menülink-Manager kann Links anhand der Route finden und stellt außerdem übergeordnete IDs für ein Menülink-Plugin bereit. 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
Das verändert das Kostenprofil vollständig. Ein riesiges Menü kann 10.000 Einträge haben, aber der aktive Pfad einer Seite ist normalerweise kurz. Vielleicht fünf Ebenen. Vielleicht sieben. Selbst ein tiefer Katalog hat selten Dutzende von Vorfahren für einen einzelnen Eintrag. Statt also 10.000 Links zu laden, um einen Pfad zu finden, lädt man den aktiven Eintrag und geht nach oben.
Danach kann man entscheiden, wie viel umgebende Navigation die Seite wirklich braucht. Manchmal reicht der Elternpfad aus. Manchmal braucht man zusätzlich die Kinder des aktiven Eintrags. Manchmal braucht man Geschwister auf einer Ebene für ein Bereichsmenü. In Ordnung. Laden Sie diese Ausschnitte gezielt. Lassen Sie nicht zu, dass „wir brauchen Navigation“ stillschweigend zu „lade den gesamten Baum bei jeder Anfrage“ wird.
Drupals Menübaumsystem denkt bereits in Begriffen von Baumparametern, aktiven Pfaden und Transformationen. Der übliche Ansatz zum Laden von Bäumen kann Links entlang des aktuellen aktiven Pfads aufklappen, was bei normalen Menüs nützlich ist. https://api.drupal.org/api/drupal/core%21lib%21Drupal%21Core%21Menu%21MenuLinkTreeInterface.php/interface/MenuLinkTreeInterface/8.2.x Bei einem sehr großen Menü bin ich jedoch lieber strenger. Zuerst den aktiven Link finden. Dann seine übergeordneten Elemente laden. Danach nur den Zweig laden, der für die aktuelle Seite benötigt wird.
Die eigentliche Wartungsregel: Lassen Sie Redakteure nie für das gesamte Menü bezahlen
Riesige Drupal-Menüs sind nicht nur ein Rendering-Problem. Sie sind ein redaktionelles Problem, ein Problem beim Aufbau von Formularen, ein Cache-Problem und manchmal ein Problem der Informationsarchitektur, das jemand drei Jahre lang aufgeschoben hat.
BigMenu hilft Redakteuren, mit großen Bäumen zu arbeiten, ohne alles auf einmal zu öffnen. https://www.drupal.org/project/bigmenu Menu Select macht die Auswahl übergeordneter Elemente erträglich, insbesondere mit Autovervollständigung. https://www.drupal.org/project/menu_select AJAX-Auswahl verhindert, dass Formulare Tausende von Optionen vorbereiten, bevor der Redakteur den ersten sinnvollen Klick gemacht hat. https://www.drupal.org/docs/develop/drupal-apis/javascript-api/ajax-forms
Für die Frontend-Navigation ist rückwärts gerichtetes Laden der Teil, den ich am entschiedensten schützen würde. Beginnen Sie mit dem aktiven Menülink. Laden Sie nur übergeordnete Elemente. Fügen Sie Kinder oder Geschwister nur hinzu, wenn das Design sie wirklich benötigt. Allein diese Gewohnheit verhindert, dass ein Menü mit 10.000 Einträgen jede Anfrage in eine Bestrafung verwandelt.
Der Browser sollte niemals das gesamte Menü tragen müssen, nur weil eine Seite wissen muss, wo sie lebt.
Suchen Sie das beste Drupal-Entwicklungsunternehmen auf dem Markt? Sie haben es gerade gefunden.
Wir sind die größte auf Drupal fokussierte Digitalagentur, geschaffen, um schnelle, sichere und skalierbare Plattformen ohne Kompromisse zu liefern. Von Neuentwicklungen und Redesigns bis hin zu Migrationen und langfristigem Support liefern unsere Drupal-Experten Ergebnisse auf Enterprise-Niveau mit der Aufmerksamkeit einer Boutique-Agentur.
Buchen Sie noch heute einen Termin, und lassen Sie uns Ihre Drupal-Roadmap in eine leistungsstarke Realität verwandeln.
Ivan Abramenko, Principal Drupal Architect
ivan.abramenko@drupalbook.org
projects@drupalbook.org