Conditions

Worum geht es hierbei?

Die Ausgangslage: Regeln tauchen überall auf

Im Alltag entstehen immer wieder Anforderungen, die mit einer einfachen Regel beginnen.

Beispiele:

• Ein Hinweis soll nur für Besucher aus Deutschland sichtbar sein.
• Ein Element soll nur auf der Startseite erscheinen.
• Eine Information soll nur für eingeloggte Nutzer sichtbar sein.
• Eine Warnung soll nur für 2 Wochen erscheinen.

Solche Anforderungen betreffen sehr unterschiedliche Stellen: ein Banner, ein Formularfeld, ein Textbaustein, eine ganze Komponente. Inhaltlich sind sie ähnlich. Technisch landen sie oft in unterschiedlichen Ecken des Projekts.

Das konkrete Problem: Ein Flickenteppich aus Regeln kostet Überblick und Pflege

Wenn Regeln an jeder Stelle anders umgesetzt werden, entsteht über Zeit ein unübersichtliches System. Eine Regel wird im Layout umgesetzt, eine andere über eine Zusatzkonfiguration, die nächste als Checkbox im Formular.

Für Teams hat das spürbare Folgen:

• Niemand sieht auf Anhieb, wo welche Regel greift.
• Änderungen brauchen mehr Abstimmung, weil jede Stelle anders funktioniert.
• Fehler bleiben länger unentdeckt, weil die Logik verteilt ist.

Wie löst Conditions das?

Drupal Projekte entwickeln sich. Es entstehen neue Anforderungen, neue Bereiche, neue Werkzeuge, sogar neue Webseiten oder Kampagnenseiten. Und mit ihnen kommen neue Regeln.

Das Konzept der Bedingungen (Conditions) selbst bringt Drupal im Kern bereits mit. Unser Modul Conditions setzt genau hier an: Es nutzt die bestehende API und macht sie überall dort im Projekt konfigurierbar, wo sie gebraucht wird. Das Feature ist nun nicht mehr nur an einzelnen, fest programmierten Stellen verfügbar. Aus einer Grundlage, die in Core meist Entwickler:innen vorbehalten ist, wird so eine zentrale, redaktionell nutzbare Grundlage, die andere Lösungen mitverwenden, wenn sie Dinge bedingungsabhängig steuern.

Ein Unterschied zum Core-Standard: Bedingungen werden dort in der Regel nur UND-verknüpft. Bei uns ist einstellbar, ob Bedingungen UND- oder ODER-verknüpft gelten sollen – oder auch komplexere Kombinationen daraus.

Für Redaktionsteams bedeutet das: Egal in welchem Werkzeug sie einer Regel begegnen, die Logik sieht gleich aus und verhält sich gleich.

Was sind die Vorteile?

• Weniger Sonderlogik im Projekt: Regeln werden als wiederverwendbarer Baustein umgesetzt statt als Einzellösungen.
• Bessere Wartbarkeit: Eine Logik wird gepflegt, getestet und verstanden, statt viele Varianten.
• Konsistente Bedienung für Redaktionen: Regeloberflächen folgen einem gemeinsamen Muster, auch wenn sie in unterschiedlichen Features auftauchen. Sie werden immer an der gleichen Stelle gesetzt und gepflegt.
• Flexible Verknüpfung: Regeln lassen sich je nach Bedarf UND- oder ODER-verknüpfen, statt wie im Core-Standard nur UND-verknüpft zu sein.
• Schnelleres Bauen neuer Werkzeuge: Lösungen, die „zeige oder verstecke etwas, wenn“ brauchen, können auf der Grundlage aufsetzen. Das gilt auch für ganze Module.
• Leicht erweiterbar für Entwickler:innen: Eigene Condition Plugins lassen sich mit rund 3 Zeilen Code anbinden. Dabei legt man einzeln fest, was davon redaktionell einstellbar sein soll und was nicht.
• Konsistenz bleibt auch hier: Viele Contrib-Module bringen bereits jetzt Conditions mit. Diese funktionieren automatisch mit unserem Modul.

