Module 7 · 7.3

Cron, Action Scheduler en staging

Module 7: Gevonden worden en hosting · Leestijd: 10 minuten

Leerdoel: Na deze les kun je uitleggen hoe WooCommerce taken op de achtergrond uitvoert, de geplande acties controleren en bij problemen herstellen, en een staging-omgeving voor een shop zo inrichten dat er geen echte klanten, betalingen of bestellingen in de knel komen.

Kernbegrippen: WP-Cron, echte cron, DISABLE_WP_CRON, Action Scheduler, geplande acties, wachtend, voltooid, mislukt, opruimen, staging voor een shop, testmodus van de betaalprovider, mail uit, webhooks, koppelingen, database niet terugzetten over productie

Wat er gebeurt als niemand kijkt

Een shop doet veel werk dat niet direct bij een klik van een bezoeker hoort:

onbetaalde bestellingen annuleren als de tijd voor voorraad vasthouden voorbij is (les 3.4);
mails versturen na een statuswijziging, en webhooks naar koppelingen;
rapporten en statistieken bijwerken in het beheer;
verlopen sessies en tijdelijke gegevens opruimen;
de bewaartermijnen uit Accounts en privacy uitvoeren (les 2.3);
bij abonnementen of boekhoudkoppelingen: betalingen afschrijven en gegevens doorsturen.

Daarvoor gebruikt WordPress WP-Cron en gebruikt WooCommerce daarbovenop de Action Scheduler. Draaien die niet goed, dan merk je dat niet meteen. Je merkt het als onbetaalde bestellingen voorraad blijven vasthouden, rapporten leeg blijven of een koppeling dagen achterloopt.

WP-Cron en echte cron

Hoe WP-Cron werkt en waarom een echte cronjob beter is, staat in de WordPress-cursus, les 6.3: WP-Cron draait bij bezoeken, niet op een klok, en dat is onbetrouwbaar bij weinig bezoekers en belastend bij veel bezoekers. De oplossing: DISABLE_WP_CRON in wp-config.php en een cronjob in je hostingpaneel die wp-cron.php elke paar minuten draait.

Voor een shop is dat geen optimalisatie maar een vereiste:

's Nachts, als er weinig bezoek is, moeten onbetaalde bestellingen toch op tijd geannuleerd worden.
In een drukke actie wil je juist niet dat een zware achtergrondtaak meelift op het paginaverzoek van een klant die wil afrekenen.

Bij WebOké maak je zo'n taak in DirectAdmin bij Cron Taken (DA 15.1, KB 48), met /usr/local/bin/php als pad naar PHP; bij andere hosters werkt het vergelijkbaar in hun cronscherm. Kies een interval van één tot vijf minuten voor een shop, liever dan tien. Een taak die elke minuut draait en niets te doen heeft, kost bijna niets.

Action Scheduler: de wachtrij van WooCommerce

De Action Scheduler is een wachtrij voor achtergrondtaken die met WooCommerce wordt meegeleverd en die ook door veel andere plugins wordt gebruikt (abonnementen, boekhoudkoppelingen, e-mailmarketing). Elke taak is een actie met een tijdstip en een status. De wachtrij wordt afgewerkt via een WP-Cron-taak (action_scheduler_run_queue), dus ook hier geldt: zonder betrouwbare cron loopt de wachtrij achter.

Je ziet alles bij WooCommerce > Status > Geplande acties (Scheduled Actions). Er zijn tabbladen per status:

Status	Betekenis	Wat je doet
Wachtend (Pending)	Moet nog draaien	Zijn er honderden met een tijdstip in het verleden, dan loopt de wachtrij achter: controleer je cron
Bezig (In-progress)	Draait nu	Blijft een actie lang hangen, kijk in het logboek ernaast
Voltooid (Complete)	Gedaan	Niets; ze worden automatisch opgeruimd
Mislukt (Failed)	Gaf een fout	Lees de foutmelding in de kolom Logboek; vaak een plugin of een koppeling die niet bereikbaar is
Geannuleerd (Canceled)	Bewust niet uitgevoerd	Meestal niets

Volgens de broncode ruimt de Action Scheduler voltooide en geannuleerde acties standaard na een maand op, mislukte na drie maanden. Groeit de tabel toch hard, dan draaien er waarschijnlijk veel acties die steeds opnieuw mislukken of worden aangemaakt; zoek uit welke plugin ze maakt (de kolom Groep en de naam van de hook helpen), in plaats van alleen de tabel te legen.

Een praktijkvoorbeeld bij Theehuis Example: de koppeling met het boekhoudprogramma zette na een wachtwoordwijziging elke bestelling als mislukte actie in de wachtrij. Na een week stonden er 400 mislukte acties en ontbraken 60 facturen (les 5.6). Na het herstellen van de koppeling kon de beheerder de acties per stuk opnieuw laten draaien met Nu uitvoeren (Run).

