Uns fehlten bei Divi nicht die responsiven Optionen. Eher das Gegenteil: Divi bietet bereits sehr viele Einstellungen, mit denen sich Typografie, Abstände und Layouts für unterschiedliche Bildschirmgrößen anpassen lassen.

Das eigentliche Problem war die ständige Wiederholung. In jedem Projekt mussten dieselben grundlegenden Entscheidungen erneut getroffen werden. Schriftgrößen brauchten responsive Werte, Sections und Rows eine einheitliche Staffelung, und Inhaltsbreiten mussten vom Smartphone bis zum großen Desktop funktionieren. Dazu kamen Menüs, Formulare, Sidebars und Footer-Widgets mit ihren eigenen Anforderungen.

Natürlich lässt sich das alles von Hand umsetzen. Je größer ein Projekt wird, desto schwieriger wird es aber, alle Werte dauerhaft aufeinander abzustimmen. Kleine Abweichungen sammeln sich an, und eine Änderung, die eigentlich das gesamte Design betreffen sollte, endet schnell in einer langen Liste einzelner Korrekturen.

Die Werte selbst waren nicht das Problem

Unser erstes Ziel war recht überschaubar: Wir wollten fluide Skalen für Typografie und Abstände aus wenigen Minimal- und Maximalwerten erzeugen.

Statt getrennte Werte für Smartphone, Tablet und Desktop festzulegen, passen sich fluide Werte stufenlos an die verfügbare Bildschirmbreite an. Dasselbe Prinzip lässt sich auf Schriftgrößen, Abstände, den Rhythmus von Sections und die Abmessungen von Rows übertragen.

Das Erzeugen dieser Werte war allerdings nur die halbe Miete.

Aus einer Sammlung von Variablen wird noch kein funktionierendes Designsystem. Es muss weiterhin entschieden werden, welcher Wert zu einer Überschrift, einem Button, einem Formularfeld oder einer bestimmten Abstandsrolle gehört. Anschließend müssen diese Zuordnungen auf der gesamten Website umgesetzt werden.

Genau daraus entstand die zentrale Idee hinter Fluid Base für Divi: Das Plugin sollte fluide Werte nicht nur erzeugen, sondern sie auch dort einsetzen, wo sie tatsächlich gebraucht werden.

Automatisieren, ohne der Gestaltung dazwischenzufunken

Die nächste Frage war: Wie lassen sich Werte automatisch anwenden, ohne den Leuten, die mit Divi arbeiten, die Kontrolle wegzunehmen?

Die Werte von Fluid Base sollten sinnvolle Standardwerte liefern. Eigene Werte mussten aber weiterhin möglich bleiben. Einzelne Felder sollten sich vom System lösen oder auch ganz bewusst leeren lassen.

Ein Wert, der noch nie gesetzt wurde, ist schließlich etwas anderes als ein Wert, den jemand absichtlich geändert oder entfernt hat. Eine Automatik muss diesen Unterschied verstehen. Sonst arbeitet sie früher oder später gegen die Person, die die Website gestaltet.

Ein großer Teil der Entwicklung drehte sich deshalb um die Trennung zwischen den von Fluid Base verwalteten Standardwerten und den eigenen Entscheidungen innerhalb von Divi. Kopierte Module, gespeicherte Layouts und bestehende Seiten müssen ihre Einstellungen behalten. Importe und Resets sollen einen sauberen Gesamtzustand herstellen, ohne nebenbei andere Entscheidungen zu überschreiben.

Diese Arbeit ist weniger sichtbar als ein neuer Schalter im Backend, wurde für uns aber zu einem der wichtigsten Teile von Fluid Base. Automatisierung ist nur dann hilfreich, wenn ihr Verhalten nachvollziehbar bleibt.

Divi 4 und Divi 5 brauchen unterschiedliche Wege

Eine weitere große Aufgabe war die Unterstützung von Divi 4 und Divi 5.

