Modul 7 · 7.3

Deutsch

Nederlands English Deutsch

Cron, Action Scheduler und Staging

Modul 7: Gefunden werden und Hosting · Lesezeit: 10 Minuten

Lernziel: Nach dieser Lektion können Sie erklären, wie WooCommerce Aufgaben im Hintergrund ausführt, die geplanten Aktionen kontrollieren und bei Problemen reparieren, und eine Staging-Umgebung für einen Shop so einrichten, dass keine echten Kunden, Zahlungen oder Bestellungen in Mitleidenschaft gezogen werden.

Kernbegriffe: WP-Cron, echter Cronjob, DISABLE_WP_CRON, Action Scheduler, geplante Aktionen, wartend, abgeschlossen, fehlgeschlagen, Aufräumen, Staging für einen Shop, Testmodus des Zahlungsanbieters, Mail aus, Webhooks, Anbindungen, Datenbank nicht über die Produktivumgebung zurückspielen

Was passiert, wenn niemand hinschaut

Ein Shop erledigt viel Arbeit, die nicht direkt zu einem Klick eines Besuchers gehört:

unbezahlte Bestellungen stornieren, wenn die Zeit für das Zurückhalten von Lagerbestand abgelaufen ist (Lektion 3.4);
Mails nach einer Statusänderung versenden und Webhooks an Anbindungen schicken;
Berichte und Statistiken in der Verwaltung aktualisieren;
abgelaufene Sitzungen und temporäre Daten aufräumen;
die Aufbewahrungsfristen aus Konten und Datenschutz umsetzen (Lektion 2.3);
bei Abonnements oder Buchhaltungsanbindungen: Zahlungen einziehen und Daten weiterleiten.

Dafür nutzt WordPress WP-Cron, und WooCommerce nutzt zusätzlich den Action Scheduler. Laufen diese nicht richtig, bemerken Sie das nicht sofort. Sie bemerken es, wenn unbezahlte Bestellungen weiterhin Lagerbestand blockieren, Berichte leer bleiben oder eine Anbindung tagelang hinterherhinkt.

WP-Cron und echter Cronjob

Wie WP-Cron funktioniert und warum ein echter Cronjob besser ist, steht im WordPress-Kurs, Lektion 6.3: WP-Cron läuft bei Seitenaufrufen, nicht nach der Uhr, und das ist bei wenigen Besuchern unzuverlässig und bei vielen Besuchern belastend. Die Lösung: DISABLE_WP_CRON in wp-config.php und ein Cronjob in Ihrem Hosting-Panel, der wp-cron.php alle paar Minuten ausführt.

Für einen Shop ist das keine Optimierung, sondern eine Voraussetzung:

Nachts, wenn wenig Besucher da sind, müssen unbezahlte Bestellungen trotzdem rechtzeitig storniert werden.
Bei einer gut besuchten Aktion möchten Sie gerade nicht, dass eine schwere Hintergrundaufgabe beim Seitenaufruf eines Kunden mitläuft, der bezahlen möchte.

Bei WebOké legen Sie eine solche Aufgabe in DirectAdmin unter Cronjobs an (DA 15.1, KB 48), mit /usr/local/bin/php als Pfad zu PHP; bei anderen Hostern funktioniert das vergleichbar in deren Cron-Bereich. Wählen Sie für einen Shop ein Intervall von einer bis fünf Minuten, lieber als zehn. Eine Aufgabe, die jede Minute läuft und nichts zu tun hat, kostet fast nichts.

Action Scheduler: die Warteschlange von WooCommerce

Der Action Scheduler ist eine Warteschlange für Hintergrundaufgaben, die mit WooCommerce mitgeliefert wird und auch von vielen anderen Plugins genutzt wird (Abonnements, Buchhaltungsanbindungen, E-Mail-Marketing). Jede Aufgabe ist eine Aktion mit einem Zeitpunkt und einem Status. Die Warteschlange wird über eine WP-Cron-Aufgabe (action_scheduler_run_queue) abgearbeitet, also gilt auch hier: Ohne zuverlässigen Cron hinkt die Warteschlange hinterher.

