Cum mărești dimensiunea maximă a fișierelor încărcate în WordPress

Trei setări controlează limita de încărcare din WordPress și toate trebuie să fie de acord. Limita efectivă este cea mai mică dintre upload_max_filesize, post_max_size și limita de cerere impusă de serverul web. Dacă mărești una singură și le lași pe celelalte două mici, nu se schimbă nimic — și exact de aceea majoritatea oamenilor ajung la concluzia că rezolvarea lor „nu a funcționat”. Verifică-ți mai întâi valorile actuale cu instrumentul pentru dimensiunea maximă de încărcare WordPress; acesta citește aceleași valori pe care le raportează WordPress și îți arată care dintre ele te ține pe loc.

De ce există limita și unde se află

WordPress nu setează limita de încărcare. Doar o raportează. Când vezi „The uploaded file exceeds the upload_max_filesize directive in php.ini”, acel mesaj vine direct din PHP.

Trei valori separate controlează o încărcare, iar plafonul real este oricare este cel mai mic:

• upload_max_filesize (PHP) — cel mai mare fișier individual pe care PHP îl acceptă.
• post_max_size (PHP) — cel mai mare corp POST total. Fișierul tău călătorește în interiorul cererii POST alături de alte câmpuri de formular, așa că această valoare trebuie să fie mai mare decât upload_max_filesize.
• Limita de corp a serverului web — client_max_body_size pe Nginx sau LimitRequestBody pe Apache. Aceasta se află complet în afara PHP, motiv pentru care rezolvările care țin doar de PHP eșuează în tăcere în spatele Nginx.

O a patra valoare, max_execution_time, nu limitează dimensiunea, dar va întrerupe o încărcare lentă și mare la jumătatea transferului pe o conexiune slabă. Este un simptom separat, nu parte din plafonul de dimensiune.

Capcana: setezi upload_max_filesize = 256M, reîncarci, tot nu poți încărca un fișier de 100 MB — pentru că post_max_size este încă 8M. PHP respinge cererea pe baza corpului total înainte să inspecteze vreodată fișierul. Limita nu te-a ignorat. O limită diferită l-a prins prima.

Cum să rezolvi problema, în ordine

Mergi de la cel mai probabil să funcționeze până la ultima soluție.

1. Editează php.ini (locul corect). Găsește fișierul pe care site-ul tău îl încarcă efectiv — rulează o pagină cu <?php phpinfo(); și citește „Loaded Configuration File”, sau întreabă-ți furnizorul de găzduire. Setează ambele valori PHP și păstrează post_max_size mai mare decât upload_max_filesize:

upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300

Repornește PHP-FPM (sudo systemctl restart php8.2-fpm) sau Apache. Modificările nu fac nimic până când procesul PHP nu repornește.

2. Nu ai acces la php.ini? Folosește .htaccess (doar Apache + mod_php). Adaugă în .htaccess din rădăcina WordPress:

php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300

Acest lucru funcționează doar când PHP rulează ca modul Apache. Sub PHP-FPM, CGI sau FastCGI, php_value aruncă o eroare 500 — acel eșec înseamnă că ești pe drumul greșit, nu că valoarea este greșită. Treci la .user.ini:

upload_max_filesize = 256M
post_max_size = 260M

3. Mărește limita serverului web — pasul pe care îl uită toată lumea. Pe Nginx, PHP nici măcar nu vede o cerere supradimensionată; Nginx returnează 413 Request Entity Too Large mai întâi. În blocul tău de server:

client_max_body_size 256M;

Reîncarcă cu sudo nginx -t && sudo systemctl reload nginx. Dacă ești pe Nginx și modificările tale în PHP „nu au făcut nimic”, aproape întotdeauna acesta este motivul.

După orice modificare, verifică din nou valorile raportate. Instrumentul pentru dimensiunea maximă de încărcare îți va spune noul plafon efectiv și va genera fragmentul exact pentru configurația ta, ca să nu mai ghicești care dintre cele trei este încă prea mică.

Ce să nu faci

Nu edita wp-config.php așteptându-te să ridice limita. Linia larg copiată nu face ceea ce pretind articolele de blog:

@ini_set( 'upload_max_filesize' , '256M' );

upload_max_filesize este PHP_INI_PERDIR. Nu poate fi modificată din PHP în timpul execuției cu ini_set(). Acceptă valori noi doar din php.ini, .htaccess sau .user.ini — niciodată din codul aplicației. Linia rulează fără eroare și nu face nimic, ceea ce o transformă într-una dintre cele mai încrezător repetate bucăți de sfat greșit din WordPress.

Nu lipi nici @ini_set('post_max_size', ...) — aceeași restricție, aceeași lipsă de efect în tăcere.

Nu seta WP_MEMORY_LIMIT crezând că este limita de încărcare. Aceasta controlează plafonul de memorie al PHP pentru rularea codului. Nu are nicio legătură cu cât de mare este fișierul pe care serverul îl acceptă.

Nu te opri la un singur fișier. Cel mai frecvent eșec este modificarea doar a upload_max_filesize și declararea rezolvării ca fiind defectă. Modifică-le pe toate trei și păstrează post_max_size peste upload_max_filesize.

Nu seta limite absurd de mari „ca să fie sigur”. O limită de 2 GB invită probleme de epuizare a resurselor și nu ajută — dacă ai cu adevărat nevoie de fișiere de mai mulți gigabytes, încarcă-le în afara browserului (SFTP sau un plugin de încărcare fragmentată), în loc să le forțezi printr-un singur POST PHP.

Tot blocat?

Dacă toate cele trei valori sunt mărite și tot dai de un zid, cererea este limitată undeva mai sus de serverul tău: un CDN sau un proxy (panoul de control Cloudflare limitează dimensiunea corpului de încărcare pe cont propriu), o limită de platformă a unui furnizor de găzduire administrat care îți ignoră php.ini, sau un .user.ini care nu s-a reîmprospătat încă — respectă valoarea user_ini.cache_ttl din PHP, deci poate întârzia câteva minute după ce salvezi. Confirmă ce raportează serverul cu adevărat, nu ce ai scris într-un fișier, și repară stratul care este încă prea mic. Când numărul raportat se potrivește în sfârșit cu ținta ta, încărcarea funcționează.