Cron, Action Scheduler ja testiympäristö (staging)

Moduuli 7: Löydettävyys ja webhotelli · Lukuaika: 10 minuuttia

Oppimistavoite: Tämän oppitunnin jälkeen osaat selittää, miten WooCommerce suorittaa tehtäviä taustalla. Osaat myös tarkistaa ajastetut toiminnot, korjata ne ongelmatilanteissa ja rakentaa verkkokaupalle testiympäristön (staging) niin, ettei siitä aiheudu haittaa oikeille asiakkaille, maksuille tai tilauksille.

Keskeiset käsitteet: WP-Cron, oikea cron, DISABLE_WP_CRON, Action Scheduler, ajastetut toiminnot, odottava, valmis, epäonnistunut, siivous, verkkokaupan testiympäristö, maksupalvelun testitila, sähköposti pois päältä, verkkotoimintokutsut (webhooks), integraatiot, tietokantaa ei palauteta tuotannon päälle

Mitä tapahtuu, kun kukaan ei katso

Verkkokauppa tekee paljon työtä, joka ei liity suoraan kävijän klikkaukseen:

• maksamattomien tilausten peruminen, kun varaston pidätysaika on kulunut (oppitunti 3.4);
• sähköpostien lähettäminen tilan muuttuessa ja verkkotoimintokutsujen lähettäminen integraatioille;
• raporttien ja tilastojen päivittäminen hallintapaneelissa;
• vanhentuneiden istuntojen ja väliaikaisten tietojen siivoaminen;
• Tilit Yksityisyys -asetusten säilytysaikojen toteuttaminen (oppitunti 2.3);
• tilausten tai kirjanpitointegraatioiden yhteydessä: maksujen veloittaminen ja tietojen välittäminen eteenpäin.

Tähän WordPress käyttää WP-Cronia, ja WooCommerce käyttää sen lisäksi Action Scheduleria. Jos ne eivät toimi kunnolla, et huomaa sitä heti. Huomaat sen, kun maksamattomat tilaukset pitävät varastoa varattuna, raportit pysyvät tyhjinä tai integraatio on päiviä jäljessä.

WP-Cron ja oikea cron

WordPress-kurssin oppitunnilla 6.3 kerrotaan, miten WP-Cron toimii ja miksi oikea cron-tehtävä on parempi: WP-Cron käynnistyy käyntien yhteydessä, ei kellon mukaan. Se on epäluotettava, kun kävijöitä on vähän, ja kuormittava, kun heitä on paljon. Ratkaisu: DISABLE_WP_CRON tiedostoon wp-config.php ja webhotellin hallintapaneeliin cron-tehtävä, joka ajaa tiedoston wp-cron.php muutaman minuutin välein.

Verkkokaupalle tämä ei ole optimointi vaan välttämättömyys:

• Yöllä, kun kävijöitä on vähän, maksamattomat tilaukset on silti peruttava ajallaan.
• Vilkkaan kampanjan aikana et halua, että raskas taustatehtävä ajetaan kassalle menevän asiakkaan sivupyynnön yhteydessä.

WebOkéssa tällainen tehtävä luodaan DirectAdminissa kohdassa Cron Jobs (DA 15.1, KB 48), ja PHP:n polkuna käytetään /usr/local/bin/php. Muilla palveluntarjoajilla tämä toimii samaan tapaan niiden cron-näkymässä. Valitse verkkokaupalle yhden ja viiden minuutin välinen aikaväli, mieluummin kuin kymmenen. Joka minuutti ajettava tehtävä, jolla ei ole mitään tehtävää, ei maksa juuri mitään.

Action Scheduler: WooCommercen jono

Action Scheduler on taustatehtävien jono, joka tulee WooCommercen mukana ja jota käyttävät myös monet muut lisäosat (tilaukset, kirjanpitointegraatiot, sähköpostimarkkinointi). Jokainen tehtävä on toiminto, jolla on ajankohta ja tila. Jono käsitellään WP-Cron-tehtävän (action_scheduler_run_queue) kautta, joten tässäkin pätee: ilman luotettavaa cronia jono jää jälkeen.

