Cron, Action Scheduler och staging

Modul 7: Synlighet och webbhotell · Lästid: 10 minuter

Lärandemål: Efter den här lektionen kan du förklara hur WooCommerce utför uppgifter i bakgrunden, kontrollera de schemalagda åtgärderna och rätta till dem vid problem. Du kan också sätta upp en stagingmiljö för en butik så att inga riktiga kunder, betalningar eller beställningar påverkas.

Nyckelbegrepp: WP-Cron, riktig cron, DISABLE_WP_CRON, Action Scheduler, schemalagda åtgärder, väntar, slutförd, misslyckades, rensning, staging för en butik, testläge hos betalleverantören, mejl avstängt, webhooks, integrationer, återställ aldrig databasen över produktion

Vad som händer när ingen tittar

En butik gör mycket arbete som inte direkt hör ihop med ett klick från en besökare:

avbryta obetalda beställningar när tiden för att hålla lager har gått ut (lektion 3.4);
skicka mejl efter en statusändring, och webhooks till integrationer;
uppdatera rapporter och statistik i administrationen;
rensa bort utgångna sessioner och tillfälliga data;
tillämpa lagringstiderna under Konton och integritet (lektion 2.3);
vid prenumerationer eller bokföringsintegrationer: dra betalningar och skicka vidare data.

För detta använder WordPress WP-Cron, och WooCommerce använder dessutom Action Scheduler. Fungerar de inte som de ska märker du det inte direkt. Du märker det när obetalda beställningar fortsätter att hålla lager, när rapporter förblir tomma eller när en integration ligger flera dagar efter.

WP-Cron och riktig cron

Hur WP-Cron fungerar och varför ett riktigt cronjobb är bättre beskrivs i WordPress-kursen, lektion 6.3: WP-Cron körs vid besök, inte efter en klocka. Det är opålitligt när du har få besökare och belastande när du har många. Lösningen: DISABLE_WP_CRON i wp-config.php och ett cronjobb i ditt kontrollpanel som kör wp-cron.php med några minuters mellanrum.

För en butik är det ingen optimering utan ett krav:

På natten, när det är få besökare, måste obetalda beställningar ändå avbrytas i tid.
Under en intensiv kampanj vill du absolut inte att en tung bakgrundsuppgift åker med på sidanropet från en kund som vill betala.

Hos WebOké skapar du en sådan uppgift i DirectAdmin under Cron-jobb (DA 15.1, KB 48), med /usr/local/bin/php som sökväg till PHP. Hos andra webbhotell fungerar det på liknande sätt i deras cronvy. Välj ett intervall på en till fem minuter för en butik, hellre än tio. En uppgift som körs varje minut och inte har något att göra kostar nästan ingenting.

Action Scheduler: WooCommerce kö

Action Scheduler är en kö för bakgrundsuppgifter som följer med WooCommerce och som också används av många andra tillägg (prenumerationer, bokföringsintegrationer, e-postmarknadsföring). Varje uppgift är en åtgärd med en tidpunkt och en status. Kön bearbetas via en WP-Cron-uppgift (action_scheduler_run_queue), så även här gäller: utan pålitlig cron hamnar kön efter.

Du ser allt under WooCommerce > Status > Schemalagda åtgärder (Scheduled Actions). Det finns flikar per status:

Status	Betydelse	Vad du gör
Väntar (Pending)	Ska fortfarande köras	Finns det hundratals med en tidpunkt i det förflutna ligger kön efter: kontrollera din cron
Pågår (In-progress)	Körs just nu	Om en åtgärd hänger länge, titta i loggen bredvid
Slutförd (Complete)	Klar	Ingenting; de rensas bort automatiskt
Misslyckades (Failed)	Gav ett fel	Läs felmeddelandet i kolumnen Logg; ofta ett tillägg eller en integration som inte går att nå
Avbruten (Canceled)	Utfördes medvetet inte	Oftast ingenting

Enligt källkoden rensar Action Scheduler som standard bort slutförda och avbrutna åtgärder efter en månad och misslyckade efter tre månader. Växer tabellen ändå snabbt körs det troligen många åtgärder som misslyckas om och om igen eller som skapas hela tiden. Ta reda på vilket tillägg som skapar dem (kolumnen Grupp och namnet på hooken hjälper dig) i stället för att bara tömma tabellen.

Ett exempel från verkligheten hos Theehuis Example: efter ett lösenordsbyte lade integrationen med bokföringsprogrammet varje beställning i kön som en misslyckad åtgärd. Efter en vecka fanns det 400 misslyckade åtgärder och 60 fakturor saknades (lektion 5.6). När integrationen var lagad kunde administratören köra åtgärderna igen en i taget med Kör (Run).

Staging för en butik