Staging voor een shop

Wat staging is, hoe je er een maakt en hoe je hem afschermt (wachtwoord, noindex), staat in de WordPress-cursus, les 8.3. Bij WebOké kan dat met klonen in Installatron (DA 13.7, KB 232) en een map met wachtwoord (DA 15.9); andere hosters hebben vergelijkbare hulpmiddelen. Voor een shop komt daar een aantal dingen bij, omdat een kopie van een shop echte klantgegevens bevat en echte acties kan uitvoeren.

Direct na het klonen, vóór je iets anders doet:

Betaalprovider in testmodus, met testsleutels. Een staging met live-sleutels kan echte betalingen ontvangen of terugbetalingen uitvoeren.
Mail uit of omgeleid. Een kopie stuurt anders bevestigingen, herinneringen en verlaten-winkelwagenmails naar echte klanten. Gebruik een plugin die alle mail tegenhoudt of naar één testadres stuurt.
Koppelingen en webhooks uit. Boekhouding, voorraadsynchronisatie, verzendlabels, e-mailmarketing: anders boekt staging facturen of verzendt het pakketten. Kijk ook bij WooCommerce > Instellingen > Geavanceerd > Webhooks en bij de API-sleutels.
Geplande acties nalopen. De wachtrij is meegekopieerd. Wachtende acties (een herinneringsmail, een abonnementsbetaling) draaien anders op staging nog een keer.
Persoonsgegevens beperken. Heb je geen echte klantgegevens nodig om te testen, verwijder of anonimiseer ze op staging. Een staging telt mee voor de AVG en is vaak minder goed beveiligd (les 5.5).

En de belangrijkste regel bij terugzetten: zet nooit de database van staging over een draaiende shop. Tussen het moment van klonen en terugzetten zijn er bestellingen, klanten, voorraadmutaties en betalingen bijgekomen; die ben je dan kwijt. Voer wijzigingen opnieuw uit op productie (je weet nu dat ze werken), of synchroniseer alleen bestanden. Moet het toch met de database, doe het dan alleen met de shop in onderhoudsmodus, direct na een verse back-up, en met een tool die bestellingen en klanten overslaat.

Een update testen op staging

Een typische route voor een grote update van WooCommerce of een betaalplugin:

Maak een verse staging (kloon van productie) en zet de vijf punten hierboven goed.
Werk bij op staging en voer de databasebijwerking uit als WooCommerce erom vraagt.
Doe een testbestelling met de testmodus: betalen, mislukken, terugbetalen (les 4.5).
Kijk bij Geplande acties en in het foutlog of er nieuwe fouten zijn.
Werk daarna productie bij op een rustig moment, met een back-up vlak ervoor (les 6.2).

Samenvatting

WooCommerce doet veel werk op de achtergrond; dat draait via WP-Cron en de Action Scheduler.
Gebruik voor een shop altijd een echte cronjob (elke één tot vijf minuten) in plaats van WP-Cron bij bezoeken.
Controleer WooCommerce > Status > Geplande acties: veel achterstallige wachtende of mislukte acties zijn een teken dat cron of een koppeling niet werkt.
Op staging: betaalprovider in testmodus, mail en koppelingen uit, geplande acties nalopen, persoonsgegevens beperken.
Zet nooit een stagingdatabase over een draaiende shop; voer wijzigingen opnieuw uit op productie.

Quiz

Opdracht

Opdracht A7.3: Is je staging afgeschermd? Dit is dezelfde controle als opdracht A8.3 van de WordPress-cursus. Je hebt eerst een eigendomsbewijs nodig voor je domein (een TXT-record _weboke-cursus.<domein> of een bestand /.well-known/weboke-cursus-<code>.txt met de code die je krijgt). Vul daarna het adres van je shop en het adres van je staging in (een host onder hetzelfde domein). Het programma vraagt de homepage van de staging op, zonder inloggegevens, en die van productie. Groen als de staging om een wachtwoord vraagt (401), of als hij noindex heeft en zijn eigen adres gebruikt (de REST-ingang wijst naar de staginghost), terwijl productie geen noindex heeft. Oranje als de staging wel noindex heeft maar geen wachtwoord, of geen geldig certificaat. Rood als de staging open en indexeerbaar is, als de staging nog naar het adres van productie wijst, of als productie per ongeluk noindex heeft.

Vragen voor jezelf (niet nagekeken): staat de betaalprovider op je staging in testmodus? Is de mail uit of omgeleid? Zijn koppelingen en webhooks uitgezet? Hoeveel wachtende en mislukte acties staan er nu bij Geplande acties op productie?

Verder lezen

Deze artikelen beschrijven de stappen in de panelen van WebOké; in andere panelen werken ze vergelijkbaar.

Cookies op WebOké

Cookie-instellingen

Noodzakelijk

Marketing