Ablaufdatum Artikel Zeitsteuerung | Startdatum setzen und automatisch schalten

Auf einen Blick

• Zeitfenster einmal setzen, Shopware schaltet den Artikel selbst frei und ab
• Läuft ohne Worker und ohne Cron, Storefront-Aufrufe stoßen die Prüfung an
• Abgelaufene Ware verschwindet aus Liste, Suche, Cross-Selling und Warenkorb
• Pro Verkaufskanal getrennt schaltbar, dein B2B-Shop bleibt davon unberührt
• Kunden sehen das Ablaufdatum, wenn du willst, mit Vorlauf in Tagen

Der Adventskalender soll am 1. Dezember online sein. Die Restposten sollen am 31. Januar verschwinden. Also sitzt du am Sonntagabend im Backend, klickst Artikel auf aktiv und vier Wochen später wieder auf inaktiv. Oder du vergisst es, und jemand bestellt Ware, die du längst nicht mehr hast.

Das Problem

Shopware kennt am Artikel einen Aktiv-Schalter, aber kein Datum. Wer Saisonware, befristete Aktionen oder einen Vorverkauf fährt, führt deshalb eine zweite Liste neben dem Shop: wann was an muss und wann was aus muss. Jeder vergessene Termin kostet Umsatz, weil die Ware zu spät online ist, oder Nerven, weil du eine Bestellung stornieren und dich beim Kunden erklären musst. Bei zehn Artikeln geht das im Kopf. Bei zweihundert nicht mehr.

Die Lösung

Du trägst am Artikel ein Startdatum und ein Ablaufdatum ein. Mehr nicht. Ab da übernimmt Shopware: Der Artikel geht zum Startzeitpunkt online und zum Ablaufzeitpunkt wieder offline. Außerhalb des Fensters ist er nicht nur unsichtbar, er ist auch nicht bestellbar.

Was du davon hast

Du planst einmal, statt dreimal nachzufassen. Startdatum und Ablaufdatum stehen direkt am Artikel, im Reiter Zusatzfelder. Wer den Artikel pflegt, sieht auch seinen Zeitraum. Kein Kalendereintrag, keine Merkliste, kein Sonntagabend im Backend.

Kein Worker, kein Cron, keine Diskussion mit dem Hoster. Das Plugin hängt die Prüfung an die ganz normalen Storefront-Aufrufe. Es läuft also auch dort, wo kein Message-Worker eingerichtet ist. Wer einen Worker betreibt, bekommt zusätzlich einen Scheduled Task, muss ihn aber nicht haben.

Abgelaufene Ware kommt nicht durch die Kasse. Vier Stellen sind abgesichert, nicht nur eine: Listen und Suchergebnisse zeigen den Artikel nicht mehr, das Cross-Selling lässt ihn weg, die Artikeldetailseite antwortet mit 404 und der Warenkorb wirft ihn wieder heraus, bevor die Bestellung durchgeht. Ein Kunde, der den alten Link noch im Newsletter hat, landet nicht in einer Bestellung, die du zurückrollen musst.

Jeder Verkaufskanal für sich. Der Hauptschalter, die Kundenanzeige und das Prüfintervall werden je Verkaufskanal gelesen. Dein B2B-Shop kann Restposten weiter verkaufen, während sie im B2C-Shop längst weg sind. Steht der Hauptschalter für einen Kanal aus, passiert dort exakt nichts.

Deine Kunden wissen, wie lange sie Zeit haben. Auf Wunsch zeigt der Shop das Ablaufdatum auf der Artikeldetailseite und im Warenkorb an, mit einem Vorlauf, den du in Tagen festlegst. Bei 0 erscheint das Datum erst am Ablauftag. Das ist ehrliche Dringlichkeit statt eines erfundenen Countdowns.

So arbeitet das Plugin

Am Artikel liegen drei Zusatzfelder in der Gruppe Start- & Ablaufdatum: ein Schalter, ein Startdatum und ein Ablaufdatum. Nur Artikel mit gesetztem Schalter werden überhaupt betrachtet, alles andere bleibt unangetastet. Leeres Startdatum heißt ab sofort, leeres Ablaufdatum heißt unbegrenzt.

