Content Staging mit Page Builder im Hyvä-Theme: zeitgesteuerte Kampagnen zuverlässig ausliefern

1. Was Content Staging leistet und wofür es im Hyvä-Theme genutzt wird

Content Staging bündelt Änderungen an CMS-Seiten, CMS-Blöcken oder Kategorieinhalten zu einer Kampagne mit einem festgelegten Start- und optional einem Endzeitpunkt, statt jede Änderung sofort live zu schalten. Damit lässt sich ein Sale-Banner bereits Tage im Voraus fertig gestalten und für den exakten Kampagnenstart einplanen, ohne dass am eigentlichen Starttermin noch jemand manuell eingreifen muss.

Im Hyvä-Theme rendert gestagter Inhalt über exakt dieselben Page-Builder-Content-Type-Templates wie live geschalteter Inhalt, denn die Staging-Funktionalität arbeitet unterhalb der Template-Schicht und tauscht lediglich aus, welche Version eines Contents zu einem gegebenen Zeitpunkt als aktuell gilt. Für die Theme-Entwicklung bedeutet das: Kein Content Type muss speziell staging-fähig gemacht werden, aber Vorschau und Cache-Verhalten verdienen gezielte Aufmerksamkeit.

2. Staging-Kampagnen für zeitgesteuerte Content-Updates anlegen

Eine Kampagne entsteht im Admin über die Aktion Schedule New Update auf einer CMS-Seite oder einem CMS-Block und fasst alle Änderungen, die bis zum geplanten Zeitpunkt vorgenommen werden, zu einem atomaren Update zusammen. Erst wenn der Cron-Job zum geplanten Zeitpunkt läuft, werden die gestagten Änderungen in die aktive Version übernommen, bis dahin bleibt der Live-Inhalt für alle Besucher unverändert sichtbar.

Für ein typisches Wochenend-Sale eignet sich genau dieses Muster: Der Sale-Banner auf der Startseite, die angepasste Kategorielandingpage und ein zusätzlicher CMS-Block mit den Aktionsbedingungen werden gemeinsam einer einzigen Kampagne zugeordnet, sodass am Freitagabend alle drei Elemente synchron erscheinen, ohne dass ein Entwickler zu dieser Uhrzeit noch aktiv sein muss.

3. Vorschau-Modus im Hyvä-Frontend technisch testen

Der Vorschau-Modus lädt eine gestagte Version über eine spezielle Vorschau-URL innerhalb des Admin-Panels, meist eingebettet in ein iFrame, und markiert die Anfrage intern so, dass Magento die gestagte statt der aktiven Version ausliefert. Für das Hyvä-Theme bedeutet das, dass sämtliche Alpine-Komponenten, die auf Page-Builder-Content-Types aufsetzen, etwa Slider oder Countdown-Banner, auch innerhalb dieses iFrame-Kontexts korrekt initialisieren müssen, denn ein fehlerhaft geladenes Skript fällt in der Vorschau sofort auf.

Ein häufig übersehener Punkt ist, dass Tracking- und Analytics-Skripte während der Vorschau nicht ausgelöst werden sollten, da sonst jeder Testaufruf eines Redakteurs als echter Seitenbesuch gezählt wird. Eine einfache serverseitige Prüfung, ob die aktuelle Anfrage eine Staging-Vorschau ist, erlaubt es, solche Skripte gezielt zu unterdrücken, ohne die eigentliche Content-Darstellung zu beeinflussen.

<?php
/** @var \Magento\Framework\View\Element\Template $block */
/** @var \Magento\Staging\Model\VersionManager $versionManager */
$versionManager = $block->getData('version_manager');
$isPreview = $versionManager !== null && $versionManager->isPreviewVersion();
?>
<?php if (!$isPreview): ?>
  <script>
    window.dataLayer = window.dataLayer || [];
    dataLayer.push({ event: 'page_view' });
  </script>
  <?php $hyvaCsp->registerInlineScript(); ?>
<?php endif; ?>

4. Zusammenspiel von Content Staging und Full Page Cache bei zeitversetzten Änderungen

