Presets, Design Tokens und Deploy für mehrere Storefronts
Mehrere Marken oder Ländershops auf derselben Magento-Instanz brauchen unterschiedliche Farben, Schriften und teils sogar unterschiedliche Layouts, sollen aber dieselbe Codebasis nutzen. Sauberes Hyvä Multi Store Theming mit Tailwind CSS trennt gemeinsame Struktur von Store-spezifischen Design Tokens, statt für jede Marke eine komplette Kopie des Themes zu pflegen.
Inhaltsverzeichnis
- 1. Zwei Grundmodelle für Multi Store Theming
- 2. Theme-Zuordnung pro Store View in Magento
- 3. Gemeinsames Tailwind Preset als Basis
- 4. Store-spezifische Design Tokens über data-Attribute
- 5. Wann getrennte Theme-Pakete nötig sind
- 6. RTL-Stores im Multi Store Theming berücksichtigen
- 7. Deploy-Pipeline für mehrere Themes
- 8. Typische Fehler beim Multi Store Theming
- 9. Single Build vs. getrennte Themes im Vergleich
- 10. Zusammenfassung
- 11. FAQ
1. Zwei Grundmodelle für Multi Store Theming
Bevor man mit der technischen Umsetzung beginnt, muss die grundlegende Frage geklärt werden: Unterscheiden sich die Storefronts nur in Farben, Logo und Schrift, oder auch strukturell in Layout und Komponentenverhalten? Diese Entscheidung bestimmt, ob Hyvä Multi Store Theming über ein einziges, tokenbasiertes Tailwind Build läuft oder über mehrere, vollständig getrennte Theme-Pakete pro Marke.
Für reine Farb- und Marken-Varianten ist ein einziger Build mit Store-spezifischen CSS Custom Properties die effizientere Lösung. Für tiefgreifende strukturelle Unterschiede, etwa eine komplett andere Kategorieseiten-Struktur für eine B2B-Marke gegenüber einer B2C-Marke, ist ein separates Hyvä Theme pro Marke der robustere Weg. Die folgenden Abschnitte zeigen beide Ansätze für Hyvä Multi Store Theming im Detail, inklusive der Kriterien, wann welcher Ansatz sinnvoll ist.
Wichtig ist, diese Entscheidung früh im Projekt zu treffen. Ein nachträglicher Wechsel von einem Single-Build-Ansatz zu getrennten Theme-Paketen bedeutet erheblichen Migrationsaufwand, weil sämtliche Store-spezifischen Übersteuerungen neu strukturiert werden müssen.
2. Theme-Zuordnung pro Store View in Magento
Magento erlaubt die Zuordnung eines Themes pro Store View über Content > Design > Configuration im Backend, oder deklarativ über core_config_data mit dem Pfad design/theme/theme_id, gescoped auf die jeweilige Store View. Für Hyvä Multi Store Theming ist relevant, dass diese Zuordnung unabhängig davon funktioniert, ob am Ende ein oder mehrere physische Theme-Verzeichnisse existieren, Magento kennt nur die Theme-ID, nicht die interne Tailwind-Struktur dahinter.
Bei einem Single-Build-Ansatz zeigen mehrere Store Views auf dasselbe physische Theme, unterscheiden sich aber zur Laufzeit über ein Store-Kennungs-Attribut im Root-Element des Layouts. Bei getrennten Theme-Paketen zeigt jede Store View auf ein eigenes Theme mit eigener theme.xml und eigenem Tailwind Build. Beide Varianten des Hyvä Multi Store Theming sind aus Magento-Sicht gleich valide, unterscheiden sich aber erheblich im Build- und Deploy-Aufwand.
3. Gemeinsames Tailwind Preset als Basis
Für den Single-Build-Ansatz ist ein gemeinsames Tailwind Preset die zentrale Grundlage. Ein Preset ist eine wiederverwendbare Basis-Konfiguration, die von mehreren Theme-Konfigurationen über presets: [require(...)] eingebunden wird. Für Hyvä Multi Store Theming bedeutet das: Grundlegende Utility-Erweiterungen, Spacing-Skalen und Breakpoints werden einmal zentral gepflegt, während jede Marke nur die tatsächlich abweichenden Design Tokens überschreibt.
Dieser Ansatz reduziert Redundanz erheblich, weil strukturelle Änderungen, etwa eine neue Breakpoint-Definition, nur einmal im Preset vorgenommen werden müssen und automatisch für alle Marken gelten. Für Hyvä Multi Store Theming mit mehr als zwei oder drei Marken ist dieser Ansatz nahezu zwingend, weil sich sonst Inkonsistenzen zwischen den Marken schleichend einschleichen.
// web/tailwind/presets/shared-base.js — shared across all store brands
module.exports = {
theme: {
extend: {
spacing: {
18: '4.5rem',
22: '5.5rem'
},
borderRadius: {
card: '1rem'
}
}
}
};
// web/tailwind/tailwind.config.js — per-brand config extends the shared base
const sharedBase = require('./presets/shared-base.js');
module.exports = {
presets: [sharedBase],
content: ['../../**/*.phtml', '../../**/*.js'],
theme: {
extend: {
colors: {
// Brand-specific colors only, everything else inherited from preset
primary: '#0369a1'
}
}
}
};
4. Store-spezifische Design Tokens über data-Attribute
Innerhalb eines einzigen Builds lassen sich Store-spezifische Farben elegant über CSS Custom Properties lösen, die je nach einem Attribut auf dem <html> oder <body> Element unterschiedliche Werte annehmen. Magento setzt dieses Attribut serverseitig anhand des aktuellen Store-Codes, sodass keine zusätzliche JavaScript-Logik nötig ist. Für Hyvä Multi Store Theming ist das der Kern der Single-Build-Strategie: Eine CSS-Datei bedient beliebig viele Marken.
Der Vorteil gegenüber separaten Builds ist die Build-Zeit: Ein einziger Tailwind Compile-Durchlauf deckt alle Marken ab, statt für jede Marke einen eigenen, zeitintensiven Build auszuführen. Der Nachteil ist, dass alle Marken dieselbe CSS-Datei laden, auch wenn sie nur einen Bruchteil der Store-spezifischen Regeln tatsächlich nutzen, was bei sehr vielen Marken zu einer spürbar größeren Bundle-Größe führen kann.
/* web/tailwind/tailwind-source.css */
@import "tailwindcss";
@theme {
--color-primary: #0369a1;
}
/* Brand-specific token overrides, matched by a store code attribute
set server-side on the html element in the root template */
[data-store-code="brand-b2b"] {
--color-primary: #7c2d12;
}
[data-store-code="brand-outlet"] {
--color-primary: #166534;
}
<!-- app/design/frontend/Mironsoft/default/Magento_Theme/templates/root.phtml -->
<html lang="<?= $block->escapeHtmlAttr($this->helper(Locale::class)->getLocaleCode()) ?>"
data-store-code="<?= $block->escapeHtmlAttr($storeManager->getStore()->getCode()) ?>">
5. Wann getrennte Theme-Pakete nötig sind
Sobald sich Marken nicht nur farblich, sondern strukturell unterscheiden, etwa eine völlig andere Checkout-Reihenfolge oder ein komplett anderes Kategorieseiten-Layout, stößt der Single-Build-Ansatz an seine Grenzen. Bedingte Templates mit unzähligen if (storeCode === 'brand-x') Verzweigungen sind schwerer zu warten als getrennte Theme-Pakete, die jeweils per Hyvä Theme Fallback auf dasselbe Parent-Theme zurückgreifen, aber eigene, gezielte Overrides besitzen.
In diesem Fall bekommt jede Marke ein eigenes Theme-Verzeichnis mit eigener theme.xml, eigenem Tailwind Build und eigener Preset-Referenz auf dieselbe geteilte Basis-Konfiguration aus Abschnitt 3. Für Hyvä Multi Store Theming bedeutet das mehr Build-Zeit und mehr Deploy-Schritte, aber deutlich klarere Trennung struktureller Unterschiede zwischen den Marken, ohne dass Templates mit Store-Bedingungen überladen werden.
6. RTL-Stores im Multi Store Theming berücksichtigen
Betreibt eine der Marken einen Store in einer von rechts nach links geschriebenen Sprache, etwa Arabisch oder Hebräisch, muss Hyvä Multi Store Theming zusätzlich die Schreibrichtung berücksichtigen. Tailwind CSS unterstützt logische Eigenschaften wie ms-4 statt ml-4, die sich automatisch an die im dir Attribut gesetzte Schreibrichtung anpassen, ohne separate RTL-spezifische Klassen zu benötigen.
Für Multi Store Setups mit gemischten Schreibrichtungen ist es entscheidend, konsequent logische statt physische Richtungsklassen zu verwenden, von Anfang an, nicht als nachträgliches RTL-Patch. Wird dieser Grundsatz beim initialen Aufbau des Hyvä Multi Store Theming Setups befolgt, funktioniert ein später hinzugefügter RTL-Store ohne strukturelle CSS-Änderungen, nur das dir="rtl" Attribut muss serverseitig korrekt gesetzt werden.
7. Deploy-Pipeline für mehrere Themes
Bei getrennten Theme-Paketen muss die Deploy-Pipeline für jedes Theme einen eigenen Build- und Deploy-Schritt durchlaufen. Für Hyvä Multi Store Theming mit mehreren Marken bedeutet das eine Schleife über alle Theme-Verzeichnisse, jeweils mit eigenem npm run build und eigenem setup:static-content:deploy -t Aufruf. Wird ein Theme in dieser Schleife vergessen, bleibt die betroffene Marke auf einem veralteten CSS-Stand, ohne dass der Fehler sofort auffällt.
Bei einem Single-Build-Ansatz ist die Pipeline einfacher, weil nur ein Build- und Deploy-Schritt für alle Marken gemeinsam läuft. Für Hyvä Multi Store Theming lohnt sich deshalb, die Deploy-Reihenfolge und die Liste der zu bauenden Themes explizit in einem Skript zu dokumentieren, statt sie im Gedächtnis einzelner Teammitglieder zu belassen.
#!/usr/bin/env bash
# deploy-multi-store-themes.sh — build and deploy every brand theme
set -euo pipefail
THEMES=(
"Mironsoft/default"
"Mironsoft/brand-b2b"
"Mironsoft/brand-outlet"
)
for theme in "${THEMES[@]}"; do
echo "[BUILD] ${theme}"
bin/npm --prefix "app/design/frontend/${theme}/web/tailwind" run build
echo "[DEPLOY] ${theme}"
bin/magento setup:static-content:deploy de_DE -t "${theme}" -f
done
bin/magento cache:flush
8. Typische Fehler beim Multi Store Theming
Der häufigste Fehler beim Single-Build-Ansatz ist das Vergessen einer Store-spezifischen Übersteuerung in der CSS-Datei, was dazu führt, dass eine neue Marke stillschweigend die Standardfarben einer anderen Marke erbt. Für Hyvä Multi Store Theming hilft hier eine automatisierte Prüfung, die für jeden konfigurierten Store-Code eine passende CSS-Regel erwartet und beim Fehlen einen Build-Fehler auslöst, statt den Fehler erst im Live-Betrieb zu bemerken.
Bei getrennten Theme-Paketen ist der häufigste Fehler das Vergessen eines Themes in der Deploy-Schleife aus Abschnitt 7, oder eine veraltete Preset-Referenz, wenn sich die gemeinsame Basis-Konfiguration geändert hat, ein Marken-Theme aber nicht neu gebaut wurde. Ein dritter Fehler betrifft RTL-Stores: Werden physische statt logische Richtungsklassen verwendet, muss jedes betroffene Template nachträglich manuell für RTL angepasst werden, was den Wartungsaufwand für Hyvä Multi Store Theming deutlich erhöht.
9. Single Build vs. getrennte Themes im Vergleich
Die Wahl zwischen einem gemeinsamen Build und getrennten Theme-Paketen hängt vom Grad der strukturellen Unterschiede zwischen den Marken ab. Die folgende Übersicht fasst die wichtigsten Unterschiede für Hyvä Multi Store Theming zusammen.
| Kriterium | Single Build mit Tokens | Getrennte Theme-Pakete |
|---|---|---|
| Nur Farben und Logo unterschiedlich | Sehr gut geeignet | Unnötiger Overhead |
| Unterschiedliches Layout pro Marke | Führt zu Store-Bedingungen im Template | Sauberer über Theme Fallback lösbar |
| Build-Zeit bei vielen Marken | Ein Build für alle Marken | Ein Build pro Marke |
| CSS-Bundle-Größe | Enthält alle Marken-Overrides | Nur die eigene Marke pro Bundle |
Mironsoft
Hyvä Theme Architektur für Multi Store und Multi Brand Setups
Mehrere Marken, eine wartbare Theme-Architektur?
Wir konzipieren und implementieren Hyvä Multi Store Theming für eure Marken, mit gemeinsamer Preset-Basis, sauberer Token-Trennung und einer verlässlichen Deploy-Pipeline für alle Storefronts.
Architektur-Beratung
Single Build vs. getrennte Themes anhand eurer Markenstruktur bewerten
Preset-Aufbau
Gemeinsame Tailwind Basis-Konfiguration für alle Marken einrichten
Deploy-Automatisierung
Skriptbasierte Build- und Deploy-Pipeline für mehrere Theme-Pakete
10. Zusammenfassung
Erfolgreiches Hyvä Multi Store Theming beginnt mit der frühen Entscheidung, ob sich Marken nur farblich oder auch strukturell unterscheiden. Für reine Farb- und Marken-Varianten liefert ein Single Build mit gemeinsamem Tailwind Preset und Store-spezifischen CSS Custom Properties über data-store-code die effizienteste Lösung, mit einem einzigen Build-Durchlauf für alle Marken. Bei strukturellen Unterschieden sind getrennte Theme-Pakete, die per Theme Fallback auf dieselbe Parent-Basis zurückgreifen, die wartbarere Wahl.
Unabhängig vom gewählten Modell sichern eine dokumentierte Deploy-Pipeline, konsequent logische Richtungsklassen für RTL-Fähigkeit und eine automatisierte Prüfung auf fehlende Store-Overrides den langfristigen Erfolg von Hyvä Multi Store Theming Projekten, auch wenn im Laufe der Zeit weitere Marken hinzukommen.
Hyvä Multi Store Theming — Das Wichtigste auf einen Blick
Grundsatzentscheidung
Farbliche Unterschiede: Single Build mit Tokens. Strukturelle Unterschiede: getrennte Theme-Pakete.
Gemeinsames Preset
Spacing, Breakpoints und Utility-Erweiterungen zentral pflegen, nur Farben pro Marke überschreiben.
Store-spezifische Tokens
data-store-code Attribut kombiniert mit CSS Custom Properties, serverseitig ohne JavaScript gesetzt.
Deploy-Pipeline
Bei getrennten Themes: dokumentierte Schleife über alle Theme-Verzeichnisse, kein Theme vergessen.