Sie sehen alles unter WooCommerce > Status > Geplante Aktionen (Scheduled Actions). Es gibt Tabs pro Status:

Status	Bedeutung	Was Sie tun
Wartend (Pending)	Muss noch laufen	Gibt es Hunderte mit einem Zeitpunkt in der Vergangenheit, hinkt die Warteschlange hinterher: Prüfen Sie Ihren Cron
In Bearbeitung (In-progress)	Läuft gerade	Hängt eine Aktion lange fest, schauen Sie in das Protokoll daneben
Abgeschlossen (Complete)	Erledigt	Nichts; sie werden automatisch aufgeräumt
Fehlgeschlagen (Failed)	Hat einen Fehler ausgelöst	Lesen Sie die Fehlermeldung in der Spalte Protokoll; oft ist es ein Plugin oder eine Anbindung, die nicht erreichbar ist
Storniert (Canceled)	Bewusst nicht ausgeführt	Meist nichts

Laut Quellcode räumt der Action Scheduler abgeschlossene und stornierte Aktionen standardmäßig nach einem Monat auf, fehlgeschlagene nach drei Monaten. Wächst die Tabelle trotzdem stark, laufen wahrscheinlich viele Aktionen, die immer wieder fehlschlagen oder neu angelegt werden. Finden Sie heraus, welches Plugin sie anlegt (die Spalte Gruppe und der Name des Hooks helfen dabei), statt nur die Tabelle zu leeren.

Ein Praxisbeispiel bei Theehuis Example: Die Anbindung an das Buchhaltungsprogramm stellte nach einer Passwortänderung jede Bestellung als fehlgeschlagene Aktion in die Warteschlange. Nach einer Woche gab es 400 fehlgeschlagene Aktionen, und 60 Rechnungen fehlten (Lektion 5.6). Nachdem die Anbindung repariert war, konnte der Administrator die Aktionen einzeln mit Jetzt ausführen (Run) erneut ausführen lassen.

Staging für einen Shop

Was Staging ist, wie Sie eine Staging-Umgebung anlegen und wie Sie sie abschirmen (Passwort, noindex), steht im WordPress-Kurs, Lektion 8.3. Bei WebOké geht das mit dem Klonen in Installatron (DA 13.7, KB 232) und einem passwortgeschützten Verzeichnis (DA 15.9); andere Hoster haben vergleichbare Werkzeuge. Für einen Shop kommt einiges hinzu, weil eine Kopie eines Shops echte Kundendaten enthält und echte Aktionen ausführen kann.

Direkt nach dem Klonen, bevor Sie irgendetwas anderes tun:

Zahlungsanbieter in den Testmodus, mit Testschlüsseln. Eine Staging-Umgebung mit Live-Schlüsseln kann echte Zahlungen empfangen oder Rückerstattungen auslösen.
Mail aus oder umgeleitet. Sonst verschickt eine Kopie Bestätigungen, Erinnerungen und Mails zu verlassenen Warenkörben an echte Kunden. Verwenden Sie ein Plugin, das alle Mails zurückhält oder an eine einzige Testadresse schickt.
Anbindungen und Webhooks aus. Buchhaltung, Lagerabgleich, Versandetiketten, E-Mail-Marketing: Sonst bucht die Staging-Umgebung Rechnungen oder verschickt Pakete. Schauen Sie auch unter WooCommerce > Einstellungen > Erweitert > Webhooks und bei den API-Schlüsseln nach.
Geplante Aktionen prüfen. Die Warteschlange wurde mitkopiert. Wartende Aktionen (eine Erinnerungsmail, eine Abonnementzahlung) laufen sonst auf der Staging-Umgebung ein zweites Mal.
Personenbezogene Daten begrenzen. Brauchen Sie zum Testen keine echten Kundendaten, löschen oder anonymisieren Sie sie auf der Staging-Umgebung. Eine Staging-Umgebung fällt ebenfalls unter die DSGVO und ist oft weniger gut abgesichert (Lektion 5.5).

