Better Views Block

Worum geht es hierbei?

Die Ausgangslage: Ein Block, viele Kontexte

Man nennt Auflistungen, die auf Webseiten dynamisch und nach bestimmten Kriterien Dinge listen, in Drupal “Views”. In Drupal entstehen viele Seiten aus wiederverwendbaren Bausteinen. Eine Newsübersicht taucht auf der Startseite auf, in einer Rubrik, vielleicht auch als kleiner Teaser in der Sidebar. Ein Eventblock läuft auf mehreren Landingpages. Ein Produktteaser wird an unterschiedlichen Stellen eingebunden.

Das Grundprinzip bleibt gleich, der Kontext ist jedes Mal ein anderer. Und genau deshalb sollen sich Details unterscheiden: Anzahl der Einträge, Sortierung, Layout, Filter.

Das konkrete Problem: Varianten werden zu Kopien und Kopien werden zu Pflegearbeit

Ohne eine saubere Variante pro Platzierung führt das schnell zu einem bekannten Muster: Für jede Seite wird eine eigene Block Konfiguration angelegt. Am Anfang wirkt das pragmatisch. Später wird es teuer und jeder neue View, der ähnliche Inhalte listet und sich nur leicht unterscheidet, benötigt ein Code Deployment, Entwickleraufwände etc.

Sobald sich am Grundprinzip etwas ändert, zum Beispiel am Markup, an Feldern, an einer Filterlogik oder an der Gestaltung, muss jede Variante einzeln angefasst werden. Je mehr Kopien, desto höher der Pflegeaufwand. Und je mehr Pflegeaufwand, desto größer die Chance, dass Konfigurationen auseinanderlaufen und niemand mehr sicher sagen kann, welche Variante wo im Einsatz ist.

Genau hier setzt Better Views Block an.

Warum war das nötig?

Der Hauptnutzen betrifft Redaktionen, Marketing-Teams und andere Editoren: Ohne views_bvb können Views zwar im Layout redaktionell platziert werden, sind dann aber fest so eingestellt, wie sie nunmal vorkonfiguriert wurden. Andere Optionen für Filterung, Sortierung oder Darstellung fehlen.

In Projekten mit vielschichtigen Seitenstrukturen entsteht schnell ein Wildwuchs aus fast identischen Konfigurationen. Das macht Websites träge in der Pflege und fehleranfällig bei Änderungen.

Better Views Block zielt auf einen einfachen Gedanken: Eine Basiskonfiguration bleibt zentral und stabil. Die Abweichungen gehören an den Ort, an dem sie entstehen. Das ist die konkrete Platzierung im Layout.

Was sind die Vorteile?

• Weniger Duplikate in der Konfiguration: Eine Quelle bleibt gepflegt, Varianten entstehen erst bei der Platzierung.
• Schnellere Anpassungen im Alltag: Anzahl, Sortierung oder Filter lassen sich pro Platzierung setzen, ohne die Basiskonfiguration anzufassen.
• Bessere Wartbarkeit bei Änderungen: Wenn sich das Grundprinzip ändert, bleibt der Eingriff zentral statt in vielen Kopien.
• Kontrollierte Flexibilität für Redaktionen: Ihr steuert, welche Optionen im Projekt überhaupt pro Platzierung veränderbar sind.
• Passt zu modernen Bauweisen: Das Prinzip funktioniert auch in Layout Builder, Display Builder und Canvas, wo Inhalte bewusst aus Platzierungen entstehen.
• Weniger Entwicklungsaufwand: Views sind Konfiguration und müssen normalerweise deployt werden. Die platzierten Blöcke hingegen sind reiner Content. Sie können jederzeit redaktionell geändert oder entfernt werden, ohne dass überhaupt ein Entwickler tätig werden muss.

Beispiele für die Anwendung

Newsübersicht im Webauftritt: Setup, Problem, Einsatz, Ergebnis

Eine Organisation veröffentlicht regelmäßig News. Auf der Startseite sollen drei aktuelle Beiträge erscheinen. Auf einer Fachbereichsseite sollen acht Beiträge stehen. Auf der Kampagnenseite soll nach einem Tag gefiltert werden und die Sortierung soll anders ausfallen.

