WordPress „HTTP error” la încărcarea imaginilor: un arbore de decizie care chiar găsește cauza

„HTTP error” nu este o cauză. Este uploaderul de fișiere media care recunoaște că a trimis fișierul către server și a primit înapoi un răspuns pe care nu l-a putut interpreta ca succes — iar cel puțin șase defecțiuni fără legătură între ele produc exact același mesaj. Faptul că oamenii ghicesc între ele este motivul pentru care își petrec o după-amiază crescând upload_max_filesize pe un sit a cărui problemă reală este o regulă de firewall.

Cel mai rapid drum de ieșire este o singură observație care împarte cele șase cauze în două grupe, apoi câte o verificare pe fiecare ramură.

Mai întâi: citește răspunsul real

Deschide uneltele pentru dezvoltatori din browser, mergi la fila Network și încarcă din nou fișierul. Urmărește cererea către async-upload.php. Ce vine înapoi este diagnosticul tău.

Ce vezi	Ce înseamnă	Mergi la
403 sau 406, corp HTML	Firewallul sau mod_security a respins cererea	Ramura A
500, răspuns gol sau corp trunchiat	PHP a crăpat sau a rămas fără memorie la jumătatea procesului	Ramura B
413	Corpul cererii a depășit o limită a serverului	Ramura C
200, dar corpul nu este JSON curat	Un modul sau o temă a tipărit ceva înaintea răspunsului	Ramura D
Cererea nu se termină niciodată / expiră	Limita de timp de execuție, de obicei la fișiere mari	Ramura B

Această singură privire elimină pentru tine mare parte din sfaturile care circulă pe internet. Dacă nu ajungi la uneltele din browser, pornește mai întâi jurnalizarea în wp-config.php:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Reproduce încărcarea, apoi citește wp-content/debug.log. O linie cu eroare fatală numește ramura direct. Dacă linia este greu de descifrat, lipește-o în decodorul de jurnal de erori — el pune în corespondență semnăturile fatale obișnuite cu ce s-a stricat de fapt.

Ramura A — o regulă de firewall sau mod_security

Un 403 cu o pagină HTML în corp înseamnă că cererea nu a ajuns niciodată la WordPress. Ceva aflat în față — mod_security, Cloudflare, Wordfence, Sucuri sau setul propriu de reguli al găzduirii — a considerat că cererea POST arată suspect.

Verificarea: dezactivează temporar orice modul de securitate și încarcă din nou. Dacă asta nu schimbă nimic, regula este la nivel de server și ai nevoie ca găzduirea să se uite în jurnalul de audit mod_security pentru momentul încărcării eșuate. Ei pot pune pe lista albă exact acel ID de regulă.

Fii sincer cu tine în privința sfaturilor pe care le vei găsi aici. Fragmentele care îți spun să pui asta în .htaccess:

SecFilterEngine Off
SecFilterScanPOST Off

vizează mod_security 1.x, care e aproape dispărut. Pe un server modern, acele directive fie nu fac nimic, fie provoacă un 500 care înrăutățește situația. Versiunile moderne de mod_security folosesc SecRuleEngine, iar majoritatea găzduirilor administrate blochează oricum suprascrierea lui per dosar. Întreabă găzduirea; nu lipi cod la întâmplare.

Ramura B — limite de memorie sau de execuție PHP

Este ramura cea mai frecventă și cea cu semnul cel mai clar: este intermitentă. Același fișier se încarcă la a treia încercare, sau o poză de 2MB eșuează în timp ce un PDF de 6MB trece fără probleme. Limitele fixe de configurare eșuează identic de fiecare dată. Cele de memorie nu, pentru că disponibilul depinde de ce mai face serverul în acel moment.

De ce tocmai imaginile: WordPress nu doar stochează fișierul, ci îl decomprimă în pixeli bruți ca să genereze fiecare dimensiune intermediară — medium_large, orice dimensiune înregistrată cu add_image_size, woocommerce_thumbnail dacă ai un magazin, plus o copie -scaled dacă imaginea depășește big_image_size_threshold. Un JPEG de 12 megapixeli ocupă câțiva MB pe disc și aproximativ 48MB în memorie, înainte de zona tampon pentru redimensionare. O limită de 128MB dispare rapid.

Crește-o în wp-config.php, deasupra liniei „stop editing”:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Costul real: WP_MEMORY_LIMIT nu poate depăși ce permite PHP în sine. Dacă găzduirea plafonează memory_limit la 128M, această constantă este pur decorativă. Verifică valoarea adevărată în Unelte → Sănătate sit → Info → Server, nu în ce ai scris tu. Dacă plafonul este chiar limita PHP, doar găzduirea o poate ridica.

Ramura C — limite de mărime a fișierului și a cererii

Verifică cifrele reale în Unelte → Sănătate sit → Info → Gestionare media. Contează două setări, iar oamenii o schimbă mereu doar pe una:

• upload_max_filesize — plafonul pentru un singur fișier.
• post_max_size — plafonul pentru întregul corp al cererii.

