«Error HTTP» en pujar imatges a WordPress és un avís genèric, no una causa concreta. La petició es pot bloquejar abans d’arribar a PHP, fallar en rebre el fitxer o completar la transferència i trobar un problema en generar miniatures. Augmentar límits o desactivar plugins sense saber quina fase falla pot no resoldre res.
Si el missatge diu «Falta una carpeta temporal», consulta la guia específica del temporal de PHP. Si les imatges es pugen però no es veuen, registra aquest comportament per separat. No tots els problemes de la biblioteca tenen el mateix origen.
Comença amb dos fitxers i una petició concreta
Prova un JPEG petit amb nom senzill i després la imatge que falla. Anota pes, dimensions, format, hora i usuari que fa la prova. Que el fitxer petit funcioni orienta cap a diferències entre fitxers o límits; no descarta tots els problemes de permisos, filtres o rutes.
A les eines del navegador, identifica la petició de pujada fallida a la pestanya de xarxa. Desa’n l’estat HTTP i el missatge de resposta, si n’hi ha. No comparteixis una exportació de xarxa sense revisar-la: pot contenir galetes, capçaleres d’autorització i dades privades.
Com interpretar els senyals més habituals
- 413: revisa el límit del cos de la petició al servidor o intermediari que retorna la resposta. No demostra per si sol que el límit sigui de PHP.
- 403: comprova permisos de l’acció, sessió i registres del sistema de seguretat. No desactivis el tallafoc de tota la web.
- 500 o timeout: relaciona l’hora amb els registres del servidor i PHP. El codi sol no identifica memòria, plugin o llibreria.
- Resposta 200 amb un error a dins: llegeix el resultat de l’aplicació; rebre HTTP 200 no garanteix que WordPress hagi creat l’adjunt.
- Fitxer present sense miniatures: revisa el processament posterior, el format i els errors de generació de mides.
Els estats descriuen la resposta d’una capa, no un diagnòstic complet. Pots consultar les definicions de 413 i 403 per interpretar el bloqueig abans de triar una correcció.
Revisa límits sense confondre pes i dimensions
upload_max_filesize limita un fitxer; post_max_size limita la petició completa i necessita marge per a la resta de dades. També hi pot haver límits del servidor intermediari o del hosting. Demana els valors efectius del PHP web i identifica la capa que rebutja la petició. Canviar una constant de WordPress no modifica automàticament tots aquests límits.
Una imatge comprimida pot ocupar pocs megabytes i tenir dimensions enormes. Descodificar-la i generar diverses mides exigeix recursos diferents de transferir-la. Revisa l’error real, la memòria disponible per a PHP i la llibreria utilitzada. WP_MEMORY_LIMIT no garanteix que el servidor concedeixi més memòria ni corregeix una política d’Imagick.
Comprova el destí i la llibreria d’imatges
Si el fitxer no es pot desar, comprova el temporal de PHP, el directori final de pujades, quotes i accés del procés. Els permisos depenen del propietari i del model d’allotjament; no substitueixis el diagnòstic per una recepta de 755, 644 o 777.
Si la recepció funciona, revisa a Salut del lloc la informació disponible sobre GD o Imagick i els formats admesos per la instal·lació. Relaciona aquestes dades amb el fitxer concret. Una conversió a JPEG serveix com a prova per acotar un format; conserva l’original i comprova si necessites transparència o qualitat que la conversió no manté.
Aïlla conflictes amb una prova acotada
Compara els canvis recents amb els registres abans de tocar components. Si l’evidència apunta a un plugin d’optimització, emmagatzematge extern o seguretat, reprodueix l’error a staging i canvia una sola variable. Defineix quina funció afecta, com restaurar-la i com repetir la prova. Desactivar tots els plugins en producció pot interrompre formularis, comandes i accessos.
Si necessites ajuda per ordenar la intervenció, el procés de reparació de WordPress comença per avaluació i abast. Una limitació de hosting s’ha de coordinar amb qui controla aquesta capa.
Què has de comprovar després de corregir la causa
- Puja una imatge petita i una altra representativa de la feina real.
- Comprova l’adjunt i les mides esperades a la biblioteca.
- Insereix la imatge en una pàgina de prova i obre-la a la web.
- Repeteix el format que fallava i revisa els errors del mateix interval.
- Confirma que s’han restaurat les proteccions o els components utilitzats durant la prova.
No repeteixis indiscriminadament una pujada gran que torna a esgotar recursos. Conserva una prova reproduïble i evita generar adjunts duplicats durant el diagnòstic.
Què has d’enviar per sol·licitar una avaluació
Prepara URL, missatge exacte, hora, pes i dimensions del fitxer, resposta HTTP, canvis recents i resultat de la prova petita. Explica si bloqueja publicacions, productes o una campanya. Envia només informació revisada; mai contrasenyes, galetes o un registre complet sense filtrar.
Sol·licita una avaluació de l’error de pujada. Es revisa el símptoma i s’acorda l’abast abans d’intervenir; no es pot triar una reparació només pel text «Error HTTP».
Preguntes freqüents sobre l’error HTTP
Una imatge més petita resol el problema?
Pot evitar un límit concret i ajudar a diagnosticar-lo. No confirma que s’hagi corregit la configuració ni que el fitxer original es pugui processar.
He d’augmentar la memòria de WordPress?
Només si l’error i els límits efectius ho justifiquen. Un bloqueig del servidor intermediari o del tallafoc requereix una altra intervenció.
HTTP 200 significa que la pujada ha funcionat?
No necessàriament. Comprova la resposta de WordPress i que existeixi l’adjunt amb les mides previstes.
És segur desactivar tots els plugins?
No és un primer pas adequat per a una web en producció. Una prova controlada ha de tenir abast, recuperació i verificació.
CRITERI D’INCIDENT WP REPAIR
Com acotar l’error sense endevinar
El carregador de suports combina transferència, autenticació, escriptura i processament d’imatge. Un petit fitxer de control revela quina etapa falla abans de tocar permisos o memòria.
Prova un JPEG petit i anota la resposta de xarxa de la càrrega.
Confirma si el fitxer arriba a uploads encara que falli la creació de miniatures.
Llegeix registres PHP per errors d'Imagick, GD, memòria o timeout a la mateixa hora.
Verifica la mida de càrrega i POST, propietari i directori temporal.
Què ha de quedar verificat
- Puja una imatge petita i una de gran realista.
- Es generen i es poden llegir les mides esperats.
- El front les serveix sense errors de permisos ni contingut mixt.
Fonts tècniques oficials
Continua el diagnòstic
Aquesta guia explica el diagnòstic. Si la web està afectada ara mateix, la intervenció ha de preservar una via de recuperació i verificar el recorregut real del negoci.
Veure el servei de reparació urgent →SOBRE ESTE SÍNTOMA
Preguntes freqüents d'aquesta guia.
Com puc reduir ràpidament si això és un problema de mida o alguna cosa més?+
Intenteu pujar primer un petit JPEG de 100 KB. Si això té èxit, el problema és específic per a la mida o processament en comptes de permisos o un bloc de servidor de manta, que descarta immediatament una gran categoria de causes.
Està bé simplement establir els permisos de la carpeta de càrregues a 777 per fer que l’error desaparegui?+
No — que canvia un inconvenient menor per una exposició de seguretat real. El directori de càrregues ha de ser escrit (per a carpetes, 644 per a fitxers) i propietat de l’usuari web correcte, el que és suficient; afluixar-lo encara més no és necessari i no és segur.
La imatge puja bé i apareix a la biblioteca dels mitjans, però és suficient per considerar-la fixa?+
No necessàriament — una càrrega que aterra a la biblioteca però que no produeix versions de miniatures redimensionades segueix sent una canonada trencada. Confirme que les versions redimensionades van ser creades i que la imatge es mostra correctament a la part davantera, no només que apareix a la biblioteca.
Podria el meu theme estar causant això tot i que l’error s'assembla a un problema del servidor?+
Sí. Un theme pot connectar-se a la canonada de càrrega i interferir amb el processament, de manera que canviar temporalment a una theme per omissió és un dels passos estàndard per aïllar la causa, juntament amb la comprovació de Site Health per a una biblioteca d’imatges faltant o un límit de memòria baix.