Hyvä-Theme-Farben im Admin ändern, ganz ohne Code

Hyvä-Themes werden mit Tailwind CSS gebaut. Farben, Schriften und Abstände sind als Design-Tokens in der Tailwind-Konfiguration des Themes definiert. Beim Build schreibt Tailwind nur die Klassen, die die Templates tatsächlich verwenden, in ein einziges kleines Stylesheet.

Die Header- und Markenfarben unseres Hyvä-Demo-Shops lassen sich unter Stores > Configuration ändern.

Das ist gut für die Performance. Es bedeutet aber auch: Eine Farbänderung ist eine Code-Änderung. Jemand bearbeitet die Konfiguration, baut das CSS neu und deployt. Für ein Marketing-Team, das für ein Sale-Wochenende einen dunkleren Header möchte, ist das zu langsam.

Dieser Beitrag zeigt, wie wir das gelöst haben und wo die Grenzen liegen.

Wo Hyvä-Farben normalerweise liegen

In einem Hyvä-Child-Theme liegt die Tailwind-Konfiguration im web/tailwind Ordner. Er definiert benannte Farben wie primary und secondary. Templates verwenden dann Klassen wie bg-primary oder text-secondary.

Der Build-Schritt durchsucht die Templates, findet die verwendeten Klassen und erzeugt das CSS. Diese Pipeline erklären wir in Tailwind in Hyvä: Design-Tokens und die Build-Pipeline.

Da die Farbwerte in das erzeugte CSS geschrieben werden, muss für eine Änderung der Build erneut laufen. Im Produktionsmodus bedeutet das zusätzlich einen Deploy.

Die Idee: Tokens verweisen auf CSS-Variablen

CSS Custom Properties, oft CSS-Variablen genannt, lösen das elegant. Statt eines festen Hex-Werts verweist ein Tailwind-Token auf eine Variable. Das Stylesheet bleibt gleich, nur der Wert der Variable ändert sich.

Der Wert der Variable stammt aus der Magento-Konfiguration. Ein kleiner Block im Seitenkopf liest die konfigurierten Farben aus und gibt sie als Variablen aus.

<style>
:root {
  --brand-header-bg: <?= $escaper->escapeCss($headerBg) ?>;
  --brand-primary: <?= $escaper->escapeCss($primary) ?>;
}
</style>

Templates verwenden die Variable über die Tokens oder über die Arbitrary-Value-Syntax von Tailwind, zum Beispiel bg-[var(--brand-header-bg)]. Jedes Element, das das Token verwendet, übernimmt den neuen Wert automatisch.

Die Standardwerte bleiben in den Theme-Dateien. Setzt niemand im Admin eine Farbe, sieht das Theme genau so aus wie gestaltet.

Was das Team im Admin sieht

Wir fügen unter Stores > Configuration einen Bereich mit den Farben hinzu, deren Änderung sinnvoll ist. In den meisten Shops ist das eine kurze Liste:

• Header-Hintergrund und Header-Text.
• Primäre Markenfarbe für Buttons und Links.
• Sekundär- oder Akzentfarbe für Badges und Hervorhebungen.
• Farbe der Top-Bar oder Ankündigungsleiste.

Jedes Feld akzeptiert einen Hex-Farbwert, der vor dem Speichern validiert wird. Ein Tippfehler darf nie die Storefront beschädigen.

Da es sich um normale Magento-Konfigurationsfelder handelt, funktionieren sie pro Website und pro Store View. Eine deutsche Store View kann eine andere Header-Farbe haben als die englische. Das passt gut zum Setup aus mehrsprachigen Hyvä-Shops.

Nach dem Speichern leert das Team den Full-Page-Cache im Admin, und die neuen Farben sind live. Kein Rebuild und kein Deploy nötig.

So bauen wir es auf, Schritt für Schritt