Wenn jede dieser Ausspielungen als eigene Block Konfiguration gebaut wird, entstehen schnell drei fast identische Varianten. Sobald später eine Anpassung am Grundaufbau nötig wird, zum Beispiel ein zusätzliches Feld oder eine veränderte Darstellung, wird aus einer Änderung ein Paket aus mehreren.

Mit Better Views Block wird die Newsübersicht einmal als Basis konfiguriert. Beim Platzieren legt das Team fest, wie viele Einträge erscheinen, welche Filter greifen und welches Layout genutzt wird. Die Basis bleibt stabil, die Varianten bleiben nachvollziehbar an ihrer Platzierung.

Das Ergebnis: weniger Pflegearbeit, weniger Konfigurationskopien, mehr Klarheit.

Ein visuelles Beispiel

In unserem Sites-Projekt für den Gemeinschaftsauftritt der Verbraucherzentralen haben wir das Modul im Einsatz. Hier ein simples Beispiel mit Testinhalt:

Blockkonfiguration

Die Konfigurationsmaske für eine View-Instanz kann beliebig komplex werden. In diesem einfachen Beispiel setzen wir eine eigene Überschrift, stellen die Darstellung als Horizontale Reihe ein und limitieren die Anzahl der Elemente auf drei.

Ergebnis

Beispiel News-Artikel: Oben wurde der View so eingestellt, dass er nur den einen neuesten Inhalt zeigt; beispielsweise als großes Einstiegselement. Unten wurde derselbe View platziert, aber als Liste mit den drei neuesten nebeneinander definiert. Zusätzlich wurde bei der unteren Variante die Überschrift händisch für diese Stelle überschrieben. 

Das Beispiel dient zur Veranschaulichung für views_bvb. Es ist keine Konfiguration notwendig, um die unterschiedlichen Darstellungen zu platzieren; dies kann vollständig redaktionell gepflegt werden.

Weitere Anwendungsmöglichkeiten (Ideen)

• Produktteaser in unterschiedlichen Kontexten: Gleicher Block, einmal mit Preisinformationen, einmal reduziert als Teaser.
• Auflistungen, die je nach Platzierung nach einem unterschiedlichen Tag (Kategorisierung, Taxonomie) gefiltert werden und somit kontextuell passende Inhalte teasern.
• Suchintegration mit Search API: Suchergebnisblöcke folgen derselben Idee und lassen sich pro Platzierung differenzieren.

💡Auch interessant: Wir bauchen views_bvb immer als Standard in neue Projekte ein. Selbst wenn es initial redaktionell nicht benötigt wird, bringt es keine Nachteile, sondern schon die Grundregeln der Views bauen wir darauf auf. Später können wir mit noch weniger Aufwand flexible Views ins System bringen, wenn der Bedarf entsteht.

Fazit

Better Views Block lohnt sich, wenn ein Views Block an mehreren Stellen eingesetzt wird und in der redaktionellen Arbeit immer wieder Bedarf für weitere Varianten entsteht. Das ermöglicht beispielsweise eine viel schnellere Erstellung von Landing Pages, Kampagnenseiten oder Inhaltsseiten aller Art. Es verkürzt die "time to market" und bringt Redaktionsteams ungeahnte Freiheit.

• Indikator für einen passenden Use Case: Ihr erkennt Bedarf oft daran, dass ihr bei einem Block Formulierungen nutzt wie: „Auf der Startseite kurz, im Bereich ausführlicher“ oder „Gleiche Liste, aber andere Sortierung und Anzahl“. Sobald dieselbe View an zwei Stellen unterschiedlich wirken soll, entsteht schnell Variantenbedarf.
• Erster Schritt: Sammelt die wiederkehrenden Blocks, die heute als Kopien existieren. Notiert pro Platzierung, was sich unterscheidet: Anzahl, Sortierung, Filter, Layout. Daraus ergibt sich sehr schnell, ob eine zentrale Basis mit Varianten pro Platzierung zu euch passt.

Auf Wunsch unterstützt erdfisch dabei im Rahmen eines Projekt-Audits oder auch bei einer geplanten Übernahme der Betreuung.