Cron, Action Scheduler és staging

Modul 7: Láthatóság és tárhely · Olvasási idő: 10 perc

Tanulási cél: A lecke után el tudja magyarázni, hogyan futtatja a WooCommerce a feladatokat a háttérben. Ellenőrizni tudja az időzített műveleteket, és probléma esetén helyre tudja állítani őket. Egy webáruházhoz úgy tud staging környezetet berendezni, hogy valódi vásárlókat, fizetéseket és rendeléseket ne érintsen.

Kulcsfogalmak: WP-Cron, valódi cron, DISABLE_WP_CRON, Action Scheduler, időzített műveletek, várakozó, befejezett, sikertelen, takarítás, staging egy webáruházhoz, a fizetési szolgáltató tesztmódja, levelezés kikapcsolása, webkapcsok, integrációk, az adatbázist ne állítsa vissza az éles rendszerre

Ami akkor történik, amikor senki sem figyel

Egy webáruház sok olyan munkát végez, amely nem közvetlenül egy látogató kattintásához tartozik:

• a ki nem fizetett rendelések megszakítása, ha lejárt a készlet visszatartására szánt idő (3.4. lecke);
• e-mailek küldése állapotváltozás után, valamint webkapcsok küldése az integrációknak;
• a jelentések és statisztikák frissítése az adminisztrációs felületen;
• a lejárt munkamenetek és ideiglenes adatok törlése;
• a Fiókok és adatvédelem részben megadott megőrzési idők végrehajtása (2.3. lecke);
• előfizetéseknél vagy könyvelési integrációknál: fizetések beszedése és adatok továbbítása.

Erre a WordPress a WP-Cron rendszert használja, a WooCommerce pedig erre építve az Action Scheduler eszközt. Ha ezek nem működnek megfelelően, azt nem veszi észre azonnal. Akkor tűnik fel, amikor a ki nem fizetett rendelések továbbra is lefoglalják a készletet, a jelentések üresek maradnak, vagy egy integráció napokkal le van maradva.

WP-Cron és valódi cron

Hogy hogyan működik a WP-Cron, és miért jobb egy valódi cronfeladat, azt a WordPress-tanfolyam 6.3. leckéje ismerteti: a WP-Cron a látogatásokkor fut, nem óra szerint, ezért kevés látogató esetén megbízhatatlan, sok látogató esetén pedig terhelő. A megoldás: DISABLE_WP_CRON a wp-config.php fájlban, és egy cronfeladat a tárhely vezérlőpultján, amely néhány percenként lefuttatja a wp-cron.php fájlt.

Egy webáruház esetében ez nem optimalizálás, hanem követelmény:

• Éjszaka, amikor kevés a látogató, a ki nem fizetett rendeléseket akkor is időben meg kell szakítani.
• Egy forgalmas akció idején pedig éppen azt nem szeretné, hogy egy nehéz háttérfeladat annak a vásárlónak az oldalkérésére terhelődjön, aki éppen fizetni szeretne.

A WebOké-nál ilyen feladatot a DirectAdmin Időzített feladatok részében hozhat létre (DA 15.1, KB 48), a PHP elérési útjaként a /usr/local/bin/php megadásával; más tárhelyszolgáltatóknál hasonlóan működik a saját cron képernyőjükön. Egy webáruházhoz egy és öt perc közötti időközt válasszon, ne tíz percet. Egy percenként futó feladat, amelynek nincs teendője, szinte semmibe sem kerül.

Action Scheduler: a WooCommerce várólistája

Az Action Scheduler egy háttérfeladatokhoz készült várólista, amelyet a WooCommerce magával hoz, és amelyet sok más bővítmény is használ (előfizetések, könyvelési integrációk, e-mail-marketing). Minden feladat egy művelet, időponttal és állapottal. A várólistát egy WP-Cron-feladat (action_scheduler_run_queue) dolgozza fel, így itt is érvényes: megbízható cron nélkül a várólista lemarad.

Mindent megtalál a WooCommerce > Állapot > Időzített műveletek (Scheduled Actions) részben. Állapotonként külön fülek vannak:

A forráskód szerint az Action Scheduler a befejezett és megszakított műveleteket alapértelmezésként egy hónap után törli, a sikerteleneket három hónap után. Ha a tábla ennek ellenére erősen nő, akkor valószínűleg sok olyan művelet fut, amely újra és újra sikertelen, vagy újra és újra létrejön; derítse ki, melyik bővítmény hozza létre őket (ebben a Csoport oszlop és a hook neve segít), ahelyett, hogy csak kiürítené a táblát.

Egy gyakorlati példa a Theehuis Example-nél: a könyvelőprogrammal való integráció egy jelszóváltoztatás után minden rendelést sikertelen műveletként tett a várólistára. Egy hét után 400 sikertelen művelet gyűlt össze, és 60 számla hiányzott (5.6. lecke). Az integráció helyreállítása után az adminisztrátor egyenként újra lefuttathatta a műveleteket a Futtatás (Run) paranccsal.

Staging egy webáruházhoz

Hogy mi a staging, hogyan hozhat létre egyet, és hogyan védheti le (jelszó, noindex), azt a WordPress-tanfolyam 8.3. leckéje ismerteti. A WebOké-nál ez az Installatron klónozási funkciójával (DA 13.7, KB 232) és egy jelszóval védett mappával (DA 15.9) oldható meg; más tárhelyszolgáltatóknál hasonló eszközök állnak rendelkezésre. Egy webáruháznál ehhez néhány további szempont is társul, mert egy webáruház másolata valódi vásárlói adatokat tartalmaz, és valódi műveleteket hajthat végre.

Közvetlenül a klónozás után, mielőtt bármi mást tenne:

