Cron job și WP-Cron: programări WordPress verificate

Ai ales ora 08:00, articolul este marcat Programat, dar la 08:10 apare încă în administrare ca nepublicat. Poate lipsi cererea care pornește verificarea, poate exista o eroare în callback sau poate fi interpretată greșit ora. Adăugarea unui apel repetat la fiecare câteva secunde nu separă aceste cauze și poate încărca serverul.

Ghidul explică diferența dintre programare, declanșare și execuție. Nu este un manual pentru toate taskurile Linux și nu modifică automat calendarul site-ului. Pentru indisponibilitatea originii în timpul unor loturi, consultă diagnosticul erorii 503. Mai întâi protejăm serviciul, apoi încercăm să recuperăm întârzierile.

Ce face WP-Cron și ce nu face

Documentația WordPress explică faptul că WP-Cron verifică sarcinile scadente la încărcări de pagină, nu continuu. Când nu există declanșări, execuția poate întârzia. ^[1] O programare salvată corect nu este, prin ea însăși, dovada că un proces a pornit la acea secundă.

Separă trei obiecte: evenimentul din listă, cererea care pornește cronul și codul care execută lucrarea. Un articol viitor poate avea un eveniment valid, dar declanșatorul să nu ajungă la WordPress. Invers, endpointul poate răspunde, dar lucrarea să eșueze în PHP.

Această distincție este utilă pentru publicare, emailuri, sincronizări și operațiuni de întreținere. Nu presupune că toate folosesc aceeași coadă. Un plugin poate avea propriul mecanism de loturi, chiar dacă se bazează pe un eveniment WordPress ca să îl pornească periodic.

Notează ora WordPress, nu doar ora telefonului

Verifică fusul orar configurat în WordPress și compară-l cu ora afișată în administrarea programării. Pentru România, o zonă precum Europe/Bucharest gestionează schimbările sezoniere diferit de un offset fix introdus manual. Nu transforma o oră locală în UTC printr-o scădere permanentă de trei ore.

În fișa incidentului notează data completă, ora locală, zona și valoarea salvată. O captură cu „08:00” fără zi și fus nu permite reconstruirea exactă a problemei. Dacă serverul folosește UTC în jurnale, convertește momentul cererii înainte să cauți eroarea.

Testează și o programare în altă zi, nu doar peste un minut. Calendarul automat poate avea reguli de sloturi și limite zilnice. Un articol pus în următorul interval disponibil nu este întârziat doar pentru că utilizatorul se aștepta să fie programat în prima oră vizibilă.

Verifică evenimentul înainte să schimbi declanșatorul

Confirmă că articolul are stare viitoare și că data este în viitor conform WordPress. Apoi verifică existența evenimentului aferent cu un instrument de administrare sau WP-CLI. Comanda de listare a evenimentelor permite inspectarea câmpurilor fără executarea lucrărilor. ^[2]

wp --path=/cale/catre/wordpress cron event list \
  --fields=hook,next_run --format=table

Calea este un exemplu și trebuie înlocuită cu directorul real al instalării. Rulează comanda cu utilizatorul potrivit și numai într-un mediu la care ai acces autorizat. Nu șterge evenimente necunoscute doar pentru că lista pare lungă; pot aparține actualizărilor, comenzilor sau altor servicii.

Dacă evenimentul lipsește, problema este la salvare ori la logica pluginului. Dacă există și este scadent, investighează declanșarea și execuția. Aceste două situații necesită intervenții diferite; un al doilea cron nu repară un eveniment care nu a fost înregistrat niciodată.

Identifică mecanismul care pornește cronul în producție

Verifică dacă folosești declanșarea implicită, un cron al găzduirii, un serviciu extern sau o comandă WP-CLI. Notează frecvența și ultima execuție observată. Nu deduce frecvența din existența unui URL salvat într-un panou: trebuie văzut și istoricul solicitărilor.

WordPress documentează conectarea WP-Cron la un scheduler de sistem și dezactivarea declanșării la încărcarea paginilor. ^[3] Ordinea sigură este să configurezi și să testezi noul mecanism înainte să oprești mecanismul vechi. Altfel, poți lăsa programările fără niciun declanșator.

Într-un site cu cache public, cererile vizitatorilor pot fi servite fără executarea WordPress pentru fiecare pagină. De aceea, observă traseul real al solicitărilor. Cache-ul Cloudflare și cronul au scopuri diferite; un HIT rapid pentru homepage nu dovedește că o sarcină programată a fost verificată.

Ce înseamnă o expresie cron

O expresie clasică cu cinci câmpuri descrie minutul, ora, ziua lunii, luna și ziua săptămânii. Panoul găzduirii poate oferi o interfață care construiește expresia. Nu confunda cronul sistemului cu alegerea orei unui articol în WordPress: unul pornește verificări, celălalt definește scadența unui obiect.

*/5 * * * *

Exemplul reprezintă o verificare la fiecare cinci minute într-un scheduler compatibil cu această sintaxă. Nu este o recomandare universală pentru orice server. Frecvența trebuie aleasă după câtă precizie ai nevoie și cât durează o rundă. Nu o seta mai mică decât poți procesa fără suprapuneri.