Beispiele für die Anwendung

Slots mit Regeln: Setup, Problem, Einsatz, Ergebnis

Auf der deutschen Version eines internationalen B2C-Shopsystems soll eine Rabatt-Aktion nur für eingeloggte User in einem bestimmten Monat erscheinen.

Hier sind die folgenden Regeln drin versteckt:

• nur auf der deutschen Shop-Site
• nur für eingeloggte User
• nur im benannten Zeitraum

Ohne eine zentrale Bedingungslogik wäre zunächst ein Konzept erforderlich, an welcher Stelle das zu definieren sei. Möglicherweise würde die Lösung an einer unerwarteten Stelle oder gar als Konfiguration mit der Notwendigkeit eines Deployments und mit Kosten für Entwickleraufwände realisiert werden.

Mit Conditions als Grundlage kann Slots diese Bedingungen überall gleich und wiedererkennbar auf dem Contentformular anbieten. Redaktionsteams konfigurieren Regeln in einem vertrauten Muster, unabhängig davon, ob es um einen Kampagnenhinweis, einen regionalen Textbaustein oder ein zeitlich begrenztes Banner geht.

Das Ergebnis: mehr Tempo im Betrieb und eine Logik, die langfristig stabil bleibt.

Ein grafisches Beispiel

Linke Seite: Die Liste der Conditions. Durch das Modul "Plugin Form Element" wird dafür gesorgt, dass an dieser Stelle auf jedem passenden Content-Formular wiedererkennbar die Elemente für die Conditions erscheinen. Conditions stellt die konfigurierbaren Bedingungen zur Verfügung. Fürs Redaktionsteam ist das alles contentseitig ohne Entwickler:innen einstellbar.

Hier im Beispiel wurde eine sprachbasierte Logik und eine nach Zeit gesetzt. Beispiele für weitere sind sichtbar – das ist selbstverständlich konfigurier- und erweiterbar.

Verwandte Module

Conditions ist eins der wichtigsten Module für komplexe Drupal-Systeme bei uns. Es ist Voraussetzung für das äußerst vielseitige Slots-Modul (coming soon) und setzt seinerseits Plugin Form Element voraus.

Die Abgrenzung dazu: Plugin Form Element macht das grundsätzlich für jede Plugin-Form nutzbar, unabhängig davon, um welche Art von Plugin es geht. Conditions dagegen kümmert sich um eine ganz bestimmte Art von Plugin, die es in Drupal Core bereits gibt: die Bedingungen selbst. Daher die Abhängigkeit von Plugin Form Element, um Conditions im Gin Backend einheitlich und wiederverwendbar bedienbar zu machen.

Abhängigkeiten werden bei der Installation solcher Module normalerweise mit installiert. Redaktionen und Content-Verantwortliche bemerken von den technischen Komplexitäten nichts. Für sie erweitern sich nur die Features um einige immens hilfreiche.

Fazit

Conditions lohnt sich, wenn im Projekt immer wieder Regeln für Sichtbarkeit oder Ausspielung auftauchen, die zentralisiert redaktionell eingestellt werden sollen. Es bietet eine konsistente UX für den Umgang mit Bedingungen, unabhängig davon, wer sie konsumiert.

• Indikator für einen passenden Use Case: Kommen häufig Sätze auf wie: „Das gilt nur auf diesen Seiten“ oder „Das gilt nur für diese Nutzergruppe“ oder „Das soll nach zwei Wochen weg sein“? Sobald solche Anforderungen in mehreren Bereichen auftauchen, lohnt sich eine gemeinsame Grundlage.
• Erster Schritt: die Stellen im Projekt sammeln, an denen heute bereits Regeln existieren. Zum Beispiel im Layout, in Formularen oder in individuellen Konfigurationen. Daraus wird sichtbar, wo eine einheitliche Logik sofort Wirkung entfaltet. 
  Das Modul kann kostenfrei installiert und genutzt werden. Auf Wunsch berät erdfisch in Sachen Web und Drupal von A bis Z.