Imagini WordPress pe shared hosting: erori și soluții

Încărcarea imaginilor WordPress pe shared hosting eșuează de obicei în una dintre două etape: primirea fișierului sau procesarea lui după upload. Erorile afișate înainte ca progresul să ajungă la 100% indică de regulă o limită pentru dimensiunea fișierului, request body, directorul temporar sau filtrarea de securitate. Erorile afișate după finalizarea transferului înseamnă frecvent că GD sau ImageMagick nu a putut decoda imaginea, genera dimensiunile responsive ori scrie fișierele înainte de epuizarea memoriei, timpului sau spațiului disponibil.

Scris de echipa tehnică ServerSpan.

Stabilește dacă a eșuat uploadul sau procesarea imaginii

Prima verificare este dacă fișierul original a ajuns în wp-content/uploads. După primirea lui, WordPress creează attachmentul, citește imaginea, aplică informațiile de orientare, scalează originalele foarte mari și generează toate dimensiunile înregistrate de nucleu, temă și pluginuri.

Dacă originalul apare în Media Library după reîmprospătarea paginii, dar thumbnailul este gol sau lipsesc dimensiunile medium și large, transferul HTTP a reușit probabil. Problema a apărut în timpul post-procesării.

Simptom vizibil	Etapă probabilă	Prima verificare
Fișierul este respins imediat deoarece este prea mare	Limită PHP sau web server	Compară upload_max_filesize, post_max_size și limita pentru request body
Progresul ajunge la 100%, apoi WordPress spune că serverul nu poate procesa imaginea	Decodare sau generare de dimensiuni	Verifică editorul activ, memoria, timeouturile și logul PHP
Originalul apare, dar thumbnailurile lipsesc	Procesarea s-a oprit după salvarea fișierului	Verifică metadata attachmentului și regenerează dimensiunile după repararea cauzei
WordPress nu poate crea directorul sau muta fișierul	Filesystem sau permisiuni	Verifică directorul uploads și accesul PHP la scriere
Browserul raportează HTTP 413	Serverul web sau proxy-ul respinge cererea	Verifică limita pentru dimensiunea cererii
Cererea returnează HTTP 406	Filtrare de securitate	Verifică logul ModSecurity și regula declanșată
Cererea returnează intermitent 500 sau 503	Limită de PHP workers, RAM, procese sau timp	Corelează timestampul cu logurile PHP și metricile contului

O eroare HTTP 406 aparține unui traseu de diagnostic separat. Ghidul ServerSpan despre acțiunile WordPress care declanșează ModSecurity 406 explică identificarea regulii fără dezactivarea globală a firewallului aplicației web.

Un JPEG mic poate necesita sute de megabytes în timpul procesării

Dimensiunea comprimată afișată pe calculator nu reprezintă memoria necesară editorului de imagini. Un JPEG de 5 MB poate ocupa zeci sau sute de megabytes după decodarea în pixeli.

O estimare minimă pentru un singur buffer cu patru bytes per pixel este:

Memorie buffer = lățime × înălțime × 4 bytes.

Dimensiuni	Număr de pixeli	Un buffer de patru bytes	Semnificație practică
4.000 × 3.000	12 megapixeli	Aproximativ 45,8 MiB	Numai sursa poate consuma o parte importantă din memoria PHP disponibilă
6.000 × 4.000	24 megapixeli	Aproximativ 91,6 MiB	Bufferul sursă și cel destinație pot depăși 128 MiB înainte de includerea WordPress
8.000 × 6.000	48 megapixeli	Aproximativ 183,1 MiB	Un singur buffer poate depăși limita PHP a unui cont de shared hosting

Calculul acoperă numai un buffer simplificat. Redimensionarea poate necesita simultan imaginea originală, bufferul destinație, metadata, memoria bibliotecii și resursele deja folosite de WordPress, temă și pluginuri. Imaginile PNG cu transparență și fotografiile cu rezoluție mare pot eșua chiar dacă fișierul comprimat pare mic.

