Ar trebui să dezactivez WP_CRON și să declanșez wp-cron.php de pe server?

Nu există dezavantaje în a rula WP CRON folosind job-urile cron ale serverului. De fapt, aceasta este practica recomandată.

Conform Documentației Oficiale pentru Dezvoltarea de Plugin-uri WordPress:

WP-Cron nu rulează continuu, ceea ce poate fi o problemă dacă există sarcini critice care trebuie executate la timp. Există o soluție simplă pentru aceasta. Configurați pur și simplu programatorul de sarcini al sistemului dumneavoastră să ruleze la intervalele dorite (sau la ora specifică necesară).

Pentru a face acest lucru, trebuie mai întâi să dezactivați comportamentul implicit al cron în wp-config.php:

define('DISABLE_WP_CRON', true);

Apoi, programați wp-cron.php de pe serverul dumneavoastră. Pentru Linux, asta înseamnă:

crontab -e

Totuși, în loc să-l rulați în linia de comandă (CLI), rulați-l ca o cerere HTTP. Pentru asta puteți folosi wget:

*/5 * * * * wget -q -O - https://domeniul-dvs.ro/wp-cron.php?doing_wp_cron

WordPress încarcă toate fișierele de bază necesare, Plugin-uri etc. în wp-cron.php cu următorul COD:

if ( !defined('ABSPATH') ) {
    /** Set up WordPress environment */
    require_once( dirname( __FILE__ ) . '/wp-load.php' );
}

Așadar, nu vă faceți griji că WordPress nu încarcă funcționalități importante.

Există câteva dezavantaje: În primul rând, atunci când utilizați wp-cron.php ca CLI, variabile precum $_SERVER nu sunt setate. Oamenii depășesc această limitare prin utilizarea unei cereri curl către wp-cron.php în schimb.

În al doilea rând, deoarece WP în sine nu este încărcat cu wp-cron.php; dacă utilizați un plugin SMTP mailer, acesta nu va fi încărcat când apelați wp-cron. Din nou, utilizarea unui apel curl depășește această problemă. Curl pare a fi metoda cea mai frecvent utilizată.

Totuși, eu prefer să folosesc wp-cli după setarea corectă a configurărilor de mail în postfix și (pentru nginx) php-fpm și setarea unui crontab precum:

*/5    *   *   *   *  wp cron event list --skip-plugins --skip-teme --path="/var/www/vhosts/example.com/httpdocs/wp" --fields=hook,next_run_relative --format=csv | awk -F, '$2=="now" {print $1}' | xargs -r wp --path="/var/www/vhosts/example.com/httpdocs/wp" cron event run $1

(Listează toate cron-urile cu câmpuri specifice în format csv - hook fiind numele cron-ului, next_run_relative fiind timpul. Elimină cele care afișează 'now' ca următoare execuție (cele care sunt datorate acum) folosind AWK, transmite acea listă către xargs pentru a apela wp cron event run $HOOK pentru fiecare cron.) Folosirea wp-cli încarcă WordPress corect (eu aleg să sar peste plugin-uri atunci când listez cron-urile, deoarece erorile de cod și avertismentele php vor strica ieșirea scriptată; dar nu să le sar când rulez cron-ul cu xargs, deoarece cron-ul poate avea nevoie de plugin-uri încărcate)

Sper că acest lucru vă oferă câteva indicii despre ce să aveți în vedere.

Încă nu am găsit un dezavantaj real în a externaliza wp-cron către un serviciu extern. Fac asta de mulți ani deja.

Mai ales în lumea de astăzi, unde poți rula aplicații ca microservicii.

Eu folosesc containere Docker separate pentru fiecare componentă WordPress - php, web, db, crontab, redis și așa mai departe). Am crontab într-un container separat, apelând wp-cron prin http folosind rețeaua locală, rulând doar atunci când am nevoie.

Aceasta reduce stresul pe nodurile de backend și îmbunătățește securitatea prin reducerea suprafeței de atac.

Dacă un developer nu poate să-și dea seama cum să facă lucrurile fără să apeleze wp-cron la fiecare încărcare de pagină, asta doar arată lipsa de experiență din partea lui. "A-l lăsa așa", pentru că nu înțelegi cum funcționează lucrurile, nu este un motiv bun pentru a-l păstra.

Există multe motive pentru a nu dezactiva wp-cron. De fapt, este aproape imposibil să găsești un caz de utilizare în care să fie necesar acest lucru. Nu încetinește site-ul tău și este folosit pentru lucruri de care poate nu ești conștient.

Multe plugin-uri folosesc WP-Cron pentru a programa anumite acțiuni. Acestea pot deveni confuze dacă oprești scheduler-ul.

Există o mulțime de tutoriale pe această temă pentru că este confuză și pentru că dezactivarea lui nu are un impact major asupra site-ului. Ceea ce va face, însă, este să creeze o durere de cap developer-ului care va trebui să rezolve problema misterioasă pe care o va genera în șase luni.

De asemenea, WP Heartbeat rulează la fiecare 15 secunde în zona de administrare, rezolvând această problemă pentru 99% dintre oamenii care cred că o au.