Näet kaiken kohdassa WooCommerce > Tila > Ajastetut toiminnot (Scheduled Actions). Jokaisella tilalla on oma välilehtensä:

Lähdekoodin mukaan Action Scheduler siivoaa valmiit ja perutut toiminnot oletuksena kuukauden kuluttua ja epäonnistuneet kolmen kuukauden kuluttua. Jos taulukko kasvaa silti nopeasti, käynnissä on todennäköisesti paljon toimintoja, jotka epäonnistuvat yhä uudelleen tai joita luodaan jatkuvasti lisää. Selvitä, mikä lisäosa niitä luo (Ryhmä-sarake ja hookin nimi auttavat), sen sijaan että vain tyhjentäisit taulukon.

Käytännön esimerkki Theehuis Examplesta: kirjanpito-ohjelman integraatio lisäsi salasanan vaihdon jälkeen jokaisen tilauksen jonoon epäonnistuneena toimintona. Viikon kuluttua epäonnistuneita toimintoja oli 400 ja 60 laskua puuttui (oppitunti 5.6). Kun integraatio oli korjattu, ylläpitäjä pystyi ajamaan toiminnot uudelleen yksitellen painikkeella Run now (Run).

Verkkokaupan testiympäristö

WordPress-kurssin oppitunnilla 8.3 kerrotaan, mikä testiympäristö (staging) on, miten sellainen luodaan ja miten se suojataan (salasana, noindex). WebOkéssa sen voi tehdä kloonaamalla Installatronissa (DA 13.7, KB 232) ja salasanalla suojatulla kansiolla (DA 15.9); muilla palveluntarjoajilla on vastaavia työkaluja. Verkkokaupassa tähän tulee lisää huomioitavaa, koska kaupan kopio sisältää oikeita asiakastietoja ja voi suorittaa oikeita toimintoja.

Heti kloonauksen jälkeen, ennen kuin teet mitään muuta:

1. Maksupalvelu testitilaan testiavaimilla. Testiympäristö, jossa on tuotantoavaimet, voi vastaanottaa oikeita maksuja tai tehdä palautuksia.
2. Sähköposti pois päältä tai uudelleenohjattuna. Muuten kopio lähettää vahvistuksia, muistutuksia ja hylätyn ostoskorin viestejä oikeille asiakkaille. Käytä lisäosaa, joka pysäyttää kaiken postin tai lähettää sen yhteen testiosoitteeseen.
3. Integraatiot ja verkkotoimintokutsut pois päältä. Kirjanpito, varastosynkronointi, lähetystarrat, sähköpostimarkkinointi: muuten testiympäristö kirjaa laskuja tai lähettää paketteja. Tarkista myös WooCommerce > Asetukset > Edistyneet > Verkkotoimintokutsut ja API-avaimet.
4. Käy ajastetut toiminnot läpi. Jono on kopioitunut mukana. Muuten odottavat toiminnot (muistutusviesti, tilauksen maksu) ajetaan testiympäristössä uudelleen.
5. Rajoita henkilötietoja. Jos et tarvitse oikeita asiakastietoja testaamiseen, poista tai anonymisoi ne testiympäristössä. Testiympäristö kuuluu GDPR:n piiriin ja on usein heikommin suojattu (oppitunti 5.5).

Ja tärkein sääntö palautettaessa: älä koskaan palauta testiympäristön tietokantaa toiminnassa olevan kaupan päälle. Kloonauksen ja palautuksen välillä on tullut uusia tilauksia, asiakkaita, varastomuutoksia ja maksuja, ja ne menetetään. Tee muutokset uudelleen tuotannossa (tiedät nyt, että ne toimivat) tai synkronoi vain tiedostot. Jos tietokanta on pakko siirtää, tee se vain kaupan ollessa huoltotilassa, heti tuoreen varmuuskopion jälkeen ja työkalulla, joka ohittaa tilaukset ja asiakkaat.

Päivityksen testaaminen testiympäristössä