Divi 5 besitzt ein natives Variablensystem. Fluid Base kann dort Variablen für Schriftgrößen und Abstände anlegen, die Teil des normalen Builder-Workflows werden. Das ist der direktere Weg, bringt aber auch die Verantwortung mit sich, Variablen, Zuordnungen und lokale Builder-Werte sauber miteinander abzugleichen.

Divi 4 besitzt diese Variablenarchitektur nicht. Dort erzeugt Fluid Base optimiertes CSS, um auf dem Frontend eine vergleichbare responsive Grundlage bereitzustellen.

Das Ziel ist in beiden Divi-Versionen weitgehend dasselbe, der technische Weg dorthin aber nicht. Wir mussten diese Unterschiede berücksichtigen, statt Divi 4 und Divi 5 in dieselbe technische Schublade zu pressen.

Von fluiden Skalen zur Grundlage für ein ganzes Projekt

Am Anfang lag der Schwerpunkt vor allem auf fluider Typografie und fluiden Abständen. Bei der Arbeit an vollständigen Websites wurde schnell klar, dass sich diese Bereiche nicht getrennt voneinander betrachten lassen.

Typografie beeinflusst Zeilenlängen, Modulgrößen und den vertikalen Rhythmus. Section-Abstände bestimmen das Tempo einer Seite. Row-Breiten verändern, wie Typografie und Abstände auf unterschiedlichen Bildschirmen wirken. Und Modul-Standardwerte entscheiden darüber, ob ein neu eingefügtes Element innerhalb des Systems startet oder direkt zur nächsten Ausnahme wird.

Der Umfang von Fluid Base wuchs deshalb nach und nach. Dazu kamen der Rhythmus von Sections und Rows, Layoutbreiten, Modul-Standardwerte und genauere Möglichkeiten, festzulegen, wo die generierten Werte angewendet werden sollen.

Außerdem mussten wir über normale Builder-Layouts hinausdenken. Echte Websites bestehen nicht nur aus perfekt aufgebauten Theme-Builder-Templates. Es gibt klassische WordPress-Inhalte, Sidebars, Footer-Widgets, Suchergebnisse und ältere Bereiche, die trotzdem zum restlichen Design passen sollen. WooCommerce und Contact Form 7 bringen weitere Bereiche mit, die nicht wie ein separates System wirken sollten.

Wiederverwendbare Presets sowie Import und Export waren die logische Fortsetzung. Wenn eine funktionierende Grundlage einmal steht, sollte sie sich in weiteren Projekten nutzen lassen, ohne die gesamte Konfiguration wieder von vorne aufzubauen.

So entwickelte sich Fluid Base schrittweise von einem Generator für responsive Werte zu einer Grundlage für vollständige Divi-Projekte.

Echte Projekte haben unsere Prioritäten verändert

Eine Funktion kann auf einer sauberen Testseite problemlos funktionieren und sich auf einer bestehenden Website trotzdem ganz anders verhalten. Dort trifft sie auf kopierte Builder-Inhalte, ältere Theme-Strukturen, individuelle Anpassungen und weitere Erweiterungen.

Reale Projekte enthalten immer eine Mischung aus aktuellen und älteren Entscheidungen. Sie sind selten so aufgeräumt wie eine frische WordPress-Installation.

Die spätere Entwicklung drehte sich deshalb immer stärker um Grenzen und Ausnahmen: Wann soll Fluid Base einen Wert setzen? Wann muss ein vorhandener Wert unangetastet bleiben? Und wann sollte eine Funktion nur in einem ganz bestimmten Bereich aktiv sein?

Manche Änderungen haben das System erweitert. Andere haben Verhalten eingegrenzt, das anfangs noch zu allgemein war. In mehreren Fällen bestand die bessere Lösung nicht darin, Fluid Base mehr machen zu lassen, sondern genauer festzulegen, wann es nichts tun sollte.

Zuverlässigkeit und Performance gehören dazu

Mit der Zahl der unterstützten Bereiche wurden auch Zuverlässigkeit und Performance wichtiger.

