Coșmarul care este wp-cron.php

O mare nemulțumire pe care o am cu WordPress este implementarea implicită a wp-cron.php. Dacă sunteți familiarizat cu modul în care WordPress utilizează wp-cron.php în mod implicit, este posibil să doriți să treceți la următoarea secțiune a acestui articol.

Fileul wp-cron.php este partea din WordPress care gestionează evenimentele programate în cadrul unui site WordPress. Tot ceea ce are de-a face cu programarea postărilor sau a publicațiilor și, de fapt, tot ceea ce este orientat către data/ora este guvernat de fișierul wp-cron.php.

Pentru ca wp-cron.php să funcționeze corect, trebuie să fie executat frecvent, dar nu mai mult de o dată pe minut. Cu toate acestea, comportamentul implicit nu vă obligă să configurați o adevărată sarcină cron la nivel de sistem pe serverul dumneavoastră. În schimb, folosește o metodă piggyback la fiecare solicitare primită. Atunci când o cerere intră pe site, WordPress va genera o cerere suplimentară de la el însuși către fișierul wp-cron.php prin HTTP(S). Sună destul de inofensiv, nu-i așa?

De ce este comportamentul implicit al wp-cron.php un coșmar?

Metoda implicită funcționează perfect bine pe un site mic cu foarte puțini vizitatori pe oră. Cu toate acestea, atunci când este implementată pe un site mediu sau mai mare sau chiar pe un site care este scanat de roboți (ceea ce este foarte comun în zilele noastre), acest lucru înseamnă că veți primi de două ori mai mult decât orice trafic pe care îl gestionați în prezent. Devine un atac DDoS rudimentar împotriva ta. Acest lucru se datorează faptului că cronul este executat de mai multe ori pe minut folosind o cerere HTTP. Cererea HTTP generează costuri suplimentare prin faptul că trebuie să genereze, să negocieze și să stabilească conexiunea prin intermediul unui socket de rețea. Aceasta are chiar un impact asupra capacității efective a serverului dvs. web de bază. Această soluție nu se descurcă bine în majoritatea situațiilor și, sincer, ar trebui să fie eliminată ca și comportament implicit din cauza predispoziției sale de a fi abuzată sau transformată într-un vector de atac asupra unui server doar din traficul obișnuit.

Ei bine, care sunt alternativele?

Singura alternativă reală și soluția mult mai bună este configurarea unui cronjob de sistem obișnuit care execută scriptul wp-cron.php direct prin PHP în fiecare minut. Acest lucru asigură că orice sarcini programate sunt într-adevăr executate la ora programată. De asemenea, nu ar trebui să se facă prin intermediul unei cereri HTTP, ci printr-o execuție directă a PHP pentru a evita împiedicarea capacității serverului web sau generarea de memorie suplimentară pe stratul de rețea.

Cum dezactivez comportamentul implicit al wp-cron.php?

Acest lucru este destul de universal și simplu de făcut. Trebuie să vă actualizați fișierul wp-cronfig.php pentru a include următoarea setare:

define('DISABLE_WP_CRON', true);

• De obicei, puteți găsi fișierul wp-config.php în directorul public_html al site-ului dvs.
• Această nouă setare ar trebui pusă în fișier imediat după linia DB_COLLATE a bazei de date, care arată după cum urmează

define('DB_COLLATE', '');

Cum configurez un cron job de sistem?

Acest lucru este simplu în cPanel, presupunând că furnizorul dvs. de găzduire a activat funcția cron job pe contul dvs. Documentația cPanel Cron Jobs intră în mai multe detalii, dar în esență faceți:

1. Intrați în cPanel pentru domeniul dumneavoastră: yourdomain.tld/cpanel
2. Introduceți „cron” în caseta de căutare rapidă din partea de sus a paginii.
3. Click pe pictograma „Cron Jobs” care apare.

• Dacă nu apare, contul dvs. nu are activată funcția Cron Jobs și va trebui să vorbiți cu furnizorul dvs. de găzduire pentru a vă ajuta să configurați cronul sau să treceți la un pachet care include funcția Cron Jobs.

1. Să acordați atenție paginii Cron Jobs, vă va oferi locația exactă a binarului PHP. Va trebui să copiați acea cale în caseta de comandă din partea de jos a paginii și să modificați fișierul executat de PHP pentru a fi în schimb fișierul dvs. /home/nume utilizator/public_html/wp-cron.php. Folosind calea completă.
2. Selectați prima intrare („*”) pentru fiecare parametru. Acest lucru va executa fișierul wp-cron.php la fiecare minut.
3. Click pe acel buton de adăugare a cronului și ați terminat.

De ce sunteți atât de dur cu această practică, pare rezonabilă și ușor de rezolvat?

Cred că este de datoria inginerilor de software care dezvoltă lumea noastră digitală să își imprime un simț al responsabilității pentru produsele lor. WordPress este omniprezent în zilele noastre și, cu ajutorul unui software de instalare automată, cum ar fi Softaculous, WordPress este instalat pe o majoritate foarte mare de site-uri. Acestea sunt instalate cu comportamentul implicit activat, ceea ce reprezintă, în esență, un vector de atac pe orice server. Acum, având în vedere că industria de găzduire este atât de răspândită în viața noastră, mulți oameni au site-uri WordPress și nu știu despre această problemă până când aceasta le paralizează site-ul. Integrarea implicită este extrem de inadecvată și ar trebui să fie eliminată. Astăzi, pe un singur server, am găsit peste 500 de instalări diferite de WordPress și am văzut cum un robot a lovit fiecare site de pe server. Fiecare dintre aceste site-uri a devenit brusc o responsabilitate pentru stabilitatea serverului.

Îmi dau seama că această problemă este tratată de la caz la caz. Cu toate acestea, cu atât de multe instalări în întreaga lume, ar fi mai bine să fie abordată de WordPress decât de fiecare furnizor de găzduire în parte, care trebuie să stabilească condiții speciale pe serverul lor pentru a se proteja împotriva găurii pe care acest software o generează. Costul eliminării acestui comportament și al forțării proprietarilor de site-uri să genereze un cron de sistem ar trebui să fie de bază și o notificare plasată în interfața de administrare a WordPress că sarcinile programate nu vor fi executate până când un job cron de sistem nu este creat în mod corespunzător. Acest lucru ține de abilitățile mele de programare, așa că știu că ține de abilitățile lor.

WordPress urmărește ușurința de utilizare, astfel încât consumatorii lor țintă sunt cei care, de obicei, știu foarte puțin despre avertismentele legate de găzduire. Cred că responsabilitatea în acest caz revine în întregime WordPress pentru a remedia și ei au luat atitudine împotriva acestui lucru. Între timp, administratorii de sistem din industria de găzduire trebuie să sufere din cauza acestei „caracteristici” teribile atunci când examinează serverele care au scăpat de sub control din cauza unui robot care rulează peste o instalare implicită a WordPress.

.