Saisonale Kampagnen-Theme-Overrides mit Tailwind CSS

1. Das Problem mit Copy-Paste-Saisoncode

Ein typisches Muster in gewachsenen Projekten: Kurz vor Weihnachten wird eine rot-grüne Akzentfarbe direkt in bestehende Komponenten geschrieben, ein Banner eingefügt und ein paar Klassen hart überschrieben. Nach den Feiertagen bleibt die Änderung oft länger im Code als geplant, weil niemand mehr genau weiß, welche Stellen ursprünglich für die Kampagne verändert wurden. Ein Kampagnen-Theme, das so entsteht, hinterlässt technische Schulden, die sich über Jahre ansammeln.

Das Grundproblem ist strukturell: Saisonale Änderungen werden meist nicht als eigenständige, klar abgegrenzte Schicht behandelt, sondern direkt in die permanenten Basis-Styles gemischt. Ohne klare Trennung lässt sich ein Kampagnen-Theme weder zuverlässig aktivieren noch zuverlässig wieder entfernen, weil die Änderungen über Dutzende Dateien verstreut sind.

Der Ausweg ist, saisonale Anpassungen von vornherein als eigene, klar benannte CSS-Schicht zu behandeln, die unabhängig vom restlichen Code aktiviert und deaktiviert werden kann. Ein Kampagnen-Theme wird damit zu einem eigenständigen, versionierten Artefakt statt zu einer Reihe verstreuter Hotfixes, die im Code hängen bleiben.

2. Eine eigene CSS-Schicht statt Ad-hoc-Anpassungen

Tailwind CSS v4 CSS Cascade Layers eignen sich ideal, um ein Kampagnen-Theme als klar abgegrenzten Baustein zu definieren. Eine eigene, benannte Schicht wie campaign-override wird bewusst nach den regulären Tailwind-Schichten deklariert, sodass ihre Regeln automatisch gegen die Basis-Styles gewinnen, ohne dass zusätzliche Spezifitäts-Tricks nötig wären.

Der entscheidende Vorteil dieser Struktur: Die gesamte Kampagnen-Logik lässt sich in einer einzigen, klar abgegrenzten CSS-Datei oder einem einzigen Import-Block sammeln. Wenn die Weihnachtskampagne vorbei ist, muss niemand mehr Dutzende einzelne Änderungen in Basis-Komponenten rückgängig machen, es reicht, den campaign-override-Import zu entfernen oder zu deaktivieren, um das Kampagnen-Theme vollständig zu entfernen.

Diese Trennung erlaubt außerdem, mehrere saisonale Kampagnen parallel vorzubereiten, etwa Weihnachten und Black Friday im selben Quartal, ohne dass sich ihre Styles gegenseitig überschreiben. Jede Kampagne bekommt eine eigene Schicht mit eigenem Namen, und die Aktivierungslogik entscheidet, welche Schicht zu welchem Zeitpunkt tatsächlich Wirkung entfaltet.

/* Campaign layer declared last: wins against base styles automatically */
@layer reset, tailwind-base, tailwind-components, tailwind-utilities,
       campaign-christmas, campaign-black-friday;

@layer campaign-christmas {
  [data-campaign="christmas"] {
    --color-brand-primary: #b91c1c;
    --color-brand-secondary: #15803d;
  }

  [data-campaign="christmas"] .hero-banner {
    background-image: url("/media/campaign/christmas-snow.svg");
  }
}

3. Aktivierung über serverseitige Zeitfenster-Prüfung

Ein Kampagnen-Theme soll idealerweise nicht manuell an- und wieder ausgeschaltet werden müssen, sondern automatisch für einen definierten Zeitraum aktiv sein. Dafür prüft die Anwendung serverseitig bei jeder Anfrage, ob das aktuelle Datum innerhalb des konfigurierten Kampagnenzeitraums liegt, und setzt entsprechend ein Attribut wie data-campaign="christmas" auf dem html- oder body-Element.

Diese Prüfung gehört in eine zentrale Stelle der Anwendung, etwa einen Layout-Handler oder ein Plugin, das bei jedem Seitenaufruf einmal ausgeführt wird, nicht verstreut über einzelne Templates. So bleibt die Aktivierungslogik für das Kampagnen-Theme an genau einer Stelle wartbar, und ein neuer Kampagnenzeitraum lässt sich durch eine einzige Konfigurationsänderung anpassen, ohne Code in mehreren Dateien zu berühren.

Zeitzonen verdienen dabei besondere Aufmerksamkeit: Ein Kampagnenstart um Mitternacht sollte konsequent in der Zeitzone des jeweiligen Shops oder Stores berechnet werden, nicht in der Serverzeit, damit das Kampagnen-Theme für internationale Kunden zur erwarteten lokalen Uhrzeit erscheint und nicht Stunden zu früh oder zu spät.

<?php
declare(strict_types=1);

namespace Mironsoft\CampaignTheme\Service;

use DateTimeImmutable;
use DateTimeZone;

/**
 * Resolves the currently active seasonal campaign, if any.
 */
