Cron, Action Scheduler og staging

Modul 7: Synlighed og hosting · Læsetid: 10 minutter

Læringsmål: Efter denne lektion kan du forklare, hvordan WooCommerce kører opgaver i baggrunden, kontrollere de skemalagte handlinger og rette dem ved problemer. Du kan også sætte et staging-miljø op til en shop, så ingen rigtige kunder, betalinger eller ordrer kommer i klemme.

Centrale begreber: WP-Cron, rigtig cron, DISABLE_WP_CRON, Action Scheduler, skemalagte handlinger, venter, fuldført, mislykket, oprydning, staging til en shop, betalingsudbyderens testtilstand, mail slået fra, webhooks, integrationer, databasen må ikke lægges tilbage over produktion

Hvad der sker, når ingen kigger

En shop udfører meget arbejde, som ikke hører direkte til en besøgendes klik:

annullere ubetalte ordrer, når tiden for at holde lagerbeholdning er udløbet (lektion 3.4);
sende mails efter en statusændring og webhooks til integrationer;
opdatere rapporter og statistik i administrationen;
rydde op i udløbne sessioner og midlertidige data;
udføre opbevaringsperioderne fra Kontooplysninger og privatliv (lektion 2.3);
ved abonnementer eller regnskabsintegrationer: trække betalinger og sende data videre.

Til det bruger WordPress WP-Cron, og oven på det bruger WooCommerce Action Scheduler. Kører de ikke ordentligt, opdager du det ikke med det samme. Du opdager det, når ubetalte ordrer bliver ved med at holde lagerbeholdning, rapporter forbliver tomme, eller en integration halter flere dage bagefter.

WP-Cron og rigtig cron

Hvordan WP-Cron fungerer, og hvorfor et rigtigt cronjob er bedre, står i WordPress-kurset, lektion 6.3: WP-Cron kører ved besøg, ikke efter et ur, og det er upålideligt ved få besøgende og belastende ved mange besøgende. Løsningen: DISABLE_WP_CRON i wp-config.php og et cronjob i dit hostingpanel, der kører wp-cron.php med få minutters mellemrum.

For en shop er det ikke en optimering, men et krav:

Om natten, når der er få besøgende, skal ubetalte ordrer alligevel annulleres til tiden.
Under en travl kampagne vil du netop ikke have, at en tung baggrundsopgave kører med på sideforespørgslen fra en kunde, der vil betale.

Hos WebOké opretter du sådan en opgave i DirectAdmin under Cron-jobs (DA 15.1, KB 48) med /usr/local/bin/php som sti til PHP; hos andre hostingudbydere fungerer det på samme måde i deres cronskærm. Vælg et interval på et til fem minutter til en shop, hellere end ti. En opgave, der kører hvert minut og ikke har noget at lave, koster næsten ingenting.

Action Scheduler: WooCommerce' kø

Action Scheduler er en kø til baggrundsopgaver, der følger med WooCommerce og også bruges af mange andre plugins (abonnementer, regnskabsintegrationer, e-mailmarketing). Hver opgave er en handling med et tidspunkt og en status. Køen afvikles via en WP-Cron-opgave (action_scheduler_run_queue), så også her gælder: uden pålidelig cron halter køen bagefter.

Du ser det hele under WooCommerce > Status > Skemalagte handlinger (Scheduled Actions). Der er faner for hver status:

Status	Betydning	Hvad du gør
Venter (Pending)	Skal stadig køre	Er der hundredvis med et tidspunkt i fortiden, halter køen bagefter: kontrollér din cron
I gang (In-progress)	Kører nu	Hænger en handling længe, så kig i loggen ved siden af
Fuldført (Complete)	Udført	Intet; de ryddes automatisk op
Mislykket (Failed)	Gav en fejl	Læs fejlmeddelelsen i kolonnen Log; ofte et plugin eller en integration, der ikke kan nås
Annulleret (Canceled)	Bevidst ikke udført	Som regel intet

Ifølge kildekoden rydder Action Scheduler som standard fuldførte og annullerede handlinger op efter en måned og mislykkede efter tre måneder. Vokser tabellen alligevel kraftigt, kører der sandsynligvis mange handlinger, der igen og igen mislykkes eller oprettes; find ud af, hvilket plugin der opretter dem (kolonnen Gruppe og navnet på hooken hjælper), i stedet for blot at tømme tabellen.

Et eksempel fra praksis hos Theehuis Example: Integrationen med regnskabsprogrammet satte efter en ændring af adgangskoden hver ordre i køen som en mislykket handling. Efter en uge stod der 400 mislykkede handlinger, og der manglede 60 fakturaer (lektion 5.6). Da integrationen var rettet, kunne administratoren køre handlingerne igen én ad gangen med Kør nu (Run).

Staging til en shop

