Cum să remediați eroarea max_execution_time în WordPress

Eroarea max_execution_time în WordPress apare atunci când un script PHP depășește durata maximă de execuție configurată la nivelul serverului. PHP termină scriptul și returnează o eroare fatală, pe care WordPress o afișează ca un ecran alb, o notificare de timeout sau un mesaj explicit „Maximum execution time exceeded”.

În mod implicit, majoritatea mediilor de hosting partajat impun o limită de 30 de secunde. Operațiuni precum importul unui CSV de produse WooCommerce, realizarea unui backup complet al site-ului sau instalarea unui pachet mare de plugin-uri pot depăși cu ușurință această limită. Creșterea limitei — prin php.ini, .htaccess, wp-config.php sau prin stratul de plugin-uri WordPress — rezolvă eroarea fără a compromite stabilitatea serverului, dacă este realizată corect.

Înțelegerea motivului pentru care există limita și când devine o problemă

Directiva max_execution_time din PHP este un mecanism de protecție a resurselor, nu o restricție arbitrară. Previne ca un script scăpat de sub control să monopolizeze timpul CPU pe un pool de procese partajate, ceea ce este deosebit de critic pe infrastructura multi-tenant.

Limita devine un obstacol real în aceste scenarii:

• Importuri sau exporturi mari de baze de date prin phpMyAdmin sau WP-CLI care procesează mii de rânduri
• Instalări de plugin-uri sau teme care dezarhivează fișiere ce depășesc 50 MB
• Operațiuni bulk WooCommerce — actualizări de prețuri, sincronizări de inventar, exporturi de comenzi
• Migrări complete ale site-ului folosind instrumente precum Duplicator sau All-in-One WP Migration
• Sarcini cron programate care agregă date din API-uri externe
• Plugin-uri de optimizare a imaginilor care procesează sute de fișiere neoptimizate într-un singur lot

O nuanță critică pe care majoritatea ghidurilor o omit: max_execution_time măsoară timpul CPU consumat de procesul PHP, nu timpul real de ceas. Pe un server cu încărcare mare, un script poate rula 90 de secunde în timp real, consumând doar 28 de secunde de timp CPU, fără a declanșa limita. În schimb, o buclă intensivă CPU atinge limita mai repede decât era de așteptat. Această distincție contează atunci când diagnosticați timeout-uri intermitente.

Cum să verificați valoarea curentă a max_execution_time

Înainte de a schimba orice, confirmați limita activă. Creați un fișier temporar în directorul rădăcină WordPress — nu îl lăsați niciodată accesibil public după testare:

<?php
phpinfo();

Încărcați-l ca phpinfo-test.php, accesați https://yourdomain.com/phpinfo-test.php și căutați max_execution_time în rezultat. Ștergeți fișierul imediat după verificare.

Alternativ, folosiți WP-CLI din SSH:

wp eval 'echo ini_get("max_execution_time");'

Aceasta returnează valoarea activă în prezent pentru cererile WordPress, care poate diferi de php.ini global al serverului dacă există deja o suprascriere per-director.

Metoda 1: Editarea fișierului php.ini (Cea mai fiabilă)

Modificarea php.ini este cea mai autoritară metodă deoarece setează directiva la nivelul interpretorului PHP, fără a suprascrie nimic și fără a fi suprascrisă de nimic inferior în ierarhia de configurare — cu excepția cazului în care un apel ulterior ini_set() o înlocuiește la runtime.

Pasul 1: Localizați fișierul php.ini corect

Acesta este locul unde majoritatea administratorilor fac o greșeală. PHP poate încărca mai multe fișiere .ini în funcție de SAPI (Server API) utilizat:

• CLI SAPI (/etc/php/8.x/cli/php.ini) — utilizat de WP-CLI și sarcini cron
• FPM SAPI (/etc/php/8.x/fpm/php.ini) — utilizat de stivele Nginx + PHP-FPM
• Apache mod_php (/etc/php/8.x/apache2/php.ini) — utilizat de Apache cu modulul PHP

Editarea php.ini CLI va rezolva timeout-urile WP-CLI, dar nu va afecta cererile declanșate din browser. Identificați întotdeauna mai întâi SAPI-ul corect:

php -i | grep "Loaded Configuration File"