final class CampaignResolver
{
    /**
     * @param array<string, array{start: string, end: string}> $campaigns
     */
    public function __construct(
        private readonly array $campaigns,
        private readonly DateTimeZone $storeTimezone,
    ) {
    }

    /**
     * Returns the active campaign key or null if none is currently running.
     *
     * @return string|null
     */
    public function resolveActiveCampaign(): ?string
    {
        $now = new DateTimeImmutable('now', $this->storeTimezone);

        foreach ($this->campaigns as $key => $window) {
            $start = new DateTimeImmutable($window['start'], $this->storeTimezone);
            $end = new DateTimeImmutable($window['end'], $this->storeTimezone);

            if ($now >= $start && $now <= $end) {
                return $key;
            }
        }

        return null;
    }
}

4. @theme Override-Block für Kampagnenfarben

Sobald das data-campaign-Attribut gesetzt ist, übernimmt ein @theme-nahes Override im entsprechenden @layer-Block die eigentliche Farbanpassung. Wichtig ist, dass ausschließlich die Custom Properties überschrieben werden, die im Basis-@theme-Block bereits existieren, damit das Kampagnen-Theme keine neuen, unbekannten Variablennamen einführt, die Komponenten sonst nicht konsumieren würden.

Für Kampagnen mit stärker abweichender Optik, etwa einem Schwarz-Gold-Schema für Black Friday statt der üblichen Markenfarben, lohnt sich eine bewusste Begrenzung auf wenige, klar definierte Tokens: Primärfarbe, Akzentfarbe und gegebenenfalls eine Bannerfarbe. Je mehr Tokens ein Kampagnen-Theme gleichzeitig überschreibt, desto größer das Risiko, dass einzelne Komponenten während der Kampagne unerwartet aussehen.

Ein bewährter Kompromiss ist, das Kampagnen-Farbschema vorab an denselben Design-Token-Stellen zu testen, die auch im regulären Theme verwendet werden, etwa Buttons, Badges und Formularelemente, damit keine Komponente während der Kampagne unlesbar oder kontrastarm wird.

5. Feature-Flags zusätzlich zum Zeitfenster

Reine Datumsprüfung reicht in der Praxis oft nicht aus. Marketing-Teams wollen ein Kampagnen-Theme häufig vorab intern testen, bevor es live geht, oder eine Kampagne kurzfristig verlängern, ohne auf ein Entwickler-Deployment zu warten. Ein zusätzliches Feature-Flag, unabhängig vom Zeitfenster, deckt genau diesen Bedarf ab.

Die Kombination aus Zeitfenster und Feature-Flag funktioniert am robustesten mit einer klaren Priorität: Das Feature-Flag kann ein Kampagnen-Theme vorzeitig aktivieren oder über das eigentliche Zeitfenster hinaus verlängern, während das Zeitfenster als automatischer Standardfall ohne manuelles Eingreifen dient. So bleibt die Automatisierung erhalten, ohne die Flexibilität für kurzfristige Marketing-Entscheidungen zu verlieren.

Für interne Vorschauzwecke lohnt sich zusätzlich ein Query-Parameter oder Cookie-basierter Override, der ausschließlich für angemeldete Redakteure sichtbar ist. So kann das Marketing-Team das Kampagnen-Theme Wochen vor dem offiziellen Start ansehen, ohne dass reguläre Besucher etwas davon mitbekommen.

<!-- Layout snippet: campaign attribute driven by resolver + feature flag -->
<body
  data-campaign="{{ $campaignResolver->resolveActiveCampaign() ?? '' }}"
  data-campaign-preview="{{ $isEditorPreview ? 'true' : 'false' }}"
>
  <!-- Regular page content, campaign layer applies via attribute selector -->
</body>

6. Automatischer Rückbau nach Kampagnenende

Der größte strukturelle Vorteil eines zeitgesteuerten Kampagnen-Themes zeigt sich am Ende der Kampagne. Weil die Aktivierung ausschließlich über das data-campaign-Attribut läuft, das der Resolver aus Abschnitt drei automatisch anhand des Datums setzt, verschwindet die gesamte Kampagnenoptik von selbst, sobald das Enddatum überschritten ist. Es ist kein manuelles Deployment, kein Entfernen von Klassen und kein Durchsuchen des Codes nach vergessenen Hotfixes nötig.

Der CSS-Code selbst, also die campaign-christmas-Schicht, bleibt zwar im Bundle vorhanden, wird aber schlicht nie mehr angewendet, weil kein Element mehr das passende Attribut trägt. Für das nächste Jahr lässt sich dieselbe Schicht einfach mit einem neuen Zeitfenster reaktivieren, ohne dass der CSS-Code erneut geschrieben werden müsste. Das Kampagnen-Theme wird so von einer einmaligen Aktion zu einer wiederverwendbaren, versionierten Ressource.

Für sehr alte Kampagnen, die über mehrere Jahre nicht mehr reaktiviert wurden, empfiehlt sich dennoch ein regelmäßiges Aufräumen des CSS-Bundles, um die Bundle-Größe nicht unnötig aufzublähen. Ein einfacher Grep nach ungenutzten campaign-*-Schichten im Rahmen eines jährlichen Reviews reicht dafür meist aus.