Un apel periodic poate publica o sarcină scadentă la următoarea rundă disponibilă, nu neapărat exact la secundă. Pentru termene comerciale stricte, include această toleranță în proiectare. O etichetă „programat la 08:00” nu trebuie prezentată ca o garanție de execuție la 08:00:00 pe orice găzduire.

Nu păstra declanșatoare concurente fără motiv

Două servicii externe, cronul cPanel și declanșarea la vizită pot crea solicitări redundante. Mecanismele de blocare reduc unele suprapuneri, dar nu justifică o configurație pe care nimeni nu o poate explica. Alege un declanșator principal, documentează recuperarea și păstrează o cale clară de diagnostic.

Dacă o rundă durează mai mult decât intervalul ales, investighează lucrarea. Poate fi nevoie de loturi mai mici, limite de timp sau reluare controlată, nu de apeluri tot mai dese. O coadă de o sută de operațiuni nu trebuie neapărat executată într-o singură cerere PHP.

Pentru integrări, cere jurnal cu sarcini preluate, finalizate, amânate și eșuate. Dezvoltarea unui plugin custom trebuie să separe aceste stări. „Worker pornit” și „totul finalizat” sunt afirmații diferite, iar interfața nu trebuie să le prezinte ca echivalente.

Interpretează răspunsul HTTP corect

Un endpoint de cron poate avea corp gol; acesta nu este automat un defect. În schimb, un răspuns 200 nu dovedește finalizarea tuturor sarcinilor. Verifică jurnalul aplicației și schimbarea stării obiectului, de exemplu trecerea articolului din viitor în publicat.

Un 403 indică refuzul cererii și merită comparat cu regulile de acces. Un 5xx indică o problemă de server sau de execuție care trebuie investigată. Pentru acces refuzat, folosește diagnosticul 403, fără să dezactivezi întregul firewall. O excepție trebuie limitată la mecanismul legitim și verificată.

Cronul nu trebuie servit ca pagină HTML publică memorată în CDN. Nu încerca să obții HIT pe endpointul tehnic. Cache-ul paginilor și execuția operațiilor sunt trasee diferite. Un răspuns vechi, memorat, poate arăta că solicitarea a reușit fără să pornească lucrarea dorită.

Testează o sarcină fără efecte comerciale

Creează pe un mediu controlat o ciornă de test și programeaz-o într-un interval apropiat. Notează ID-ul, ora locală și starea. După scadență, verifică declanșatorul, apoi articolul și jurnalul. Nu folosi o comandă reală sau o campanie de email către clienți drept prim test al cronului.

Pentru un site deja în producție, un articol demonstrativ nu trebuie publicat accidental în sitemap sau trimis în newsletter. Preferă staging cu acces protejat și fără servicii externe active. Dacă testul trebuie făcut live, definește în prealabil efectele și modul de retragere, împreună cu persoana responsabilă.

Nu rula „toate evenimentele scadente” fără să inspectezi lista. O asemenea comandă poate executa lucrări comerciale legitime, dar neașteptate în acel moment. Testarea trebuie să fie deliberată, nu o încercare de a vedea ce se întâmplă când forțezi întregul sistem.

Publicarea articolului și afișarea lui în Blog sunt două verificări

Articolul poate fi publicat în baza de date, dar arhiva publică să rămână o copie veche din cache. Verifică întâi starea din WordPress și URL-ul articolului. Apoi verifică hubul Blogului, categoria și paginarea relevantă. Nu atribui cronului o problemă de invalidare a arhivei.

Într-o integrare bună, schimbarea stării semnalează invalidarea paginilor dependente. Controlul cache-ului trebuie să lucreze cu publicarea, nu să o înlocuiască. Dacă articolul există, dar lista nu îl arată, jurnalul de cache devine mai relevant decât repetarea solicitărilor către cron.

Verifică și destinațiile linkurilor interne. Un ghid programat nu trebuie legat ca și cum ar fi deja public. După publicare, paginile care îl recomandă pot necesita reîmprospătare. Această dependență este o responsabilitate distinctă a integrării de linkuri interne.

Calendar automat: sloturi, limită zilnică și pauză

Un calendar automat ar trebui să verifice ce este deja programat înainte să atribuie un loc nou. Limita zilnică trebuie definită fără ambiguitate: trei articole în total sau trei pe categorie sunt reguli diferite. Interfața trebuie să arate data și ora finală, nu numai mesajul că articolul a fost adăugat.

Imaginează-ți un calendar cu locuri la 04:00, 08:00 și 23:00. Dacă primele două sunt ocupate, noua ciornă poate primi locul de la 23:00, conform regulilor. O programare manuală existentă nu ar trebui mutată în tăcere pentru a face loc unui import nou.

Pauza poate opri alocările viitoare fără să anuleze publicările deja înregistrate. Acest comportament trebuie descris explicit. Înainte de un import mare, decide dacă materialele intră imediat în calendar sau rămân pentru revizie. Butonul de pauză nu este un mecanism de retragere a tuturor sarcinilor salvate.

Recuperarea după o întrerupere