Vad staging är, hur du skapar en och hur du skyddar den (lösenord, noindex) beskrivs i WordPress-kursen, lektion 8.3. Hos WebOké gör du det med kloning i Installatron (DA 13.7, KB 232) och en lösenordsskyddad mapp (DA 15.9); andra webbhotell har liknande verktyg. För en butik tillkommer några saker, eftersom en kopia av en butik innehåller riktiga kunduppgifter och kan utföra riktiga åtgärder.

Direkt efter kloningen, innan du gör något annat:

Betalleverantören i testläge, med testnycklar. En staging med livenycklar kan ta emot riktiga betalningar eller genomföra återbetalningar.
Mejl avstängt eller omdirigerat. Annars skickar en kopia bekräftelser, påminnelser och mejl om övergivna varukorgar till riktiga kunder. Använd ett tillägg som stoppar all e-post eller skickar den till en enda testadress.
Integrationer och webhooks avstängda. Bokföring, lagersynkronisering, fraktetiketter, e-postmarknadsföring: annars bokför stagingmiljön fakturor eller skickar paket. Titta också under WooCommerce > Inställningar > Avancerat > Webhooks och på API-nycklarna.
Gå igenom schemalagda åtgärder. Kön har kopierats med. Väntande åtgärder (ett påminnelsemejl, en prenumerationsbetalning) körs annars en gång till på staging.
Begränsa personuppgifterna. Behöver du inga riktiga kunduppgifter för att testa, ta bort eller anonymisera dem på staging. En staging omfattas av GDPR och är ofta sämre skyddad (lektion 5.5).

Och den viktigaste regeln när du för tillbaka ändringar: lägg aldrig stagingdatabasen över en butik som är i drift. Mellan kloningen och återställningen har det tillkommit beställningar, kunder, lagerförändringar och betalningar; de förlorar du då. Gör om ändringarna i produktion (nu vet du att de fungerar), eller synkronisera bara filer. Måste det ändå ske med databasen, gör det då bara med butiken i underhållsläge, direkt efter en färsk säkerhetskopia, och med ett verktyg som hoppar över beställningar och kunder.

Testa en uppdatering på staging

Ett typiskt arbetsflöde för en stor uppdatering av WooCommerce eller ett betaltillägg:

Skapa en färsk staging (klon av produktion) och ställ in de fem punkterna ovan.
Uppdatera på staging och kör databasuppdateringen om WooCommerce ber om det.
Gör en testbeställning i testläget: betala, misslyckas, återbetala (lektion 4.5).
Titta under Schemalagda åtgärder och i felloggen om det finns nya fel.
Uppdatera sedan produktion vid en lugn tidpunkt, med en säkerhetskopia precis innan (lektion 6.2).

Sammanfattning

WooCommerce gör mycket arbete i bakgrunden; det körs via WP-Cron och Action Scheduler.
Använd alltid ett riktigt cronjobb (var första till var femte minut) för en butik i stället för WP-Cron vid besök.
Kontrollera WooCommerce > Status > Schemalagda åtgärder: många försenade väntande eller misslyckade åtgärder är ett tecken på att cron eller en integration inte fungerar.
På staging: betalleverantören i testläge, mejl och integrationer avstängda, gå igenom schemalagda åtgärder, begränsa personuppgifterna.
Lägg aldrig en stagingdatabas över en butik i drift; gör om ändringarna i produktion.

Quiz

Uppgift

Uppgift A7.3: Är din staging skyddad? Det här är samma kontroll som uppgift A8.3 i WordPress-kursen. Först behöver du ett ägarbevis för din domän (en TXT-post _weboke-cursus.<domein> eller en fil /.well-known/weboke-cursus-<code>.txt med koden du får). Fyll sedan i adressen till din butik och adressen till din staging (en värd under samma domän). Programmet hämtar startsidan för stagingmiljön, utan inloggningsuppgifter, och startsidan för produktion. Grönt om stagingmiljön ber om ett lösenord (401), eller om den har noindex och använder sin egen adress (REST-ingången pekar på stagingvärden), samtidigt som produktion inte har noindex. Orange om stagingmiljön har noindex men inget lösenord, eller saknar ett giltigt certifikat. Rött om stagingmiljön är öppen och indexerbar, om stagingmiljön fortfarande pekar på produktionsadressen, eller om produktion av misstag har noindex.

Frågor till dig själv (rättas inte): står betalleverantören i testläge på din staging? Är mejlen avstängda eller omdirigerade? Har integrationer och webhooks stängts av? Hur många väntande och misslyckade åtgärder finns just nu under Schemalagda åtgärder i produktion?

Läs mer

De här artiklarna beskriver stegen i WebOkés kontrollpaneler; i andra paneler fungerar de på liknande sätt.

Cookies på WebOké

Cookieinställningar

Nödvändiga

Marknadsföring