Dacă întregul POST depășește post_max_size, PHP aruncă cererea înainte ca WordPress să execute vreo linie de cod. Nu există nimic de returnat, așa că uploaderul primește un răspuns neinterpretabil și spune „HTTP error”. post_max_size ar trebui să fie mereu confortabil mai mare decât upload_max_filesize.

O nuanță care merită știută: când un fișier depășește doar upload_max_filesize, uploaderul îl prinde de obicei încă din browser și spune că fișierul depășește mărimea maximă de încărcare — un mesaj mai clar. Așa că un simplu „HTTP error” indică mai des post_max_size sau Ramura B decât setarea pe care toată lumea o crește prima.

Unde le schimbi depinde de stiva ta. Pe Apache cu mod_php, .htaccess funcționează:

php_value upload_max_filesize 64M
php_value post_max_size 128M

Pe PHP-FPM, LiteSpeed sau NGINX — adică pe majoritatea găzduirilor moderne — liniile acelea nu fac nimic și pot provoca un 500. Folosește în schimb panoul de setări PHP al găzduirii sau un fișier .user.ini. NGINX impune și propriul client_max_body_size, pe care doar găzduirea îl poate ridica.

Ramura D — biblioteca de editare a imaginilor (Imagick sau GD)

WordPress preferă ImageMagick când extensia PHP este prezentă și revine la GD în lipsa ei. Pe găzduirile partajate, ImageMagick este frecvent problema: fișierul său de configurare a politicilor restricționează memoria, spațiul pe disc și suprafața per operație, iar când o redimensionare depășește una dintre aceste limite, procesul moare fără un mesaj util. De obicei vezi asta la imagini mari, în timp ce cele mici merg — ceea ce seamănă cu Ramura B, dar nu este.

Forțează GD ca să testezi ipoteza:

add_filter( 'wp_image_editors', function ( $editors ) {
    return array( 'WP_Image_Editor_GD' );
} );

Pune asta în functions.php sau într-un mic mu-plugin, reia încărcarea, apoi scoate codul dacă nu se schimbă nimic.

Compromisul sincer: GD nu este strict mai bun. Ține imaginea completă necomprimată în memoria PHP, așa că la fișiere foarte mari poate atinge memory_limit acolo unde ImageMagick — care lucrează parțial în afara alocării PHP — ar fi reușit. Schimbarea poate înlocui un eșec cu altul. Tratează-l întâi ca instrument de diagnostic și abia apoi ca soluție.

Ramura E — permisiunile dosarului de încărcări

Rară pe găzduirile administrate, frecventă imediat după o migrare sau o mutare manuală de server. Dacă wp-content/uploads nu este inscriptibil de utilizatorul serverului web sau dacă un subdosar an/lună nou creat a moștenit proprietarul greșit, scrierea eșuează.

ls -ld wp-content/uploads
ls -ld wp-content/uploads/2026/07

Dosarele ar trebui să fie de obicei 755 și să aparțină utilizatorului sub care rulează PHP. Nu pune 777 doar pentru că ți-a zis cineva pe un forum — asta rezolvă simptomul făcând dosarul inscriptibil de orice cont de pe server, ceea ce pe găzduire partajată este o expunere reală.

Ramura F — numele fișierului

Cea mai ieftină verificare din listă, așa că fă-o devreme, chiar dacă este cea mai puțin probabilă. Redenumește fișierul folosind doar litere mici, cifre și cratime — fără diacritice, apostrofuri, ampersand, # sau caractere non-latine — și încarcă din nou. Caracterele speciale declanșează ocazional o regulă de securitate sau se strică pe un sistem de fișiere cu codare nepotrivită. Zece secunde ca să elimini varianta.

Ce să nu faci

Nu începe prin a dezactiva toate modulele. Este deranjant și testează doar Ramura A și Ramura D. Răspunsul din rețea îți spune mai multe în cinci secunde.

Nu adăuga o linie de handler la întâmplare în .htaccess. Fragmentele care circulă și care adaugă o directivă SetHandler sau AddHandler presupun configurația PHP a unei anumite găzduiri. Pe o stivă greșită, pun tot situl la pământ cu un 500.

Nu accepta „a mers la a doua încercare” ca rezolvare. Succesul intermitent este semnătura Ramurii B și va reveni în clipa în care serverul este ocupat sau cineva încarcă ceva mai mare.

Tot blocat?

Dacă răspunsul este un 200 curat cu JSON valid și încărcarea tot eșuează, defecțiunea apare după ce fișierul ajunge pe server — de obicei un modul agățat de lanțul de procesare a atașamentelor care aruncă o eroare fatală, sau un modul de optimizare care trimite propria cerere către un serviciu extern și expiră. Activează WP_DEBUG_LOG, reproduce problema și trece eroarea fatală rezultată prin decodorul de jurnal de erori, ca să vezi ce fișier și ce cârlig sunt de fapt responsabile.