Cron, Action Scheduler og staging

Modul 7: Bli funnet og hosting · Lesetid: 10 minutter

Læringsmål: Etter denne leksjonen kan du forklare hvordan WooCommerce kjører oppgaver i bakgrunnen, sjekke de planlagte handlingene og rette dem opp ved problemer, og sette opp et stagingmiljø for en nettbutikk slik at ingen ekte kunder, betalinger eller bestillinger blir rammet.

Nøkkelbegreper: WP-Cron, ekte cron, DISABLE_WP_CRON, Action Scheduler, planlagte handlinger, venter, fullført, mislyktes, opprydding, staging for en nettbutikk, testmodus hos betalingsleverandøren, e-post av, webhooks, integrasjoner, ikke legg databasen tilbake over produksjon

Det som skjer når ingen ser på

En nettbutikk gjør mye arbeid som ikke henger direkte sammen med et klikk fra en besøkende:

• kansellere ubetalte bestillinger når tiden for å holde av lager er ute (leksjon 3.4);
• sende e-post etter en statusendring, og webhooks til integrasjoner;
• oppdatere rapporter og statistikk i administrasjonen;
• rydde opp i utløpte økter og midlertidige data;
• gjennomføre oppbevaringstidene fra Kontoer og personvern (leksjon 2.3);
• ved abonnementer eller regnskapsintegrasjoner: trekke betalinger og sende videre data.

Til dette bruker WordPress WP-Cron, og WooCommerce bruker i tillegg Action Scheduler. Hvis de ikke kjører som de skal, merker du det ikke med en gang. Du merker det når ubetalte bestillinger fortsetter å holde av lager, rapporter forblir tomme eller en integrasjon ligger flere dager etter.

WP-Cron og ekte cron

Hvordan WP-Cron fungerer og hvorfor en ekte cronjobb er bedre, står i WordPress-kurset, leksjon 6.3: WP-Cron kjører ved besøk, ikke etter en klokke, og det er upålitelig med få besøkende og belastende med mange besøkende. Løsningen: DISABLE_WP_CRON i wp-config.php og en cronjobb i hostingpanelet ditt som kjører wp-cron.php med noen minutters mellomrom.

For en nettbutikk er det ikke en optimalisering, men et krav:

• Om natten, når det er få besøkende, må ubetalte bestillinger likevel kanselleres i tide.
• Under en travel kampanje vil du nettopp ikke at en tung bakgrunnsoppgave skal henge seg på sidevisningen til en kunde som vil betale.

Hos WebOké lager du en slik oppgave i DirectAdmin under Cron Jobs (DA 15.1, KB 48), med /usr/local/bin/php som sti til PHP; hos andre leverandører fungerer det på lignende måte i cronbildet deres. Velg et intervall på ett til fem minutter for en nettbutikk, heller enn ti. En oppgave som kjører hvert minutt og ikke har noe å gjøre, koster nesten ingenting.

Action Scheduler: køen til WooCommerce

Action Scheduler er en kø for bakgrunnsoppgaver som følger med WooCommerce, og som også brukes av mange andre utvidelser (abonnementer, regnskapsintegrasjoner, e-postmarkedsføring). Hver oppgave er en handling med et tidspunkt og en status. Køen behandles via en WP-Cron-oppgave (action_scheduler_run_queue), så også her gjelder det: uten pålitelig cron havner køen på etterskudd.

Du ser alt under WooCommerce > Status > Planlagte handlinger (Scheduled Actions). Det finnes faner per status:

Ifølge kildekoden rydder Action Scheduler som standard bort fullførte og kansellerte handlinger etter en måned, og mislykkede etter tre måneder. Vokser tabellen likevel kraftig, kjører det sannsynligvis mange handlinger som mislykkes eller opprettes om og om igjen. Finn ut hvilken utvidelse som lager dem (kolonnen Gruppe og navnet på hooken hjelper), i stedet for bare å tømme tabellen.

Et eksempel fra praksis hos Theehuis Example: Etter et passordbytte la integrasjonen med regnskapsprogrammet hver bestilling i køen som en mislykket handling. Etter en uke sto det 400 mislykkede handlinger, og 60 fakturaer manglet (leksjon 5.6). Da integrasjonen var rettet, kunne administratoren kjøre handlingene på nytt én og én med Run now (Run).

Staging for en nettbutikk

Hva staging er, hvordan du lager det og hvordan du skjermer det (passord, noindex), står i WordPress-kurset, leksjon 8.3. Hos WebOké kan du gjøre det med kloning i Installatron (DA 13.7, KB 232) og en passordbeskyttet mappe (DA 15.9); andre leverandører har lignende verktøy. For en nettbutikk kommer det noen ting i tillegg, fordi en kopi av en nettbutikk inneholder ekte kundedata og kan utføre ekte handlinger.

Rett etter kloningen, før du gjør noe annet:

1. Betalingsleverandøren i testmodus, med testnøkler. Et stagingmiljø med live-nøkler kan ta imot ekte betalinger eller utføre refusjoner.
2. E-post av eller omdirigert. Ellers sender en kopi bekreftelser, påminnelser og e-post om forlatte handlekurver til ekte kunder. Bruk en utvidelse som stopper all e-post eller sender den til én testadresse.
3. Integrasjoner og webhooks av. Regnskap, lagersynkronisering, fraktetiketter, e-postmarkedsføring: ellers bokfører staging fakturaer eller sender pakker. Se også under WooCommerce > Innstillinger > Avansert > Webhooks og på API-nøklene.
4. Gå gjennom planlagte handlinger. Køen er kopiert med. Ventende handlinger (en påminnelse på e-post, en abonnementsbetaling) kjører ellers én gang til på staging.
5. Begrens personopplysninger. Trenger du ikke ekte kundedata for å teste, slett eller anonymiser dem på staging. Et stagingmiljø omfattes av GDPR og er ofte dårligere sikret (leksjon 5.5).

Og den viktigste regelen når du legger tilbake: legg aldri databasen fra staging over en nettbutikk som er i drift. Mellom kloningen og tilbakeføringen har det kommet til bestillinger, kunder, lagerendringer og betalinger; dem mister du da. Gjør endringene på nytt i produksjon (du vet nå at de fungerer), eller synkroniser bare filer. Må det likevel gjøres med databasen, gjør det bare med nettbutikken i vedlikeholdsmodus, rett etter en fersk sikkerhetskopi, og med et verktøy som hopper over bestillinger og kunder.

Teste en oppdatering på staging

En typisk fremgangsmåte for en stor oppdatering av WooCommerce eller en betalingsutvidelse:

1. Lag et ferskt stagingmiljø (klon av produksjon) og ordne de fem punktene over.
2. Oppdater på staging og kjør databaseoppdateringen hvis WooCommerce ber om det.
3. Gjør en testbestilling i testmodus: betale, mislykkes, refundere (leksjon 4.5).
4. Sjekk Planlagte handlinger og feilloggen for nye feil.
5. Oppdater deretter produksjon på et rolig tidspunkt, med en sikkerhetskopi rett før (leksjon 6.2).

Sammendrag

• WooCommerce gjør mye arbeid i bakgrunnen; det kjører via WP-Cron og Action Scheduler.
• Bruk alltid en ekte cronjobb (hvert ett til fem minutter) for en nettbutikk i stedet for WP-Cron ved besøk.
• Sjekk WooCommerce > Status > Planlagte handlinger: mange forsinkede ventende eller mislykkede handlinger er et tegn på at cron eller en integrasjon ikke fungerer.
• På staging: betalingsleverandøren i testmodus, e-post og integrasjoner av, gå gjennom planlagte handlinger, begrens personopplysninger.
• Legg aldri en stagingdatabase over en nettbutikk i drift; gjør endringene på nytt i produksjon.

Quiz

Oppgave

Oppgave A7.3: Er stagingmiljøet ditt skjermet? Dette er den samme kontrollen som oppgave A8.3 i WordPress-kurset. Først trenger du et eierskapsbevis for domenet ditt (en TXT-post _weboke-cursus.<domein> eller en fil /.well-known/weboke-cursus-<code>.txt med koden du får). Fyll deretter inn adressen til nettbutikken din og adressen til stagingmiljøet ditt (en vert under samme domene). Programmet henter forsiden til stagingmiljøet, uten innloggingsdata, og forsiden til produksjon. Grønt hvis stagingmiljøet ber om passord (401), eller hvis det har noindex og bruker sin egen adresse (REST-inngangen peker til stagingverten), mens produksjon ikke har noindex. Oransje hvis stagingmiljøet har noindex, men ikke passord, eller ikke har et gyldig sertifikat. Rødt hvis stagingmiljøet er åpent og kan indekseres, hvis stagingmiljøet fortsatt peker til adressen til produksjon, eller hvis produksjon ved en feil har noindex.

Spørsmål til deg selv (rettes ikke): Står betalingsleverandøren i testmodus på stagingmiljøet ditt? Er e-posten slått av eller omdirigert? Er integrasjoner og webhooks slått av? Hvor mange ventende og mislykkede handlinger står det nå under Planlagte handlinger i produksjon?

Les mer

Disse artiklene beskriver stegene i panelene til WebOké; i andre paneler fungerer de på lignende måte.

• DirectAdmin-veiledning 15.1: Cron Jobs: la oppgaver kjøre automatisk
• Opprett en cronjob eller oppgave (og hva du gjør hvis den ikke kjører)
• Opprett et WordPress-stagingmiljø
• DirectAdmin-veiledning 13.7: Klone og lage et testmiljø (staging)
• DirectAdmin-veiledning 15.9: Passordbeskyttede mapper
• Gratis WordPress-kurs 8.3: Staging: trygg testing
• Gratis WordPress-kurs 6.3: Bilder, PHP og andre hastighetsgevinster
• Action Scheduler (actionscheduler.org, engelsk): https://actionscheduler.org/