Fluid Base muss Plugin-Einstellungen, Divi-Werte, Builder-Inhalte und die Frontend-Ausgabe miteinander abstimmen. Diese Teile ändern sich nicht immer gleichzeitig. Das Plugin muss sie also zuverlässig zusammenhalten, ohne unnötige Arbeit zu wiederholen oder ausstehende Änderungen zu verlieren.

Wir haben deshalb viel Zeit damit verbracht, wiederholte Verarbeitung zu reduzieren, Caches sinnvoller zu nutzen und die Synchronisierung stabiler zu machen. Ebenso wichtig war die Frage, was bei einem Fehler passiert. Eine Aufgabe sollte nicht nur deshalb als erfolgreich gelten, weil eine Anfrage ohne Absturz beendet wurde. Die vorgesehene Änderung muss auch tatsächlich erfolgt sein.

Einige Performance-Ideen haben wir bewusst nicht umgesetzt. Manche Ansätze klangen in der Theorie effizient, brachten unter realistischen Bedingungen aber keinen messbaren Vorteil. Zusätzliche Komplexität hätte das Plugin lediglich schwerer wartbar gemacht.

Auch das war eine wichtige Erkenntnis aus der Entwicklung: Performance sollte gemessen und nicht einfach behauptet werden.

Was wir über Divi-Erweiterungen gelernt haben

Wir arbeiten seit deutlich mehr als zehn Jahren mit WordPress und verstehen die Zurückhaltung gegenüber Erweiterungen gut.

Ein Plugin kann auf dem Papier sinnvoll aussehen und trotzdem Nebenwirkungen mitbringen, einen eigenen Arbeitsablauf aufzwingen oder am Ende eine weitere Schicht aus Korrekturen erzeugen. Bei der Entwicklung von Fluid Base wurde für uns deshalb immer wichtiger, die vorhandenen Divi-Konzepte zu respektieren.

Der Visual Builder sollte der zentrale Arbeitsbereich bleiben. Native Divi-Systeme sollten dort genutzt werden, wo sie die passende Grundlage bieten. Lokale Werte müssen Vorrang behalten. Und eine Funktion sollte nur den Bereich beeinflussen, für den sie gedacht ist.

Natürlich können wir nicht jede Divi-Erweiterung einzeln testen. Nicht-native Module erhalten außerdem nicht dieselben speziellen Fluid-Base-Einstellungen pro Modul wie native Divi-Module. In Divi 5 lassen sich die Fluid-Base-Variablen aber weiterhin in kompatiblen Feldern anderer Erweiterungen verwenden.

Fluid Base ist deshalb weniger eine lange Liste einzelner Funktionen als eine Reihe klarer Grenzen: Wo wird ein Wert angewendet? Wo sollte er in Ruhe gelassen werden? Was verwaltet das Plugin, und was bleibt eine bewusste Entscheidung innerhalb von Divi?

Eine Grundlage, kein Autopilot

Fluid Base ersetzt weder ein gutes Auge noch gestalterische Entscheidungen.

Es wird weiterhin Situationen geben, in denen eine Überschrift größer sein sollte, eine Section andere Abstände braucht oder eine bewusste Ausnahme das gesamte Layout besser macht.

Fluid Base kann aber einen großen Teil der wiederkehrenden Arbeit darunter abnehmen. Typografie, Abstände und Layout starten mit demselben System. Neue Module erhalten sinnvolle Standardwerte. Klassische WordPress-Bereiche können derselben gestalterischen Logik folgen wie Builder-Layouts. Bewusste Ausnahmen bleiben trotzdem möglich.

Genau deshalb haben wir Fluid Base weiterentwickelt, nachdem die ersten fluiden Skalen längst funktionierten. Responsive Werte zu berechnen war der vergleichsweise einfache Teil. Deutlich schwieriger war es, daraus eine verlässliche Grundlage für echte Divi-Projekte zu machen, ohne den Menschen, die damit arbeiten, die Kontrolle über ihre Gestaltung zu nehmen.