Pentru cererile web, verificați rezultatul phpinfo() sub Loaded Configuration File.

Pasul 2: Editați sau creați php.ini în directorul rădăcină web

Pe hosting partajat unde nu aveți acces root, puteți plasa un php.ini la nivel de utilizator în directorul rădăcină al site-ului (public_html). Accesați-l prin cPanel File Manager, FTP sau SSH:

nano ~/public_html/php.ini

Adăugați sau actualizați directiva:

max_execution_time = 300

300 de secunde (5 minute) sunt suficiente pentru majoritatea operațiunilor. Pentru migrări extrem de mari, luați în considerare temporar 600 de secunde, apoi reveniți la valoarea inițială după finalizarea sarcinii.

Pasul 3: Verificați că modificarea a intrat în vigoare

După salvare, rulați din nou verificarea phpinfo() sau comanda WP-CLI de mai devreme. Dacă valoarea nu s-a schimbat, gazda dvs. poate impune o limită maximă prin max_execution_time într-un php.ini la nivel de server care suprascrie fișierul dvs. la nivel de utilizator. În acest caz, treceți la Metoda 4.

Pasul 4: Reporniți PHP-FPM (VPS și servere dedicate)

Pe un VPS sau server dedicat unde controlați mediul, este necesară o repornire PHP-FPM pentru ca modificarea să se propage la cererile web:

sudo systemctl restart php8.2-fpm

Înlocuiți php8.2-fpm cu versiunea PHP instalată. Apache cu mod_php necesită în schimb o reîncărcare Apache:

sudo systemctl reload apache2

Metoda 2: Editarea fișierului .htaccess (Doar Apache)

Metoda .htaccess funcționează exclusiv pe serverele Apache unde AllowOverride permite directive de configurare PHP. Nu funcționează pe Nginx, LiteSpeed cu anumite configurații sau orice stivă unde PHP rulează ca FastCGI/FPM cu AllowOverride None.

Pasul 1: Afișați și accesați fișierul .htaccess

Fișierul .htaccess este ascuns în mod implicit. În cPanel File Manager, faceți clic pe Settings în colțul din dreapta sus și activați Show Hidden Files (dotfiles). Fișierul se află în public_html.

Prin SSH:

nano ~/public_html/.htaccess

Pasul 2: Adăugați directiva PHP

Inserați următoarea linie. Poziția contează — plasați-o în afara oricărui bloc <IfModule> pentru a vă asigura că se aplică global:

php_value max_execution_time 300

Dacă serverul dvs. rulează PHP-FPM (identificabil prin PHP/x.x.x (fpm-fcgi) în phpinfo()), această directivă va cauza o Eroare Internă de Server 500 deoarece php_value nu este valid în acel context. Folosiți php_admin_value doar dacă gazda permite explicit acest lucru, sau treceți la Metoda 1.

Pasul 3: Testați pentru erori 500

După salvare, încărcați imediat pagina de start. O eroare 500 înseamnă că directiva este incompatibilă cu configurația serverului dvs. Eliminați linia și folosiți o metodă alternativă.

Metoda 3: Editarea wp-config.php folosind set_time_limit()

Funcția set_time_limit() resetează cronometrul de execuție din punctul în care este apelată. Acesta este un apel PHP la runtime, nu o directivă de configurare, ceea ce înseamnă că funcționează indiferent dacă serverul permite suprascrieri php.ini sau .htaccess — atâta timp cât lista disable_functions a PHP nu o include.

Pasul 1: Localizați wp-config.php

Fișierul se află în directorul rădăcină al instalării WordPress, cu un nivel deasupra public_html în unele configurații de server, sau direct în interiorul acestuia în altele.

find ~/public_html -maxdepth 2 -name "wp-config.php"

Pasul 2: Adăugați directiva

Deschideți wp-config.php și adăugați următoarea linie înainte de comentariul /* That's all, stop editing! Happy publishing. */:

set_time_limit(300);

Apelarea set_time_limit(0) dezactivează complet limita pentru acea cerere. Folosiți aceasta doar ca măsură temporară de diagnosticare — niciodată în producție — deoarece elimină rețeaua de siguranță împotriva buclelor infinite.

Avertisment important: set_time_limit() afectează doar execuția scriptului curent. Nu modifică configurația PHP la nivel de server. Dacă un plugin generează intern un subproces sau face o cerere HTTP blocantă, acel subproces nu este acoperit de acest apel.