Zwei Dinge laufen parallel. Bei jedem Seitenaufruf entscheidet das Plugin direkt aus den bereits geladenen Zusatzfeldern, ob der Artikel gerade verkäuflich ist. Das braucht keine zusätzliche Abfrage und wirkt sofort. Getrennt davon zieht das Plugin den echten Aktiv-Schalter des Artikels nach, damit auch Sitemap, Produkt-Feeds und API dasselbe Bild zeigen wie die Storefront. Dieser Lauf startet höchstens einmal je konfiguriertem Intervall, standardmäßig alle 60 Sekunden. Wer sich das Intervall auf 10 Sekunden stellt, bekommt eine genauere Schaltzeit und minimal mehr Last.

Der Andrang macht dabei keinen Unterschied. Das Recht, den Lauf auszuführen, wird über eine einzige atomare Datenbank-Anweisung vergeben. Kommen in derselben Sekunde 500 Besucher, läuft die Prüfung trotzdem genau einmal, nicht 500 mal. Der Cache wird nur geleert, wenn sich tatsächlich ein Artikel geändert hat.

Typische Einsatzszenarien

Saison- und Aktionsware. Der Adventskalender startet am 1. Dezember, das Grillsortiment endet am 30. September. Du pflegst die Termine im Sommer und denkst bis zum Jahreswechsel nicht mehr daran.

Befristete Angebote. Eine Aktion läuft drei Wochen. Danach soll der Artikel nicht als toter Link im Google-Index hängen, sondern sauber verschwinden.

Vorverkauf mit Startdatum. Die Neuheit ist gepflegt, fotografiert und freigegeben, soll aber erst zur Messe sichtbar werden. Du setzt das Startdatum und musst nachts nicht am Rechner sitzen.

Auslaufende Sortimente und Artikel mit Mindesthaltbarkeit. Ist der Stichtag erreicht, ist der Artikel raus. Auch aus dem Warenkorb des Kunden, der ihn vor drei Tagen hineingelegt hat.

Technische Fakten für deine IT

Voraussetzung ist Shopware 6.7.11 oder neuer und PHP 8.2 oder neuer. Der Boden bei 6.7.11 ist kein Vorsichtshalber: Der Ablaufdatum-Hinweis in der Storefront ist eine Twig-Komponente, und das Storefront-Komponentensystem gibt es erst ab dieser Version.

Das Plugin legt keine eigene Datenbanktabelle an und führt keine Migration aus. Es nutzt drei Custom Fields am Produkt sowie einen Zeitstempel in der Systemkonfiguration, an dem es den letzten Prüflauf merkt. Bestehende Shopware-Tabellen bleiben unverändert.

Das Plugin sendet keine Daten an externe Server. Es verarbeitet keine personenbezogenen Daten: Es liest Artikeldaten und schreibt den Aktiv-Schalter von Artikeln. Alles bleibt in deiner Shopware-Datenbank.

Zur Last: Die Sichtbarkeitsprüfung in Listen und auf der Detailseite kommt ohne zusätzliche Datenbankabfrage aus, weil sie die ohnehin geladenen Zusatzfelder auswertet. Der Warenkorb wird mit einer Sammelabfrage geprüft, nie mit einer Abfrage je Position. Der Schaltlauf ist durch den Intervall-Wächter gedeckelt, der Cache wird nur bei echten Änderungen geleert.

Bei der Deinstallation entscheidest du: Wählst du im Plugin-Manager, dass die Daten erhalten bleiben, bleiben Zusatzfelder und Einstellungen stehen. Sonst entfernt das Plugin seine Custom Fields und seine Konfigurationswerte wieder. Deaktivierst du es nur, werden die Zusatzfelder inaktiv gesetzt, deine eingetragenen Daten bleiben aber erhalten.

Ehrlich gesagt

Das Plugin schaltet Artikel. Es warnt dich nicht per E-Mail, bevor etwas abläuft, es rechnet keine Rabatte herunter und es verwaltet keine Chargen. Wenn du eine Ablaufwarnung mit Benachrichtigung brauchst, ist das hier das falsche Werkzeug.

