Cron, Action Scheduler și staging

Modulul 7: Vizibilitate și găzduire · Timp de citire: 10 minute

Obiectiv de învățare: După această lecție puteți explica modul în care WooCommerce execută sarcini în fundal, puteți verifica acțiunile programate și le puteți repara în caz de probleme. De asemenea, puteți configura un mediu de staging pentru un magazin astfel încât clienții, plățile și comenzile reale să nu fie afectate.

Noțiuni cheie: WP-Cron, cron real, DISABLE_WP_CRON, Action Scheduler, acțiuni programate, în așteptare, finalizat, eșuat, curățare, staging pentru un magazin, modul de test al furnizorului de plăți, e-mail dezactivat, webhook-uri, integrări, nu restaurați baza de date peste producție

Ce se întâmplă când nu se uită nimeni

Un magazin face multă muncă ce nu ține direct de un clic al unui vizitator:

• anulează comenzile neplătite după ce a expirat timpul de reținere a stocului (lecția 3.4);
• trimite e-mailuri după o schimbare de stare, precum și webhook-uri către integrări;
• actualizează rapoartele și statisticile din panoul de administrare;
• curăță sesiunile expirate și datele temporare;
• aplică perioadele de păstrare din Conturi și confidențialitate (lecția 2.3);
• în cazul abonamentelor sau al integrărilor cu programe de contabilitate: încasează plăți și transmite date.

Pentru aceasta, WordPress folosește WP-Cron, iar WooCommerce folosește în plus Action Scheduler. Dacă acestea nu funcționează corect, nu observați imediat. Observați abia atunci când comenzile neplătite continuă să rețină stoc, rapoartele rămân goale sau o integrare rămâne cu zile în urmă.

WP-Cron și cron real

Cum funcționează WP-Cron și de ce un cron job real este mai bun este explicat în cursul WordPress, lecția 6.3: WP-Cron rulează la vizite, nu după ceas. Acest lucru este nesigur când aveți puțini vizitatori și solicitant când aveți mulți. Soluția: DISABLE_WP_CRON în wp-config.php și un cron job în panoul de găzduire care rulează wp-cron.php la fiecare câteva minute.

Pentru un magazin, aceasta nu este o optimizare, ci o cerință:

• Noaptea, când sunt puțini vizitatori, comenzile neplătite trebuie totuși anulate la timp.
• În timpul unei promoții aglomerate nu doriți ca o sarcină grea din fundal să se execute pe cererea de pagină a unui client care vrea să finalizeze comanda.

La WebOké creați o astfel de sarcină în DirectAdmin, la Cron Jobs (DA 15.1, KB 48), cu /usr/local/bin/php drept cale către PHP; la alți furnizori de găzduire funcționează similar, în ecranul lor pentru cron. Pentru un magazin alegeți un interval de unu până la cinci minute, mai degrabă decât zece. O sarcină care rulează în fiecare minut și nu are nimic de făcut nu costă aproape nimic.

Action Scheduler: coada de așteptare a WooCommerce

Action Scheduler este o coadă de așteptare pentru sarcini în fundal, livrată împreună cu WooCommerce și folosită și de multe alte module (abonamente, integrări cu programe de contabilitate, e-mail marketing). Fiecare sarcină este o acțiune cu un moment de execuție și o stare. Coada este procesată printr-o sarcină WP-Cron (action_scheduler_run_queue), așa că și aici este valabil: fără un cron de încredere, coada rămâne în urmă.

Vedeți totul la WooCommerce > Stare > Acțiuni programate (Scheduled Actions). Există file pentru fiecare stare:

Conform codului sursă, Action Scheduler șterge implicit acțiunile finalizate și anulate după o lună, iar pe cele eșuate după trei luni. Dacă tabelul crește totuși foarte mult, probabil rulează multe acțiuni care eșuează sau sunt create din nou și din nou; aflați ce modul le creează (coloana Grup și numele hook-ului vă ajută), în loc să goliți doar tabelul.

Un exemplu practic de la Theehuis Example: după o schimbare de parolă, integrarea cu programul de contabilitate a pus fiecare comandă în coadă ca acțiune eșuată. După o săptămână existau 400 de acțiuni eșuate și lipseau 60 de facturi (lecția 5.6). După repararea integrării, administratorul a putut rula din nou acțiunile, una câte una, cu Run now (Run).

Staging pentru un magazin

Ce este un mediu de staging, cum îl creați și cum îl protejați (parolă, noindex) este explicat în cursul WordPress, lecția 8.3. La WebOké puteți face acest lucru prin clonare în Installatron (DA 13.7, KB 232) și printr-un director protejat cu parolă (DA 15.9); alți furnizori de găzduire au instrumente similare. Pentru un magazin se adaugă câteva lucruri, deoarece o copie a unui magazin conține date reale ale clienților și poate executa acțiuni reale.

Imediat după clonare, înainte de a face orice altceva:

1. Furnizorul de plăți în modul de test, cu chei de test. Un mediu de staging cu chei live poate primi plăți reale sau poate efectua rambursări.
2. E-mailul dezactivat sau redirecționat. Altfel, o copie trimite confirmări, mementouri și e-mailuri pentru coșuri abandonate către clienți reali. Folosiți un modul care blochează toate e-mailurile sau le trimite la o singură adresă de test.
3. Integrările și webhook-urile dezactivate. Contabilitate, sincronizarea stocului, etichete de expediere, e-mail marketing: altfel, mediul de staging înregistrează facturi sau expediază colete. Verificați și WooCommerce > Setări > Avansate > Cârlige web, precum și cheile API.
4. Verificați acțiunile programate. Coada a fost copiată odată cu restul. Altfel, acțiunile în așteptare (un e-mail de memento, o plată de abonament) rulează încă o dată pe staging.
5. Limitați datele cu caracter personal. Dacă nu aveți nevoie de date reale ale clienților pentru teste, ștergeți-le sau anonimizați-le pe staging. Un mediu de staging intră și el sub incidența GDPR și este adesea mai slab securizat (lecția 5.5).

Și cea mai importantă regulă la restaurare: nu puneți niciodată baza de date din staging peste un magazin activ. Între momentul clonării și cel al restaurării s-au adăugat comenzi, clienți, modificări de stoc și plăți; pe acestea le-ați pierde. Refaceți modificările în producție (acum știți că funcționează) sau sincronizați doar fișierele. Dacă trebuie totuși să includeți baza de date, faceți acest lucru numai cu magazinul în modul de mentenanță, imediat după o copie de siguranță proaspătă și cu un instrument care omite comenzile și clienții.

Testarea unei actualizări pe staging

Un parcurs tipic pentru o actualizare majoră a WooCommerce sau a unui modul de plată:

1. Creați un mediu de staging nou (o clonă a producției) și rezolvați cele cinci puncte de mai sus.
2. Actualizați pe staging și rulați actualizarea bazei de date dacă WooCommerce o solicită.
3. Plasați o comandă de test în modul de test: plată, plată eșuată, rambursare (lecția 4.5).
4. Verificați la Acțiuni programate și în jurnalul de erori dacă au apărut erori noi.
5. Apoi actualizați producția într-un moment liniștit, cu o copie de siguranță făcută chiar înainte (lecția 6.2).

Rezumat

• WooCommerce face multă muncă în fundal; aceasta rulează prin WP-Cron și Action Scheduler.
• Pentru un magazin folosiți întotdeauna un cron job real (la fiecare unu până la cinci minute) în loc de WP-Cron declanșat de vizite.
• Verificați WooCommerce > Stare > Acțiuni programate: multe acțiuni în așteptare restante sau eșuate sunt un semn că cron-ul sau o integrare nu funcționează.
• Pe staging: furnizorul de plăți în modul de test, e-mailul și integrările dezactivate, acțiunile programate verificate, datele cu caracter personal limitate.
• Nu puneți niciodată o bază de date din staging peste un magazin activ; refaceți modificările în producție.

Test (quiz)

Exercițiu

Exercițiul A7.3: Este mediul dumneavoastră de staging protejat? Aceasta este aceeași verificare ca exercițiul A8.3 din cursul WordPress. Mai întâi aveți nevoie de o dovadă de proprietate pentru domeniul dumneavoastră (o înregistrare TXT _weboke-cursus.<domein> sau un fișier /.well-known/weboke-cursus-<code>.txt cu codul pe care îl primiți). Apoi introduceți adresa magazinului și adresa mediului de staging (o gazdă sub același domeniu). Programul solicită pagina principală a mediului de staging, fără date de autentificare, precum și pe cea a producției. Verde dacă mediul de staging cere o parolă (401) sau dacă are noindex și își folosește propria adresă (punctul de acces REST indică gazda de staging), în timp ce producția nu are noindex. Portocaliu dacă mediul de staging are noindex, dar nu are parolă sau nu are un certificat valid. Roșu dacă mediul de staging este deschis și indexabil, dacă mediul de staging indică încă adresa producției sau dacă producția are din greșeală noindex.

Întrebări pentru dumneavoastră (nu sunt verificate): este furnizorul de plăți de pe mediul de staging în modul de test? Este e-mailul dezactivat sau redirecționat? Sunt integrările și webhook-urile dezactivate? Câte acțiuni în așteptare și eșuate există acum la Acțiuni programate în producție?

Lecturi suplimentare

Aceste articole descriu pașii din panourile WebOké; în alte panouri funcționează similar.

• Manual DirectAdmin 15.1: Cron Jobs: rularea automată a sarcinilor
• Crearea unui cronjob sau a unei sarcini programate (și ce să faceți dacă nu se execută)
• Crearea unui mediu de staging WordPress
• Manual DirectAdmin 13.7: Clonarea și crearea unui mediu de testare (staging)
• Manual DirectAdmin 15.9: Mape protejate prin parolă
• Curs gratuit WordPress 8.3: Staging: testare în siguranță
• Curs gratuit WordPress 6.3: Imagini, PHP și alte câștiguri de viteză
• Action Scheduler (actionscheduler.org, în engleză): https://actionscheduler.org/