WordPress folosește implicit pragul de 2560 de pixeli pentru scalarea imaginilor mari. Acesta este motivul pentru care mesajul generic poate recomanda o imagine cu latura maximă sub 2560 de pixeli. Nu înseamnă că orice imagine peste prag trebuie să eșueze sau că orice imagine mai mică va funcționa.

Redimensionează latura cea mai lungă la 2560 de pixeli sau mai puțin atunci când website-ul nu are nevoie de rezoluția originală a camerei. Dacă eșuează și un JPEG de 1200 × 800, cauza nu mai este probabil numai dimensiunea imaginii.

WordPress încearcă de obicei ImageMagick înainte de GD

WordPress selectează una dintre implementările disponibile pentru editorul său de imagini. Ordinea implicită este ImageMagick prin extensia PHP Imagick, urmată de biblioteca GD.

Deschide Unelte → Sănătate site → Informații → Gestionare media și notează valorile înainte de orice modificare:

• Editorul activ.
• Versiunile ImageMagick și Imagick.
• Versiunea GD și formatele acceptate.
• Dimensiunea maximă pentru upload și POST.
• Starea funcției PHP pentru uploaduri.

GD și ImageMagick pot eșua din motive diferite. GD păstrează imaginea decodată într-o resursă de memorie administrată prin PHP. Epuizarea limitei PHP este astfel frecventă la imaginile cu rezoluție mare.

ImageMagick poate muta pixel cache-ul din memorie în mapped storage sau pe disc, dar aplică și propriile politici de securitate și resurse. O politică restrictivă poate opri procesarea chiar dacă PHP mai raportează memorie liberă.

Nu forța permanent GD numai pentru că un test a funcționat. Confirmă mai întâi că aceeași imagine eșuează repetat cu Imagick și reușește cu GD. Furnizorul trebuie apoi să verifice extensia Imagick, politicile ImageMagick, directorul temporar și logurile relevante.

Fiecare limită PHP controlează altă etapă

Mărirea valorii upload_max_filesize nu oferă automat mai mult RAM pentru generarea thumbnailurilor. Directivele PHP sunt independente și se aplică în momente diferite.

Directivă PHP	Ce limitează	Eroare tipică	Regulă de decizie
upload_max_filesize	Dimensiunea unui singur fișier	Fișierul este respins înainte de procesare	Configureaz-o peste cel mai mare fișier acceptat intenționat
post_max_size	Dimensiunea completă a cererii POST	Cererea ajunge fără fișierul așteptat	Trebuie să fie mai mare decât upload_max_filesize
memory_limit	Memoria alocată scriptului PHP	Allowed memory size exhausted	Include pixelii decodați, WordPress, tema și pluginurile
max_input_time	Timpul pentru primirea și parsarea datelor	Uploadul se oprește pe conexiuni lente	Mărește-l numai când transferul depășește limita
max_execution_time	Timpul de execuție al scriptului	Procesarea se oprește în timpul generării dimensiunilor	Mărește-l numai când logurile confirmă depășirea
upload_tmp_dir	Directorul temporar pentru uploaduri	Director temporar lipsă sau eroare la scriere	Calea trebuie să existe, să permită scrierea și să aibă spațiu liber

Site Health afișează valorile folosite de cererea web și este mai relevant decât un fișier php.ini găsit întâmplător prin SSH. Un server shared poate folosi versiuni și configurații PHP diferite pentru Apache, PHP-FPM și linia de comandă.

Cu acces WP-CLI, următoarea comandă read-only afișează valorile procesului PHP folosit de CLI:

wp eval '
$keys = array(
    "memory_limit",
    "upload_max_filesize",
    "post_max_size",
    "max_execution_time",
    "max_input_time",
    "upload_tmp_dir"
);

foreach ( $keys as $key ) {
    echo $key . "=" . ini_get( $key ) . PHP_EOL;
}

echo "imagick=" . ( extension_loaded( "imagick" ) ? "yes" : "no" ) . PHP_EOL;
echo "gd=" . ( extension_loaded( "gd" ) ? "yes" : "no" ) . PHP_EOL;
'