1. Mit dem Team abstimmen, welche Farben es wirklich ändern muss.
2. Diese Felder in einem kleinen Modul zu einem Konfigurationsbereich hinzufügen, mit sinnvollen Standardwerten.
3. Die passenden Tailwind-Tokens im Child-Theme auf CSS-Variablen verweisen lassen.
4. Einen Head-Block hinzufügen, der die konfigurierten Werte als Variablen ausgibt, für CSS escaped.
5. Fest codierte Farbklassen in Header und Buttons durch die Tokens ersetzen.
6. Jede Store View mit den Standardfarben und mit geänderten Farben testen.

Der Aufwand ist gering, betrifft aber Header, Buttons und Links auf jeder Seite. Deshalb testen wir es vor dem Livegang auf Staging, wie jede andere Theme-Änderung.

Was bewusst im Code bleibt

Nicht jede Farbe sollte bearbeitbar sein. Wer einem Team zwanzig Farbwähler gibt, verliert schnell das Design.

Diese Werte behalten wir in den Theme-Dateien:

• Neutrale Grautöne und Rahmen. Sie halten das Layout zusammen und müssen sich selten ändern.
• Statusfarben. Fehler-, Warn- und Erfolgsfarben tragen in Formularen und im Checkout eine Bedeutung.
• Schriften und Abstände. Sie gehören zum Designsystem, nicht zu einer Kampagne.

Diese Tokens werden beim Deploy aus den Theme-Dateien neu erzeugt, wie jede andere Code-Änderung. Die Aufteilung ist einfach: Markenmomente im Admin, Struktur im Code.

Kontrast und Barrierefreiheit

Eine bearbeitbare Farbe kann auch zu einer unlesbaren Farbe werden. Weißer Text auf hellgelbem Header sieht für die Person, die ihn auf einem großen Monitor ausgewählt hat, gut aus. Auf einem Smartphone im Sonnenlicht ist er schwer zu lesen.

Wir lösen das auf zwei Wegen. Zu jedem Hintergrundfeld gibt es ein passendes Feld für die Textfarbe, sodass das Team beide als Paar wählt. Außerdem empfehlen wir, jedes neue Paar vor dem Speichern mit einem Kontrast-Checker zu prüfen.

Mehr zu diesem Thema finden Sie in Barrierefreiheit in Hyvä-Themes.

Beeinflusst das die Performance?

Nein, jedenfalls nicht messbar. Die Variablen fügen dem Seitenkopf ein paar Zeilen Inline-CSS hinzu. Das Haupt-Stylesheet bleibt eine kleine, gecachte Datei.

Die Seite ist weiterhin vollständig cachebar. Die Farbwerte sind Teil des gecachten HTML jeder Store View, deshalb muss der Full-Page-Cache nach einer Änderung geleert werden.

Dieser Ansatz ist Teil dessen, wie wir Hyvä-Shops nach dem Launch einfach betreibbar halten. Auch unser Demo-Shop nutzt ihn, zusammen mit dem Speed-Setup aus unserem Hyvä-vs.-Luma-Benchmark.

FAQ

Können wir auch Schriften im Admin ändern?

Technisch ist das mit demselben Variablen-Ansatz möglich. Schriften behalten wir in der Regel im Code, weil eine Schriftänderung auch Zeilenhöhe, Abstände und Ladezeit beeinflusst.

Überschreibt ein Hyvä-Update unsere Admin-Farben?

Nein. Die Werte sind in der Magento-Konfiguration gespeichert, und die Logik liegt in Ihrem Child-Theme oder einem kleinen Modul. Hyvä-Updates berühren beides nicht.

Können wir eine Farbänderung für eine Kampagne zeitlich planen?

Standardmäßig nicht, da die Magento-Konfiguration keine Zeitsteuerung kennt. Bei häufigen Kampagnen lässt sich das mit einem kleinen Modul ergänzen. Für vollständige Kampagnenseiten ist unsere Mage-PageBuilder-Blockbibliothek meist das bessere Werkzeug.

Sie möchten ein Hyvä-Theme, das Ihr Team ohne Entwickler anpassen kann? Werfen Sie einen Blick auf unsere Hyvä-Theme-Entwicklung und Mage PageBuilder, oder kontaktieren Sie uns , um über Ihren Shop zu sprechen.