1. A fizetési szolgáltató tesztmódban, tesztkulcsokkal. Egy éles kulcsokkal működő staging valódi fizetéseket fogadhat, vagy visszatérítéseket hajthat végre.
2. A levelezés kikapcsolva vagy átirányítva. Különben a másolat visszaigazolásokat, emlékeztetőket és elhagyott kosárra figyelmeztető leveleket küld valódi vásárlóknak. Használjon olyan bővítményt, amely minden levelet visszatart, vagy egyetlen tesztcímre küld.
3. Integrációk és webkapcsok kikapcsolva. Könyvelés, készletszinkronizálás, szállítási címkék, e-mail-marketing: különben a staging számlákat könyvel vagy csomagokat ad fel. Nézze meg a WooCommerce > Beállítások > Haladó > Webkapcsok részt és az API-kulcsokat is.
4. Az időzített műveletek átnézése. A várólista is átmásolódott. A várakozó műveletek (egy emlékeztető levél, egy előfizetési díj beszedése) különben a stagingen még egyszer lefutnak.
5. A személyes adatok korlátozása. Ha a teszteléshez nincs szüksége valódi vásárlói adatokra, törölje vagy anonimizálja őket a stagingen. A staging is a GDPR hatálya alá tartozik, és gyakran kevésbé jól védett (5.5. lecke).

A visszaállítás legfontosabb szabálya pedig: soha ne írja felül egy működő webáruház adatbázisát a staging adatbázisával. A klónozás és a visszaállítás között rendelések, vásárlók, készletmozgások és fizetések keletkeztek; ezek elvesznének. Hajtsa végre a módosításokat újra az éles rendszeren (most már tudja, hogy működnek), vagy csak a fájlokat szinkronizálja. Ha mégis az adatbázissal kell, akkor csak karbantartási módban lévő webáruházzal tegye, közvetlenül egy friss biztonsági mentés után, és olyan eszközzel, amely kihagyja a rendeléseket és a vásárlókat.

Frissítés tesztelése a stagingen

Egy tipikus menet a WooCommerce vagy egy fizetési bővítmény nagyobb frissítéséhez:

1. Készítsen friss stagingot (az éles rendszer klónját), és állítsa be a fenti öt pontot.
2. Frissítsen a stagingen, és futtassa le az adatbázis-frissítést, ha a WooCommerce kéri.
3. Adjon le egy tesztrendelést tesztmódban: fizetés, sikertelen fizetés, visszatérítés (4.5. lecke).
4. Nézze meg az Időzített műveletek részt és a hibanaplót, hogy vannak-e új hibák.
5. Ezután frissítse az éles rendszert egy nyugodt időpontban, közvetlenül előtte készült biztonsági mentéssel (6.2. lecke).

Összefoglalás

• A WooCommerce sok munkát végez a háttérben; ez a WP-Cron és az Action Scheduler segítségével fut.
• Webáruházhoz mindig valódi cronfeladatot használjon (egy-öt percenként) a látogatásokkor futó WP-Cron helyett.
• Ellenőrizze a WooCommerce > Állapot > Időzített műveletek részt: sok lemaradt várakozó vagy sikertelen művelet azt jelzi, hogy a cron vagy egy integráció nem működik.
• A stagingen: a fizetési szolgáltató tesztmódban, a levelezés és az integrációk kikapcsolva, az időzített műveletek átnézve, a személyes adatok korlátozva.
• Soha ne írja felül egy működő webáruház adatbázisát a staging adatbázisával; a módosításokat hajtsa végre újra az éles rendszeren.

Kvíz

Feladat

A7.3. feladat: Védett az Ön staging környezete? Ez ugyanaz az ellenőrzés, mint a WordPress-tanfolyam A8.3. feladata. Először tulajdonjog-igazolásra van szüksége a domainjéhez (egy TXT-rekord _weboke-cursus.<domein> vagy egy /.well-known/weboke-cursus-<code>.txt fájl a kapott kóddal). Ezután adja meg webáruháza címét és a staging címét (egy hosztot ugyanazon a domainen). A program bejelentkezési adatok nélkül lekéri a staging kezdőlapját, valamint az éles rendszerét. Zöld, ha a staging jelszót kér (401), vagy ha noindex beállítású és a saját címét használja (a REST-belépési pont a staging hosztra mutat), miközben az éles rendszeren nincs noindex. Narancssárga, ha a stagingen van noindex, de nincs jelszó, vagy nincs érvényes tanúsítványa. Piros, ha a staging nyitott és indexelhető, ha a staging még az éles rendszer címére mutat, vagy ha az éles rendszeren véletlenül noindex van.

Kérdések önmagának (nem kerülnek ellenőrzésre): tesztmódban van a fizetési szolgáltató a stagingen? Ki van kapcsolva vagy át van irányítva a levelezés? Ki vannak kapcsolva az integrációk és a webkapcsok? Hány várakozó és sikertelen művelet áll most az éles rendszer Időzített műveletek részében?

Bővebben olvasva

Ezek a cikkek a WebOké vezérlőpultjainak lépéseit írják le; más vezérlőpultokban hasonlóan működnek.

• DirectAdmin útmutató 15.1: Időzített feladatok: feladatok automatikus futtatása
• Időzített feladat (cronjob) létrehozása (és teendők, ha az nem fut le)
• WordPress staging környezet létrehozása
• DirectAdmin útmutató 13.7: Klónozás és tesztkörnyezet (staging) létrehozása
• DirectAdmin útmutató 15.9: Jelszóval védett könyvtárak
• Ingyenes WordPress-tanfolyam 8.3: Staging: biztonságos tesztelés
• Ingyenes WordPress-tanfolyam 6.3: Képek, PHP és egyéb sebességnövelő megoldások
• Action Scheduler (actionscheduler.org, angol nyelven): https://actionscheduler.org/