Outputul trebuie să confirme existența a cel puțin unei biblioteci de procesare. Valorile diferite față de Site Health nu înseamnă că WordPress raportează greșit. De obicei, WP-CLI folosește alt executabil PHP sau altă configurație. Comanda wp cli info arată binarul PHP și fișierul php.ini încărcat de CLI.

Definirea constantei WP_MEMORY_LIMIT în wp-config.php este numai o solicitare făcută de WordPress. Nu poate depăși o limită PHP sau o restricție hard impusă contului de hosting.

ImageMagick poate avea limite independente de PHP

ImageMagick poate limita lățimea, înălțimea, aria pixelilor, heap memory, mapped memory, cache-ul pe disc, numărul de threaduri și durata procesării. Clienții de shared hosting nu pot modifica de obicei fișierul global policy.xml.

Cu acces shell, verifică politica activă fără să o modifici:

magick identify -list policy
magick identify -list resource

Serverele care folosesc ImageMagick 6 pot expune comenzile fără prefixul magick:

identify -list policy
identify -list resource

Caută valori neobișnuit de mici pentru memory, map, disk, width, height sau time. Atingerea limitei de memorie nu oprește întotdeauna imediat operațiunea. ImageMagick poate folosi mapped storage sau cache pe disc, iar procesarea devine mai lentă și poate lovi apoi limita de timp sau de stocare.

Trimite furnizorului outputul, dimensiunile imaginii și timestampul erorii. Nu solicita eliminarea tuturor limitelor. Politicile protejează serverul shared împotriva imaginilor malformate și a vârfurilor simultane de procesare. Soluția corectă este o limită suficientă pentru imagini web normale, fără ca un singur cont să consume toate resursele hostului.

Spațiul, inode-urile și permisiunile pot opri generarea thumbnailurilor

Un cont poate avea gigabytes liberi și totuși să nu mai poată crea fișiere deoarece a epuizat inode-urile, spațiul temporar sau permisiunea de scriere în directorul uploads al lunii curente.

Verifică Unelte → Sănătate site → Informații → Directoare și dimensiuni, precum și secțiunea despre permisiunile filesystemului. WordPress trebuie să poată scrie în directorul de upload.

Cu acces shell, folosește verificări read-only:

df -h
df -ih

find wp-content/uploads -maxdepth 2 -type d ! -writable -print

find wp-content/uploads -maxdepth 2 -type f | tail -n 20

df -h afișează capacitatea filesystemului, iar df -ih arată utilizarea inode-urilor. Un filesystem ajuns la 100% în oricare dintre rezultate nu mai poate crea thumbnailuri sau fișiere temporare.

Verificarea directoarelor nu ar trebui să returneze căi din uploads. Un rezultat înseamnă că utilizatorul shell consideră directorul inaccesibil pentru scriere, dar utilizatorul PHP poate fi diferit. Nu aplica recursiv chmod 777 și nu modifica ownershipul fără să cunoști modelul contului. Furnizorul trebuie să confirme utilizatorul și permisiunile corecte.

Logul PHP trebuie să decidă următoarea modificare

Repetă o singură încărcare eșuată și notează ora exactă, numele fișierului, formatul și dimensiunile în pixeli. Verifică apoi logul PHP al contului prin panoul de hosting.

Text în log	Semnificație	Acțiune
Allowed memory size exhausted	Procesul PHP a ajuns la limita de memorie	Redu dimensiunile, elimină procesarea inutilă sau solicită o limită efectivă mai mare
Maximum execution time exceeded	Procesarea PHP a durat prea mult	Verifică dimensiunile și numărul de variante generate înainte de mărirea timeoutului
ImagickException sau cache resources exhausted	ImageMagick a respins operațiunea sau a epuizat o resursă	Verifică politicile, spațiul temporar și suportul formatului
No space left on device	Discul sau spațiul temporar este plin	Verifică quota contului, filesystemul și directorul temporar
Permission denied	PHP nu poate citi sursa sau scrie fișierul generat	Corectează ownershipul și permisiunile conform modelului de hosting
Nicio eroare PHP, dar browserul returnează 413 sau 406	Cererea a fost respinsă înainte de finalizarea PHP	Verifică logurile serverului web, proxy-ului sau sistemului de securitate