Tyypillinen eteneminen WooCommercen tai maksulisäosan suuressa päivityksessä:

1. Luo tuore testiympäristö (tuotannon klooni) ja hoida yllä olevat viisi kohtaa kuntoon.
2. Päivitä testiympäristössä ja suorita tietokannan päivitys, jos WooCommerce pyytää sitä.
3. Tee testitilaus testitilassa: maksu, epäonnistunut maksu, palautus (oppitunti 4.5).
4. Tarkista Ajastetut toiminnot ja virheloki uusien virheiden varalta.
5. Päivitä sen jälkeen tuotanto rauhalliseen aikaan, ja ota varmuuskopio juuri ennen sitä (oppitunti 6.2).

Yhteenveto

• WooCommerce tekee paljon työtä taustalla; se toimii WP-Cronin ja Action Schedulerin kautta.
• Käytä verkkokaupassa aina oikeaa cron-tehtävää (yhden ja viiden minuutin välein) käyntien yhteydessä toimivan WP-Cronin sijaan.
• Tarkista WooCommerce > Tila > Ajastetut toiminnot: suuri määrä myöhässä olevia odottavia tai epäonnistuneita toimintoja on merkki siitä, että cron tai integraatio ei toimi.
• Testiympäristössä: maksupalvelu testitilaan, sähköposti ja integraatiot pois päältä, ajastetut toiminnot läpi, henkilötiedot minimiin.
• Älä koskaan palauta testiympäristön tietokantaa toiminnassa olevan kaupan päälle; tee muutokset uudelleen tuotannossa.

Tietovisa (quiz)

Tehtävä

Tehtävä A7.3: Onko testiympäristösi (staging) suojattu? Tämä on sama tarkistus kuin WordPress-kurssin tehtävä A8.3. Tarvitset ensin todisteen verkkotunnuksesi omistajuudesta (TXT-tietue _weboke-cursus.<domein> tai tiedosto /.well-known/weboke-cursus-<code>.txt, jossa on saamasi koodi). Syötä sen jälkeen kauppasi osoite ja testiympäristösi osoite (saman verkkotunnuksen alla oleva host). Ohjelma hakee testiympäristön etusivun ilman kirjautumistietoja sekä tuotannon etusivun. Vihreä, jos testiympäristö pyytää salasanaa (401) tai jos sillä on noindex ja se käyttää omaa osoitettaan (REST-osoite osoittaa testiympäristön hostiin), eikä tuotannossa ole noindexiä. Oranssi, jos testiympäristöllä on noindex mutta ei salasanaa tai jos sillä ei ole voimassa olevaa varmennetta. Punainen, jos testiympäristö on avoin ja indeksoitavissa, jos testiympäristö osoittaa yhä tuotannon osoitteeseen tai jos tuotannossa on vahingossa noindex.

Kysymyksiä itsellesi (ei tarkisteta): onko testiympäristösi maksupalvelu testitilassa? Onko sähköposti pois päältä tai uudelleenohjattu? Onko integraatiot ja verkkotoimintokutsut poistettu käytöstä? Montako odottavaa ja epäonnistunutta toimintoa tuotannon Ajastetuissa toiminnoissa on nyt?

Lue lisää

Nämä artikkelit kuvaavat vaiheet WebOkén hallintapaneeleissa; muissa paneeleissa ne toimivat samaan tapaan.

• DirectAdmin-ohje 15.1: Cron Jobs: tehtävien automaattinen ajaminen
• Cronjobin tai ajastetun tehtävän luominen (ja mitä tehdä, jos se ei suoritu)
• Luo WordPress-staging-ympäristö
• DirectAdmin-ohje 13.7: Kloonaaminen ja testiympäristön (staging) luominen
• DirectAdmin-ohje 15.9: Salasanalla suojatut hakemistot
• Ilmainen WordPress-kurssi 8.3: Staging: turvallista testaamista
• Ilmainen WordPress-kurssi 6.3: Kuvat, PHP ja muita nopeusvoittoja
• Action Scheduler (actionscheduler.org, englanniksi): https://actionscheduler.org/