7. Asset-Overrides parallel zu Farb-Token

Ein vollständiges Kampagnen-Theme beschränkt sich selten nur auf Farben. Saisonale Icons, ein anderes Hero-Bild oder ein zusätzliches Badge-Icon gehören für viele Kampagnen ebenso dazu wie die Farbanpassung selbst. Diese Assets lassen sich über denselben Attribut-Selektor steuern wie die Farbtoken, etwa indem ein background-image innerhalb derselben @layer-Regel gesetzt wird, die auch die Farbvariablen überschreibt.

Wichtig ist, saisonale Assets nicht bedingungslos zu laden, sondern nur dann, wenn das Kampagnen-Theme tatsächlich aktiv ist. Ein per CSS background-image referenziertes Bild wird vom Browser ohnehin nur geladen, wenn die zugehörige Regel tatsächlich matcht, was bei attribut-basierter Aktivierung automatisch der Fall ist. Für größere Asset-Wechsel, etwa ein komplett anderes Hero-Bild, lohnt sich zusätzlich eine bedingte Ladelogik im Template, damit das reguläre Bild außerhalb der Kampagne gar nicht erst angefragt wird.

Ein oft übersehener Punkt: Saisonale Assets sollten dieselben Performance-Anforderungen erfüllen wie reguläre Assets, also optimierte Bildformate und passende Dimensionen. Ein Kampagnen-Theme, das kurzfristig unoptimierte Bilder einbindet, kann die Core Web Vitals während der umsatzstärksten Wochen des Jahres spürbar verschlechtern.

8. Zeitreise-Tests und Preview-Modus

Ein Kampagnen-Theme, das erst am tatsächlichen Starttag zum ersten Mal live getestet wird, birgt unnötiges Risiko. Zeitreise-Tests, bei denen die Systemzeit oder eine injizierte Zeitquelle im Testkontext künstlich auf ein Datum innerhalb des Kampagnenzeitraums gesetzt wird, erlauben es, das gesamte Verhalten des Resolvers und der CSS-Aktivierung Wochen vor dem echten Start zu verifizieren.

Der in Abschnitt fünf beschriebene Preview-Modus für Redakteure dient demselben Zweck aus fachlicher Sicht: Das Marketing-Team kann das Kampagnen-Theme in einer produktionsnahen Umgebung ansehen, ohne die Systemzeit zu manipulieren oder auf einen Entwickler angewiesen zu sein. Beide Testebenen ergänzen sich, technische Zeitreise-Tests für Entwickler, visueller Preview-Modus für Redakteure.

Automatisierte visuelle Regressionstests, die einmal mit und einmal ohne aktives Kampagnen-Attribut laufen, decken zuverlässig auf, ob eine Komponente unter dem Kampagnen-Overlay unerwartet bricht, etwa durch einen zu geringen Kontrast zwischen der neuen Akzentfarbe und dem Textelement.

# Time travel test: simulate a date inside the campaign window
FAKETIME='2026-12-15 10:00:00' bin/phpunit \
  --filter CampaignResolverTest --testsuite Unit

# Verify the resolver picks up the christmas campaign
# and that no other campaign window overlaps unexpectedly

9. Manuelle Anpassung versus automatisiertes System

Die folgende Gegenüberstellung fasst zusammen, warum ein automatisiertes Kampagnen-Theme-System gegenüber manuellen, saisonalen Anpassungen strukturell im Vorteil ist, insbesondere bei mehreren Kampagnen pro Jahr.

Der Aufwand für den initialen Aufbau des automatisierten Systems ist höher als eine einzelne Ad-hoc-Anpassung, amortisiert sich aber bereits bei der zweiten oder dritten Kampagne, spätestens jedoch im zweiten Jahr, wenn dieselbe Weihnachtskampagne ohne Code-Rekonstruktion reaktiviert werden kann.

10. Zusammenfassung

Ein sauberes Kampagnen-Theme behandelt saisonale Anpassungen als eigenständige, klar benannte CSS-Schicht statt als Ad-hoc-Änderungen in bestehenden Komponenten. Ein serverseitiger Resolver setzt anhand von Zeitfenster und optionalem Feature-Flag ein Attribut, das die passende Schicht automatisch aktiviert, während Farb-Token, Assets und Preview-Modus alle über dieselbe Attribut-Grundlage gesteuert werden.

Der größte Gewinn zeigt sich nicht bei der ersten Kampagne, sondern bei der Wiederverwendung im Folgejahr: Statt den Code erneut zu rekonstruieren, reicht ein neues Zeitfenster in der Konfiguration, um dasselbe Kampagnen-Theme erneut zu aktivieren. Zeitreise-Tests und ein Preview-Modus für Redakteure stellen sicher, dass die Kampagne schon Wochen vor dem echten Start verifiziert werden kann, ohne auf den tatsächlichen Stichtag warten zu müssen.

11. FAQ: Saisonale Kampagnen-Theme-Overrides