Dacă operațiunea afișează și mesajul generic privind o eroare critică, urmează procesul de logging și recuperare din ghidul ServerSpan despre remedierea erorii critice WordPress.

Folosește imagini de test controlate, nu modifica toate setările simultan

Un set de test util conține aceeași imagine exportată în mai multe variante:

• Imaginea originală.
• Aceeași imagine redimensionată la o latură maximă de 2560 de pixeli.
• Un JPEG de 1200 de pixeli exportat fără metadata neobișnuită.
• Un JPEG sau PNG despre care știi că a funcționat anterior.

Dacă eșuează numai originalul, serverul atinge probabil o limită legată de dimensiunea decodată. Dacă eșuează fiecare imagine nouă, verifică editorul, permisiunile, directorul temporar și starea serviciilor. Dacă numai un fișier eșuează indiferent de dimensiune, acesta poate fi corupt sau poate folosi o caracteristică neacceptată de biblioteca instalată.

Dezactivează pluginuri numai pe staging sau într-o fereastră controlată. Pluginurile pentru optimizare, WebP, watermark, securitate și e-commerce pot adăuga procesări sau dimensiuni suplimentare. Un conflict este demonstrat numai dacă același fișier reușește după dezactivarea unui anumit plugin și eșuează din nou după reactivare.

Regenerează dimensiunile lipsă numai după repararea serverului

Dacă originalul există, dar variantele responsive lipsesc, corectează întâi problema server-side. Altfel, operațiunea de regenerare va repeta aceeași eroare pentru un număr mare de fișiere.

Afișează dimensiunile înregistrate de WordPress, temă și pluginuri:

wp media image-size

Testează apoi un singur attachment cunoscut:

wp media regenerate 123 --only-missing

Un rezultat corect confirmă regenerarea thumbnailurilor pentru attachmentul 123. O eroare oferă un test repetabil din CLI, fără uploaderul browserului.

Creează un backup actual înaintea unei regenerări generale. O bibliotecă media mare poate consuma mult CPU și I/O. Procesează fișierele în loturi controlate sau solicită programarea operațiunii în afara orelor aglomerate.

Shared hosting este suficient când imaginile web normale sunt procesate fiabil

Un website WordPress nu are nevoie automat de VPS doar pentru că folosește fotografii. Shared hosting rămâne potrivit când imaginile JPEG, PNG și WebP obișnuite sunt procesate corect, editorul este actualizat, limitele susțin dimensiunile înregistrate, iar furnizorul poate investiga erorile contului.

Un VPS devine justificat pentru importuri repetate în masă, imagini sursă foarte mari, numeroase dimensiuni custom sau un pipeline care necesită control asupra politicilor ImageMagick și joburilor în fundal. Decizia trebuie bazată pe un workload repetabil, nu pe un singur fișier corupt.

Comparația ServerSpan dintre shared hosting și VPS explică diferența dintre comoditate și control. Un VPS unmanaged oferă acces la configurație, dar transferă către tine responsabilitatea pentru PHP, ImageMagick, securitate, backupuri și monitorizare.

Dacă furnizorul actual nu poate oferi un editor WordPress funcțional, valorile PHP efective sau loguri utile, serviciul ServerSpan de găzduire web cu DirectAdmin oferă un mediu shared administrat pentru WordPress. Include în solicitarea de suport imaginea problematică, dimensiunile sale, ora exactă a erorii și raportul Site Health pentru media.

Regula practică este clară. Dacă originalul nu ajunge în directorul uploads, verifică limitele cererii și filesystemul. Dacă originalul există, dar variantele sale lipsesc, verifică GD sau ImageMagick, memoria necesară pixelilor decodați, timpul de procesare și accesul la scriere. Modifică numai limita identificată prin dovezi.