Views AJAX History toggle

Worum geht es hierbei?

Die Ausgangslage: Moderne Seiten reagieren sofort, aber die Navigation soll trotzdem verlässlich bleiben

Viele Website Frontends arbeiten heute mit dynamischen Inhaltslisten. Nutzer:innen klicken Filter, blättern durch Ergebnisse, passen Sortierungen an. Das passiert oft ohne kompletten Seitenreload. Das fühlt sich schnell an und ist in vielen Fällen genau das, was man will.

Das Problem: Obwohl sich eine Seite so verhält wie eine kleine Anwendung, erwarten Besucher:innen trotzdem, dass die Basics funktionieren.

• Die URL soll zur Ansicht passen, die man gerade sieht.
• Die Zurück-Taste soll das tun, was sie immer tut.
• Und wenn man den Link zu einem Zustand teilt, soll der Empfänger dasselbe sehen.

Das konkrete Problem: Wenn mehrere AJAX-Bereiche die Browser-URL gleichzeitig verändern, entsteht Chaos

„Seit Drupal 10.1 aktualisiert jeder dynamische Inhaltsbereich automatisch die Browser-URL, wenn er sich verändert. Sobald mehrere solche Bereiche auf einer Seite gleichzeitig aktiv sind, überschreiben sie sich gegenseitig. Views AJAX History Toggle gibt Redaktions- und Entwicklungsteams die Kontrolle zurück.“
– Pascal Crott, CTO und Drupal Solution Architect

Seit Drupal 10.1 ist das Verhalten besonders sichtbar. Dynamische Views können bei jeder Änderung automatisch die Browser-URL aktualisieren. Für eine einzelne Hauptliste ist das oft hilfreich. Man kann Filterzustände teilen oder über die Zurück-Taste Schritt für Schritt zurückgehen.

Sobald aber mehrere dynamische Bereiche auf derselben Seite aktiv sind, wird es unberechenbar.

Beispiel: Eine gefilterte Produktliste in der Mitte und eine zusätzliche Filter- oder Suchkomponente in der Seitenleiste. Beide reagieren dynamisch. Beide schreiben bei Änderungen in die Browser-Historie. Am Ende überschreiben sie sich gegenseitig.

Das Ergebnis fühlt sich für Nutzer:innen an wie ein kaputtes System:

• Die URL passt nicht mehr zu dem, was man sieht.
• Ein Klick auf Zurück führt in einen Zwischenzustand statt zur vorherigen Seite.
• Man braucht mehrere Zurück-Klicks, um wirklich wegzukommen.

Views AJAX History Toggle gibt Teams die Kontrolle zurück. Statt dass jede dynamische Ansicht automatisch die Browser-Historie beeinflusst, kann man pro Bereich entscheiden, ob er die URL und die Zurück-Taste mitsteuern darf oder nicht.

Warum war das nötig?

In vielen Projekten entsteht diese Situation nicht, weil jemand etwas „falsch gebaut“ hat, sondern weil Websites heute mehr können sollen.

Eine Seite ist nicht mehr nur ein statischer Text. Sie ist oft eine Kombination aus:

• Hauptliste (Produkte, News, Events)
• sekundären Listen (Empfehlungen, ähnliche Inhalte)
• Filter- und Suchkomponenten in Seitenleisten
• Overlays oder Schiebepanels

Die einzelnen Bausteine funktionieren für sich genommen gut. Das Problem ist das Zusammenspiel. Genau dafür ist dieses Modul da: Es verhindert, dass sich dynamische Bereiche gegenseitig die Navigation kaputt machen.

Was sind die Vorteile?

• Vorhersehbare Nutzerführung: Die Zurück-Taste führt wieder dahin, wo Besucher:innen sie erwarten. Ansichten, die man teilen oder wiederfinden möchte, gehen nicht verloren.
• Stabile URLs für die wichtigen Bereiche: Die Hauptliste darf weiter „teilbare“ Zustände erzeugen. Nebenbereiche stören nicht mehr.
• Mehr Vertrauen: Wenn Navigation und URL sich widersprechen, wirkt das System instabil. Dieses Modul macht das Verhalten wieder logisch und zuverlässig.

Beispiele für die Anwendung

Produktliste plus Seitenleisten-Filter: Schnell filtern, ohne die Navigation zu zerstören

Stell dir eine typische Produkt- oder Content-Seite vor:

• In der Mitte eine große Ergebnisliste, die sich per Filter und Paging aktualisiert.
• In der Seitenleiste eine Suche oder zusätzliche Filter, die ebenfalls dynamisch reagieren.

Beide Bereiche sind für sich sinnvoll. Aber wenn beide gleichzeitig die URL verändern, wird die Browser-Historie unbrauchbar.

Mit Views AJAX History Toggle bleibt die Hauptliste das „Leitsystem“. Sie darf die URL aktualisieren, damit Filterzustände teilbar bleiben. Die Seitenleiste hingegen kann so eingestellt werden, dass sie zwar dynamisch reagiert, aber die URL nicht jedes Mal neu schreibt. Damit bleiben URLs und Zurück-Taste stabil.

Das Ergebnis ist wieder das, was man als Nutzer:in erwartet: eine schnelle Oberfläche mit verlässlicher Navigation.

Weitere Anwendungen im selben Setup

Dasselbe Problem taucht an vielen Stellen auf, ohne dass es im Konzept vorher explizit geplant war:

• Portale mit mehreren Inhaltsbereichen pro Seite: Startseiten mit mehreren dynamischen Teasern, Listen und Filtern.
• Inhalte in Overlays oder Schiebepanels: Dynamische Inhalte sollen reagieren, aber die Seiten-URL soll „die Seite“ bleiben.
• Redaktionsnahe Ansichten: Views im Backend oder in geschützten Bereichen, wo Vorhersehbarkeit wichtiger ist als „bookmarkable“ in jedem Teilbereich.
• Für erweiterte Flexibilität: Falls es notwendig wird, dass ein komplexer AJAX-View sich in unterschiedlichen Kontexten anders verhält und auch die Zurück-Funktion und Verlinkung des aktuellen Standes nicht überall gleich sein darf, kommt unser Modul Better Views Block ins Spiel. Hiermit kann pro Platzierung eines Views festgelegt werden, welche URL-Parameter bei einem AJAX Refresh verändert werden dürfen – redaktionell gesteuert und ohne weiteren Entwicklungsaufwand.

Fazit

Views AJAX History Toggle ist ein kleiner, aber wirksamer Stabilitätsbaustein für moderne Drupal-Seiten.
Wenn mehrere dynamische Views oder AJAX-Bereiche auf einer Seite existieren und die Zurück-Taste nicht mehr so ganz tut, was sie soll, dann lohnt sich dieses Modul.

Erster Schritt: Die Hauptliste auf der Seite identifizieren. Dort soll die URL-Änderung sinnvoll bleiben. Für alle sekundären Bereiche wird das Verhalten gezielt abgeschaltet. Dann den Flow mit echten Nutzeraktionen testen: Filtern, Paging, Zurück, erneut vor, Link teilen.