Metoda 4: Utilizarea unui plugin WordPress

Pentru utilizatorii care preferă să nu editeze direct fișierele serverului, mai multe plugin-uri expun valorile de configurare PHP prin interfața de administrare WordPress. Această abordare este potrivită pentru proprietarii de site-uri non-tehnici pe hosting administrat.

Opțiuni recomandate:

• WP Maximum Execution Time Exceeded — vizează specific această eroare și încearcă mai multe metode de suprascriere
• PHP Settings — oferă o vizualizare în tabloul de bord a directivelor PHP active și permite suprascrieri sigure acolo unde gazda permite

Pentru instalare: navigați la Plugins > Add New în tabloul de bord WordPress, căutați numele plugin-ului, instalați și activați. Urmați pagina de setări a plugin-ului pentru a seta timpul de execuție dorit.

Limitare: Plugin-urile pot apela doar set_time_limit() sau ini_set() la runtime. Dacă gazda a blocat max_execution_time prin restricții open_basedir sau o configurație de server codificată, plugin-ul va eșua silențios în creșterea limitei. Verificați întotdeauna modificarea folosind phpinfo() după activare.

Metoda 5: Contactați furnizorul de hosting

Dacă niciuna dintre metodele de mai sus nu produce o modificare verificată în rezultatul phpinfo(), limita este impusă la nivel de server de către gazda dvs. Acest lucru este frecvent pe planurile de hosting partajat de nivel de intrare, unde furnizorul setează o limită maximă pentru a proteja resursele partajate.

Când contactați suportul, furnizați:

• Mesajul exact de eroare și acțiunea WordPress care îl declanșează
• Valoarea curentă max_execution_time din phpinfo()
• Valoarea de care aveți nevoie (ex.: 300 de secunde) și motivul (ex.: import mare WooCommerce)

Gazdele de renume vor ajusta fie limita pentru contul dvs., fie vă vor indica o opțiune din panoul de control (cum ar fi un selector PHP în cPanel) unde o puteți configura singur.

Compararea tuturor celor cinci metode

Diagnosticarea timeout-urilor persistente după creșterea limitei

Dacă ați confirmat că noua limită este activă în phpinfo() dar eroarea persistă, blocajul probabil nu este max_execution_time. Luați în considerare aceste cauze alternative:

Directive de timeout FastCGI sau Nginx — Nginx are propria directivă fastcgi_read_timeout, separată de PHP:

fastcgi_read_timeout 300;

Aceasta trebuie setată în blocul de server Nginx și necesită o reîncărcare Nginx.

Directiva Apache TimeOut — Propriul timeout de conexiune al Apache poate termina o cerere înainte ca limita PHP să fie atinsă:

TimeOut 300

PHP-FPM request_terminate_timeout — În configurația pool-ului PHP-FPM (/etc/php/8.x/fpm/pool.d/www.conf), această directivă omoară independent procesele worker:

request_terminate_timeout = 300

MySQL wait_timeout și interactive_timeout — Interogările de baze de date cu durată lungă pot cauza căderea conexiunii MySQL în mijlocul execuției, pe care PHP o afișează ca o eroare de script, nu ca o eroare de bază de date. Verificați cu:

SHOW VARIABLES LIKE '%timeout%';

Timeout-uri la nivel de WooCommerce sau plugin — Unele plugin-uri implementează propria logică internă de timeout folosind set_time_limit() al PHP cu o valoare mai mică, care resetează contorul și poate suprascrie configurația dvs.

Considerații de performanță și bune practici

Creșterea max_execution_time este o soluție țintită, nu o soluție arhitecturală permanentă. Dacă o operațiune specifică depășește în mod regulat 30–60 de secunde, procesul de bază ar trebui optimizat sau restructurat:

• Procesare în loturi: Împărțiți importurile mari în bucăți mai mici folosind fragmentare bazată pe AJAX (așa cum face WP All Import nativ) în loc să procesați totul într-o singură cerere HTTP
• Procesare în fundal: Folosiți WP-Cron sau o coadă de sarcini adecvată (Action Scheduler, utilizat de WooCommerce) pentru a muta munca de lungă durată în afara ciclului de viață al cererii web
• WP-CLI pentru operațiuni bulk: Execuția CLI nu este supusă timeout-urilor serverului web și este instrumentul corect pentru importuri de baze de date, operațiuni de căutare-înlocuire și procesare bulk a media
• Optimizați interogările lente: Folosiți plugin-ul Query Monitor pentru a identifica interogările de baze de date care consumă timp de execuție disproporționat
• Actualizați nivelul de hosting: Dacă volumul de lucru necesită în mod constant timpi de execuție extinși, un VPS cu cPanel vă oferă control complet asupra configurației PHP și resurse dedicate care nu concurează cu alți chiriași

Pentru volume de lucru cu calcul intensiv, cum ar fi recomandările de produse bazate pe AI sau pipeline-urile de procesare a imaginilor la scară largă, hosting-ul GPU descarcă complet calculul intensiv din stratul PHP.

Listă de verificare practică pentru decizii

Folosiți această listă de verificare înainte și după aplicarea oricărei remedieri:

• Confirmați valoarea curentă max_execution_time prin phpinfo() sau WP-CLI înainte de a face modificări
• Identificați stiva serverului dvs. (Apache + mod_php, Apache + FPM, Nginx + FPM) înainte de a alege o metodă
• Aplicați o singură metodă la un moment dat — stivuirea modificărilor php.ini, .htaccess și wp-config.php simultan face depanarea imposibilă
• După aplicarea unei modificări, reverificați valoarea activă în phpinfo() — nu presupuneți că modificarea a funcționat
• Testați reproducând acțiunea originală care a eșuat, nu doar încărcând pagina de start
• Dacă eroarea este rezolvată, luați în considerare dacă operațiunea de bază poate fi optimizată pentru a rula în limita originală
• Setați un memento în calendar pentru a reveni la orice creșteri temporare ale limitei (ex.: set_time_limit(0)) după finalizarea sarcinii unice
• Pe hosting partajat, documentați ce a confirmat gazda ca valoare maximă permisă pentru planul dvs.
• Dacă timeout-urile persistă după confirmarea că limita PHP este ridicată, auditați independent Nginx fastcgi_read_timeout, Apache TimeOut și PHP-FPM request_terminate_timeout

Întrebări frecvente

Care este cea mai sigură valoare de setat pentru max_execution_time în WordPress?

300 de secunde (5 minute) acoperă marea majoritate a operațiunilor WordPress intensive în resurse, inclusiv instalările mari de plugin-uri, importurile WooCommerce și actualizările de teme. Valorile de peste 600 de secunde ar trebui tratate ca temporare și revertite după finalizarea sarcinii specifice.

De ce modificarea max_execution_time nu apare în phpinfo() după editarea php.ini?

Cel mai probabil editați fișierul php.ini greșit. PHP încarcă fișiere de configurare diferite pentru CLI, Apache mod_php și PHP-FPM. Rulați php -i | grep "Loaded Configuration File" pentru CLI și verificați rândul Loaded Configuration File într-o pagină phpinfo() accesibilă din browser pentru a identifica fișierul corect pentru cererile web.

Creșterea max_execution_time afectează toți utilizatorii de pe serverul meu?

Pe un server partajat, editarea unui php.ini la nivel de utilizator în directorul rădăcină web afectează doar contul dvs. Editarea php.ini global al serverului (care necesită acces root) afectează toate procesele PHP de pe acel server. Pe un server dedicat, controlați configurația globală și purtați responsabilitatea deplină pentru impactul acesteia.

Va funcționa metoda .htaccess pe un server Nginx?

Nu. Fișierul .htaccess este un mecanism specific Apache. Nginx nu procesează fișierele .htaccess. Pe stivele Nginx + PHP-FPM, trebuie să editați configurația pool-ului PHP-FPM sau php.ini la nivel de server, ambele necesitând acces SSH.

Poate un plugin WordPress să crească permanent max_execution_time?

Nu. Plugin-urile se execută în runtime-ul PHP și pot apela doar set_time_limit() sau ini_set(), care afectează doar cererea curentă. Nu pot scrie în php.ini sau persista modificările de configurare între cereri. Pentru o creștere permanentă, trebuie să modificați php.ini, .htaccess sau un fișier de configurare a pool-ului PHP-FPM la nivel de server.