Die eigentliche Herausforderung beginnt erst am Kampagnenstart selbst: Der Full Page Cache hält die zuletzt gerenderte, noch nicht gestagte Version einer Seite unter Umständen deutlich über den geplanten Startzeitpunkt hinaus vor, wenn niemand die betroffenen Cache-Einträge aktiv invalidiert. Der dafür zuständige Cron-Job staging_update_cache_context merged die gestagte Version zum geplanten Zeitpunkt in den aktiven Content und stößt die passende Cache-Invalidierung für die betroffenen Entitäten an.

Entscheidend ist dabei das Intervall, mit dem dieser Cron-Job läuft: Bei einer Standardkonfiguration von wenigen Minuten kann eine Kampagne, die exakt um Mitternacht starten soll, tatsächlich erst einige Minuten später sichtbar werden. Für zeitkritische Kampagnen, etwa einen Flash Sale mit einer auf die Minute festgelegten Startzeit, lohnt sich eine Verkürzung dieses Intervalls oder ein gezielter, manuell getriggerter Cache-Flush kurz nach dem geplanten Start.

5. CDN- und Edge-Caching bei Kampagnenstart berücksichtigen

Selbst wenn Magentos eigener Full Page Cache korrekt invalidiert, kann ein vorgeschaltetes CDN oder ein Varnish-Layer die alte Seite noch für die Dauer seiner eigenen TTL ausliefern, da diese Systeme von der internen Cache-Invalidierung durch Magento typischerweise nichts wissen. Für Seiten, die regelmäßig Ziel von Staging-Kampagnen sind, wie die Startseite oder zentrale Kategorielandingpages, lohnt sich eine deutlich kürzere Edge-TTL als für unveränderliche Inhalte wie Produktdetailseiten.

Alternativ lässt sich ein gezielter Purge-Aufruf an das CDN direkt an das Staging-Update-Event koppeln, sodass die betroffene URL exakt zum Kampagnenstart aus dem Edge-Cache entfernt wird, statt auf den Ablauf einer festen TTL zu warten. Das hält die TTL für den Rest des Shops hoch, während zeitkritische Kampagnenseiten trotzdem pünktlich aktualisiert werden.

<?php
declare(strict_types=1);

namespace Mironsoft\StagingCache\Observer;

use Magento\Framework\Event\Observer;
use Magento\Framework\Event\ObserverInterface;
use Magento\Framework\HTTP\Client\Curl;

/**
 * Purged betroffene URLs am Edge-Cache, sobald eine Staging-Kampagne
 * live geschaltet wurde, statt auf die CDN-TTL zu warten.
 */
class PurgeCdnOnCampaignActivate implements ObserverInterface
{
    /**
     * @param Curl $curl
     */
    public function __construct(private readonly Curl $curl)
    {
    }

    /**
     * Löst den Purge-Request beim CDN für die betroffenen URLs aus.
     *
     * @param Observer $observer
     * @return void
     */
    public function execute(Observer $observer): void
    {
        $urls = (array) $observer->getEvent()->getData('affected_urls');
        foreach ($urls as $url) {
            $this->curl->setHeaders(['X-Purge-Method' => 'single']);
            $this->curl->post($url, []);
        }
    }
}

6. Page Builder Content Types innerhalb einer Staging-Kampagne bearbeiten

Redakteure bearbeiten Page-Builder-Content-Types innerhalb einer Kampagne mit demselben Drag-and-Drop-Editor wie bei direkten Änderungen, und jeder im Theme registrierte Custom Content Type steht dort automatisch zur Verfügung, ohne zusätzliche Registrierung für den Staging-Kontext. Wichtig wird es bei Custom Content Types, die zur Laufzeit eigene Logik ausführen, etwa ein Countdown-Banner, der die verbleibende Zeit bis zu einem Ereignis berechnet.

Ein solcher Countdown darf sich in der Vorschau nicht auf das tatsächliche Serverdatum verlassen, sondern muss das im Staging-Kontext hinterlegte Vorschau-Datum verwenden, sonst zeigt die Vorschau für den Redakteur einen völlig falschen Countdown-Stand an. Der ViewModel des Content Types sollte deshalb konsequent über eine injizierte Datumsquelle arbeiten, die im Vorschau-Fall das gestagte Datum liefert und im Live-Betrieb das reale Serverdatum.

<?php
declare(strict_types=1);

namespace Mironsoft\CountdownBanner\ViewModel;