Hvad staging er, hvordan du opretter et, og hvordan du afskærmer det (adgangskode, noindex), står i WordPress-kurset, lektion 8.3. Hos WebOké kan det gøres med kloning i Installatron (DA 13.7, KB 232) og en mappe med adgangskode (DA 15.9); andre hostingudbydere har lignende værktøjer. For en shop kommer der nogle ting oveni, fordi en kopi af en shop indeholder rigtige kundedata og kan udføre rigtige handlinger.

Lige efter kloningen, før du gør noget andet:

Betalingsudbyder i testtilstand med testnøgler. Et staging-miljø med live-nøgler kan modtage rigtige betalinger eller udføre refunderinger.
Mail slået fra eller omdirigeret. Ellers sender en kopi bekræftelser, påmindelser og mails om forladte kurve til rigtige kunder. Brug et plugin, der stopper al mail eller sender den til én testadresse.
Integrationer og webhooks slået fra. Regnskab, lagersynkronisering, forsendelseslabels, e-mailmarketing: ellers bogfører staging fakturaer eller sender pakker. Kig også under WooCommerce > Indstillinger > Avanceret > Webhooks og ved API-nøglerne.
Gennemgå skemalagte handlinger. Køen er kopieret med. Ventende handlinger (en påmindelsesmail, en abonnementsbetaling) kører ellers én gang til på staging.
Begræns persondata. Har du ikke brug for rigtige kundedata til at teste, så slet eller anonymiser dem på staging. Et staging-miljø er omfattet af GDPR og er ofte dårligere beskyttet (lektion 5.5).

Og den vigtigste regel, når du lægger noget tilbage: læg aldrig databasen fra staging over en kørende shop. Mellem kloningen og tilbagelægningen er der kommet ordrer, kunder, lagerændringer og betalinger til; dem mister du så. Udfør ændringerne igen på produktion (du ved nu, at de virker), eller synkroniser kun filer. Skal det alligevel ske med databasen, så gør det kun med shoppen i vedligeholdelsestilstand, lige efter en frisk backup og med et værktøj, der springer ordrer og kunder over.

Test en opdatering på staging

En typisk fremgangsmåde ved en stor opdatering af WooCommerce eller et betalingsplugin:

Opret et frisk staging-miljø (en klon af produktion), og ret de fem punkter ovenfor.
Opdater på staging, og kør databaseopdateringen, hvis WooCommerce beder om det.
Lav en testbestilling i testtilstand: betale, mislykkes, refundere (lektion 4.5).
Kig under Skemalagte handlinger og i fejlloggen, om der er nye fejl.
Opdater derefter produktion på et roligt tidspunkt med en backup lige før (lektion 6.2).

Opsummering

WooCommerce udfører meget arbejde i baggrunden; det kører via WP-Cron og Action Scheduler.
Brug til en shop altid et rigtigt cronjob (hvert et til fem minutter) i stedet for WP-Cron ved besøg.
Kontrollér WooCommerce > Status > Skemalagte handlinger: mange forsinkede ventende eller mislykkede handlinger er et tegn på, at cron eller en integration ikke virker.
På staging: betalingsudbyder i testtilstand, mail og integrationer slået fra, gennemgå skemalagte handlinger, begræns persondata.
Læg aldrig en stagingdatabase over en kørende shop; udfør ændringerne igen på produktion.

Quiz

Opgave

Opgave A7.3: Er dit staging-miljø afskærmet? Det er den samme kontrol som opgave A8.3 i WordPress-kurset. Først skal du bruge et ejerskabsbevis for dit domæne (en TXT-record _weboke-cursus.<domein> eller en fil /.well-known/weboke-cursus-<code>.txt med den kode, du får). Udfyld derefter adressen på din shop og adressen på dit staging-miljø (en host under samme domæne). Programmet henter forsiden af staging-miljøet uden loginoplysninger og forsiden af produktion. Grøn, hvis staging-miljøet beder om en adgangskode (401), eller hvis det har noindex og bruger sin egen adresse (REST-indgangen peger på staginghosten), mens produktion ikke har noindex. Orange, hvis staging-miljøet har noindex, men ingen adgangskode, eller intet gyldigt certifikat. Rød, hvis staging-miljøet er åbent og kan indekseres, hvis staging-miljøet stadig peger på produktionens adresse, eller hvis produktion ved en fejl har noindex.

Spørgsmål til dig selv (rettes ikke): Står betalingsudbyderen på dit staging-miljø i testtilstand? Er mailen slået fra eller omdirigeret? Er integrationer og webhooks slået fra? Hvor mange ventende og mislykkede handlinger står der lige nu under Skemalagte handlinger på produktion?

Læs videre

Disse artikler beskriver trinnene i WebOkés paneler; i andre paneler fungerer de på samme måde.

Cookies hos WebOké

Cookieindstillinger

Nødvendige

Marketing