După revenirea serverului, inventariază evenimentele restante și lucrările parțial executate. Nu presupune că fiecare sarcină trebuie repetată integral. Pentru o operațiune cu efect extern, verifică dacă prima încercare a reușit înainte de a retrimite, chiar dacă răspunsul nu a ajuns înapoi la WordPress.

Acesta este motivul pentru care operațiunile au nevoie de identificatori și de protecție la repetare. Publicarea aceluiași articol nu trebuie să creeze un articol nou, iar o sincronizare nu trebuie să dubleze obiectul de destinație. Jurnalul trebuie să permită recunoașterea aceleiași lucrări între încercări.

Reia în loturi potrivite, urmărește timpul și oprește procesarea când apar erori repetate. Pentru probleme de execuție PHP, ghidul erorii 500 oferă un traseu separat. Un cron care continuă să pornească o lucrare defectă nu este o soluție de recuperare.

Fișa minimă pe care o trimiți la suport

Include URL-ul endpointului fără secrete, ora și zona, hookul sau ID-ul obiectului, codul HTTP și mesajul de eroare relevant. Adaugă ultima modificare cunoscută: actualizare plugin, schimbare hosting, activare firewall sau modificarea calendarului. Elimină tokenuri, parole și date ale clienților din capturi.

Atașează două observații separate: „declanșatorul a rulat” și „obiectul a fost finalizat” ori „a rămas în aceeași stare”. Acest lucru reduce timpul pierdut cu presupuneri. Mentenanța și suportul tehnic pot interveni mai precis când incidentul este descris ca un traseu, nu doar ca mesajul „programarea nu merge”.

Exemplu de diagnostic pe patru coloane

Construiește un tabel cu scadență, declanșare, execuție și rezultat. Pentru un articol ipotetic, scadența este 08:00, declanșarea apare la 08:02, callbackul se încheie la 08:02:04, iar starea devine publicat. Acesta este un caz de execuție după scadență, cu întârziere explicată de intervalul verificării, nu o programare lipsă.

În al doilea caz, declanșarea apare la timp, dar jurnalul arată eroare PHP, iar starea rămâne viitoare. Aici schimbarea frecvenței nu rezolvă callbackul. În al treilea caz, evenimentul nu există, deși interfața arată o dată. Investigația trebuie mutată la salvare și la eventualele erori returnate de WordPress. Aceeași etichetă vizuală poate ascunde mecanisme diferite.

În al patrulea caz, articolul este publicat, dar vizitatorul vede o arhivă veche. Compari URL-ul individual cu lista și verifici invalidarea. Repetarea publicării sau schimbarea datei articolului poate crea confuzie fără să repare HTML-ul din cache. Tabelul te ajută să atribui problema componentei potrivite înainte de a modifica programarea.

Păstrează și durata rundei, numărul sarcinilor și eventualele reîncercări. Un worker care procesează un lot limitat poate funcționa corect chiar dacă mai rămân elemente în coadă. Interfața trebuie să distingă progresul de eșec. Concluzia utilă este dacă următoarea rundă este programată și dacă sarcinile avansează, nu dacă toate dispar instantaneu din listă.

Verificări după schimbarea orei sezoniere

Pentru un calendar care exprimă ore locale, testează date dinaintea și de după schimbarea sezonieră a orei. Nu este nevoie să modifici ceasul serverului pentru aceasta; poți verifica transformarea datelor într-un mediu de test și valorile salvate. Slotul local de 08:00 trebuie interpretat prin zona configurată, nu printr-un offset păstrat într-o formulă veche.

Notează comportamentul pentru orele locale ambigue sau inexistente când proiectul permite asemenea alegeri manuale. Un selector robust trebuie să valideze data, nu să accepte în tăcere orice text. Pentru un calendar cu sloturi fixe, alege și documentează politica, astfel încât utilizatorul să vadă data efectivă, nu o promisiune pe care sistemul o convertește diferit.

Întrebări frecvente

Trebuie să țin administrarea deschisă?

Nu pentru o programare care folosește un declanșator funcțional independent. Un worker manual din browser poate avea alte reguli, dar nu trebuie confundat cu publicarea prin cron. Verifică documentația pluginului și mecanismul efectiv de pe găzduire.

Este suficient să cresc frecvența la un minut?

Nu. Dacă lipsește evenimentul, accesul este blocat sau callbackul eșuează, vei repeta aceeași problemă mai des. Frecvența se ajustează după ce ai confirmat traseul și durata unei runde.

DISABLE_WP_CRON șterge evenimentele?

Nu reprezintă o comandă de ștergere a calendarului; controlează declanșarea implicită. Totuși, modificarea ei fără un mecanism alternativ testat poate lăsa sarcinile neexecutate. Păstrează configurația și testul de revenire înainte de intervenție.

Surse și documentație

Exemplele și scenariile sunt editoriale și ipotetice, nu rezultate măsurate pentru clienți. Instrucțiunile trebuie adaptate configurației proiectului și verificate înainte de intervenții în producție.

1. WordPress: înțelegerea WP-Cron
2. WP-CLI: comenzi pentru evenimente cron
3. WordPress: conectarea cronului la un scheduler de sistem