use Magento\Framework\View\Element\Block\ArgumentInterface;
use Magento\Staging\Model\VersionManager;
use Magento\Framework\Stdlib\DateTime\DateTime;

/**
 * Liefert das für Countdown-Berechnungen relevante Datum, unter
 * Berücksichtigung des Staging-Vorschau-Kontexts.
 */
class CountdownDateProvider implements ArgumentInterface
{
    /**
     * @param VersionManager $versionManager
     * @param DateTime $dateTime
     */
    public function __construct(
        private readonly VersionManager $versionManager,
        private readonly DateTime $dateTime,
    ) {
    }

    /**
     * Gibt das aktuell relevante Datum als Unix-Timestamp zurück.
     *
     * @return int
     */
    public function getReferenceTimestamp(): int
    {
        if ($this->versionManager->isPreviewVersion()) {
            return (int) $this->versionManager->getVersion()->getData('created_at');
        }
        return $this->dateTime->gmtTimestamp();
    }
}

7. Rollback bei fehlerhaften Kampagnen und Konfliktbehandlung

Solange eine Kampagne noch nicht live geschaltet wurde, lässt sie sich im Admin problemlos verschieben oder ganz löschen, ohne dass der Live-Content jemals betroffen war. Nach dem Merge in die aktive Version gibt es dagegen keinen einfachen Undo-Button mehr, ein Rollback bedeutet in der Praxis, eine neue Kampagne anzulegen, die den ursprünglichen Zustand wiederherstellt, weshalb sich ein Snapshot des Vorzustands vor größeren Kampagnen immer auszahlt.

Überlappen sich zwei Kampagnen auf derselben Entität, etwa weil ein Redakteur versehentlich zwei Sale-Kampagnen mit sich überschneidenden Zeiträumen anlegt, löst Magento den Konflikt anhand von Priorität und Zeitpunkt der Erstellung auf, was für Beteiligte selten intuitiv nachvollziehbar ist. Vor umsatzstarken Phasen wie einem Black-Friday-Wochenende lohnt sich deshalb ein bewusster Test überlappender Kampagnen auf einer Staging-Umgebung, um solche Überraschungen vorab auszuschließen.

8. Praxisbeispiel: Zeitgesteuerte Sale-Kampagne für ein Wochenende

Eine typische Wochenend-Kampagne startet freitags um achtzehn Uhr und endet sonntags um dreiundzwanzig Uhr neunundfünfzig, mit einem Startseiten-Banner, einer angepassten Kategorielandingpage und reduzierter Edge-TTL für genau diese beiden Seiten. Die Vorschau wird bereits am Mittwoch mit dem Marketing-Team abgenommen, während die technische Seite parallel prüft, ob der Cache-Purge-Mechanismus für den geplanten Startzeitpunkt korrekt konfiguriert ist.

Während des eigentlichen Kampagnenstarts lohnt sich eine kurze aktive Beobachtung: ein Blick ins Cron-Log, ob der Staging-Update-Job pünktlich gelaufen ist, und ein Blick auf die Cache-Hit-Rate, um sicherzustellen, dass Besucher tatsächlich die neue Version sehen. Für den Fall, dass der geplante Job sich verzögert, hilft ein vorbereiteter, manueller Cache-Flush-Befehl, um den Startzeitpunkt notfalls von Hand nachzuziehen, statt tatenlos auf den nächsten Cron-Lauf zu warten.

9. Checkliste für zuverlässiges Content Staging im Hyvä-Theme

Content Staging entfaltet seinen Wert vor allem dann, wenn Vorschau, Cache-Invalidierung und Edge-Caching als zusammenhängendes System betrachtet werden, statt jeden Teilbereich isoliert zu betrachten. Ein Redaktionsteam, das eine Kampagne sauber vorbereiten kann, aber am Starttermin von einem trägen CDN ausgebremst wird, erlebt das Feature am Ende trotzdem als unzuverlässig, auch wenn Magento selbst korrekt funktioniert hat.

Die folgende Übersicht fasst die wichtigsten Prüfpunkte für ein zeitkritisches Kampagnen-Setup zusammen, damit vor dem nächsten Kampagnenstart nichts Grundlegendes übersehen wird.

10. Zusammenfassung

11. FAQ: Content Staging mit Page Builder im Hyvä-Theme