Und die wichtigste Regel beim Zurückspielen: Spielen Sie niemals die Datenbank der Staging-Umgebung über einen laufenden Shop. Zwischen dem Klonen und dem Zurückspielen sind Bestellungen, Kunden, Lagerbewegungen und Zahlungen hinzugekommen; die wären dann verloren. Führen Sie Änderungen auf der Produktivumgebung erneut durch (Sie wissen jetzt, dass sie funktionieren), oder synchronisieren Sie nur Dateien. Muss es doch mit der Datenbank sein, dann nur mit dem Shop im Wartungsmodus, direkt nach einer frischen Sicherung und mit einem Werkzeug, das Bestellungen und Kunden überspringt.

Ein Update auf der Staging-Umgebung testen

Ein typischer Ablauf für ein großes Update von WooCommerce oder einem Zahlungs-Plugin:

Legen Sie eine frische Staging-Umgebung an (Klon der Produktivumgebung) und stellen Sie die fünf Punkte oben richtig ein.
Aktualisieren Sie auf der Staging-Umgebung und führen Sie die Datenbankaktualisierung aus, wenn WooCommerce danach fragt.
Machen Sie eine Testbestellung im Testmodus: bezahlen, fehlschlagen lassen, zurückerstatten (Lektion 4.5).
Prüfen Sie unter Geplante Aktionen und im Fehlerprotokoll, ob neue Fehler auftreten.
Aktualisieren Sie danach die Produktivumgebung zu einem ruhigen Zeitpunkt, mit einer Sicherung kurz davor (Lektion 6.2).

Zusammenfassung

WooCommerce erledigt viel Arbeit im Hintergrund; das läuft über WP-Cron und den Action Scheduler.
Verwenden Sie für einen Shop immer einen echten Cronjob (alle ein bis fünf Minuten) statt WP-Cron bei Seitenaufrufen.
Prüfen Sie WooCommerce > Status > Geplante Aktionen: Viele überfällige wartende oder fehlgeschlagene Aktionen sind ein Zeichen, dass Cron oder eine Anbindung nicht funktioniert.
Auf der Staging-Umgebung: Zahlungsanbieter in den Testmodus, Mail und Anbindungen aus, geplante Aktionen prüfen, personenbezogene Daten begrenzen.
Spielen Sie niemals eine Staging-Datenbank über einen laufenden Shop; führen Sie Änderungen auf der Produktivumgebung erneut durch.

Quiz

Aufgabe

Aufgabe A7.3: Ist Ihre Staging-Umgebung abgeschirmt? Dies ist dieselbe Prüfung wie Aufgabe A8.3 des WordPress-Kurses. Sie benötigen zuerst einen Eigentumsnachweis für Ihre Domain (einen TXT-Record _weboke-cursus.<domein> oder eine Datei /.well-known/weboke-cursus-<code>.txt mit dem Code, den Sie erhalten). Geben Sie danach die Adresse Ihres Shops und die Adresse Ihrer Staging-Umgebung ein (ein Host unter derselben Domain). Das Programm ruft die Startseite der Staging-Umgebung ohne Zugangsdaten ab, ebenso die der Produktivumgebung. Grün, wenn die Staging-Umgebung nach einem Passwort fragt (401), oder wenn sie noindex hat und ihre eigene Adresse verwendet (der REST-Einstiegspunkt verweist auf den Staging-Host), während die Produktivumgebung kein noindex hat. Orange, wenn die Staging-Umgebung zwar noindex hat, aber kein Passwort oder kein gültiges Zertifikat. Rot, wenn die Staging-Umgebung offen und indexierbar ist, wenn sie noch auf die Adresse der Produktivumgebung verweist oder wenn die Produktivumgebung versehentlich noindex hat.

Fragen für Sie selbst (werden nicht geprüft): Steht der Zahlungsanbieter auf Ihrer Staging-Umgebung im Testmodus? Ist die Mail aus oder umgeleitet? Sind Anbindungen und Webhooks abgeschaltet? Wie viele wartende und fehlgeschlagene Aktionen stehen derzeit unter Geplante Aktionen auf der Produktivumgebung?

Weiterführende Informationen

Diese Artikel beschreiben die Schritte in den Panels von WebOké; in anderen Panels funktionieren sie vergleichbar.

Cookies bei WebOké

Cookie-Einstellungen

Notwendig

Marketing