Ohne Worker hängt der Zeitpunkt des Schaltlaufs am Traffic. In einem Shop, der nachts um drei keinen einzigen Besucher hat, wird der Aktiv-Schalter erst mit dem ersten Aufruf am Morgen nachgezogen. Für den Kunden ändert das nichts, denn die Sichtbarkeitsprüfung greift bei jedem Seitenaufruf sofort. Wer den persistenten Schalter minutengenau braucht, etwa für einen externen Produkt-Feed, richtet zusätzlich den Scheduled Task oder den CLI-Befehl ein. Probier es in Ruhe an einem Testartikel aus, ein Zeitfenster ist in unter fünf Minuten gesetzt.

Häufige Fragen

Brauche ich dafür einen Cron oder einen Message-Worker?

Nein. Die Prüfung hängt an den normalen Storefront-Aufrufen und läuft höchstens einmal je eingestelltem Intervall. Wenn du einen Worker betreibst, nimmt das Plugin zusätzlich einen Scheduled Task mit, notwendig ist er nicht.

Was passiert mit einem Artikel, der im Warenkorb liegt und in der Zwischenzeit abläuft?

Er fliegt aus dem Warenkorb, und der Kunde bekommt einen Hinweis. Die Bestellung wird blockiert, solange die abgelaufene Position drin ist. Du musst also nichts stornieren.

Funktioniert das mit meinem Theme?

In aller Regel ja. Der Ablaufdatum-Hinweis hängt sich in die Standard-Blöcke der Storefront für Kaufbereich und Warenkorbposition. Ein Theme, das diese Blöcke komplett ersetzt, zeigt den Hinweis nicht mehr. Das Ausblenden und Sperren der Artikel arbeitet unabhängig vom Theme und funktioniert weiter.

Kann ich das nur in einem von mehreren Verkaufskanälen einsetzen?

Ja. Alle Einstellungen werden je Verkaufskanal gelesen, auch der Hauptschalter. Steht er in einem Kanal aus, wird dort kein Artikel ausgeblendet, keiner gesperrt und kein Datum angezeigt.

Warnt mich das Plugin, bevor ein Artikel abläuft?

Nein. Es verschickt keine E-Mail und legt keine Erinnerung an. Es schaltet Artikel, mehr nicht. Für Ablaufwarnungen per Benachrichtigung brauchst du ein anderes Werkzeug.

Was passiert bei der Deinstallation mit meinen eingetragenen Daten?

Das entscheidest du im Plugin-Manager. Wählst du dort, dass die Daten erhalten bleiben, stehen Zusatzfelder und Einstellungen unverändert weiter. Andernfalls entfernt das Plugin seine Custom Fields und seine Konfiguration. Bestehende Shopware-Tabellen fasst es nie an.

Sendet das Plugin Daten an externe Server?

Nein. Es sendet keine Daten nach außen und verarbeitet keine personenbezogenen Daten. Es liest Artikeldaten und schreibt den Aktiv-Schalter von Artikeln, alles innerhalb deiner Shopware-Datenbank.

Bremst das meinen Shop aus?

Die Sichtbarkeitsprüfung wertet Zusatzfelder aus, die ohnehin geladen sind, und braucht dafür keine zusätzliche Abfrage. Der Warenkorb wird mit einer einzigen Sammelabfrage geprüft. Der Schaltlauf selbst ist durch das Intervall gedeckelt und leert den Cache nur, wenn sich wirklich etwas geändert hat.

Warum erst ab Shopware 6.7.11 und nicht ab 6.7.0?

Der Ablaufdatum-Hinweis in der Storefront ist eine Twig-Komponente. Das Storefront-Komponentensystem gibt es erst ab 6.7.11. Auf älteren Ständen wäre das Tag unbekannt und die Artikelseite würde brechen. Deshalb steht die Grenze hart im Constraint statt als Fußnote.

Was passiert mit Artikeln, bei denen ich gar kein Zeitfenster pflege?

Nichts. Das Plugin schaut nur auf Artikel, bei denen du den Schalter im Zusatzfeld gesetzt hast. Alle anderen laufen weiter wie vorher.