Corriger l’erreur HTTP d’upload d’images WordPress

Si vous voyez soudain « Erreur HTTP » au moment d’envoyer une image dans la médiathèque, c’est rarement “WordPress qui bugge” au hasard. Dans la pratique, c’est presque toujours un échec côté serveur (mémoire, permissions, pare-feu) que l’interface WordPress résume en un message trop vague.

Le problème

Le message typique apparaît dans l’admin, au moment d’ajouter un média (Médias → Ajouter ou via l’éditeur de blocs) :

Erreur HTTP.

Vous le voyez dans wp-admin, pas sur le front-end. L’upload commence parfois (barre de progression), puis échoue. Souvent, ça arrive :

après une mise à jour WordPress (ici, vous êtes en WordPress 6.9.4) ou PHP,
après l’activation d’un plugin de sécurité/cache,
après un changement d’hébergeur, un passage derrière Cloudflare/WAF,
sur des images lourdes (smartphone en HEIC converti, PNG très grand, etc.).

À la fin, vous saurez diagnostiquer la cause la plus probable, lire les indices (logs/console), et appliquer une correction adaptée sans “toucher au core”.

Résumé rapide

Commencez par vérifier mémoire PHP et traitement d’image (Imagick/GD) : c’est la cause n°1 sur les sites de blogueurs.
Ensuite, contrôlez wp-content/uploads (droits, propriétaire, espace disque) et la configuration des chemins (ABSPATH, WP_HOME/WP_SITEURL).
Si l’erreur est intermittente, suspectez un WAF/ModSecurity ou un plugin de sécurité qui bloque la requête.
Activez temporairement WP_DEBUG + consultez debug.log : le message “Erreur HTTP” cache souvent une vraie erreur PHP.
Testez sans conflit avec Health Check et vérifiez la console navigateur (onglet Réseau) sur l’upload.

Les symptômes

Selon la cause, “Erreur HTTP” s’accompagne d’autres signes. Voici ceux que je vois le plus souvent sur des sites en production (Divi, Elementor, Avada compris) :

Échec uniquement sur les grosses images (ex. > 5–10 Mo) ou dimensions très grandes.
Échec uniquement sur certains formats (PNG, WebP, parfois HEIC via conversion).
Miniatures non générées : l’image “monte”, mais reste en “cassé” ou sans tailles intermédiaires.
Erreur 500 dans l’onglet Réseau du navigateur sur async-upload.php ou sur une route REST liée à l’éditeur.
Erreur 403 (interdit) lors de l’upload : typique d’un WAF/ModSecurity.
Écran blanc ou “Il y a eu une erreur critique” juste après l’envoi.
Ça marche en local mais pas en production (différences PHP, extensions Imagick, limites mémoire, règles WAF).
Ça marche pour un admin mais pas pour un éditeur (droits/quotas, politiques de sécurité, filtrage MIME).

Compatibilité page builders : Divi 5, Elementor et Avada s’appuient sur la médiathèque WordPress. Si l’upload échoue dans Médias, il échouera aussi dans leurs sélecteurs d’images. La différence, c’est que certains builders masquent encore plus l’erreur (overlay “Upload failed”).

Pourquoi ça arrive

Explication simple (débutant)

Quand vous uploadez une image, WordPress ne fait pas qu’“enregistrer un fichier”. Il doit :

recevoir le fichier via PHP,
l’écrire dans wp-content/uploads,
lire l’image pour en extraire les métadonnées,
générer plusieurs tailles (miniatures),
et enregistrer tout ça en base.

Si une étape échoue (mémoire insuffisante, dossier non accessible, pare-feu qui bloque), l’interface résume souvent par “Erreur HTTP”.

Explication technique (intermédiaire/pro)

En WordPress 6.9.4, l’upload passe généralement par async-upload.php (admin) et/ou des appels REST selon le contexte éditeur. L’erreur “HTTP” est souvent un statut non-200 (500/403/413) ou une réponse tronquée. Les causes, par fréquence :

Limites PHP : memory_limit, max_execution_time, upload_max_filesize, post_max_size.
Traitement d’image : Imagick qui segfault, politique ImageMagick, manque de mémoire pendant la création des tailles.
Permissions / propriétaire : WordPress ne peut pas écrire dans uploads.
WAF/ModSecurity : blocage sur multipart/form-data, faux positif.
Reverse proxy / CDN : limite de taille (413 Request Entity Too Large).
Conflit plugin/thème : hooks sur upload, filtrage MIME, optimisation d’images, sécurité.
Disque plein / inode : l’écriture échoue, parfois sans message clair.

Je vois très souvent le duo “image trop grande + Imagick + memory_limit trop bas” sur des hébergements mutualisés, surtout après un passage à PHP 8.1+ où les réglages ont été réinitialisés.

Prérequis avant de commencer

Sauvegarde : faites une sauvegarde fichiers + base avant toute modification (ou travaillez sur une préproduction).
Versions : WordPress 6.9.4, PHP recommandé 8.1+. Vérifiez dans Outils → Santé du site.
Ne modifiez jamais le core (wp-includes, wp-admin). Tout correctif doit aller dans un plugin, un thème enfant, ou une configuration serveur.
Outils utiles :
- Query Monitor (pour voir erreurs PHP/HTTP et requêtes),
- Health Check & Troubleshooting (mode dépannage sans casser le site public),
- accès aux logs PHP (error_log) côté hébergeur.

Pour le debug WordPress, référez-vous à la doc officielle : Debugging in WordPress.

Solution 1 : Corriger les limites mémoire (PHP) et les traitements d’image (Imagick/GD)

Cette solution vise les cas où l’upload échoue surtout sur les images “lourdes” et où vous observez des erreurs 500 côté serveur. Le symptôme typique : une image de 8–15 Mo échoue, une image de 300 Ko passe.

Étape A : vérifier les limites côté WordPress

Allez dans Outils → Santé du site → Info → Serveur. Relevez :

memory_limit (PHP),
upload_max_filesize, post_max_size, max_execution_time,
bibliothèque d’image (Imagick ou GD).

Étape B : corriger un snippet “mémoire” mal fait (AVANT / APRÈS)

J’ai souvent vu des snippets copiés d’anciens tutos, collés dans le mauvais fichier, ou avec une constante redéfinie trop tard. Exemple classique : définir WP_MEMORY_LIMIT dans functions.php (trop tard) ou avec une faute de syntaxe.

AVANT (cassé / inefficace)

Ce code est fréquent, mais il est au mauvais endroit (dans le thème) et ne change rien si PHP limite déjà plus bas :

<?php
// Mauvaise pratique : dans functions.php, WordPress a déjà chargé la mémoire
define('WP_MEMORY_LIMIT', '256M')  // Oubli du point-virgule => fatal error

APRÈS (corrigé)

Faites-le proprement :

Option 1 (recommandée) : augmentez la mémoire côté PHP (hébergeur) — c’est la vraie limite.
Option 2 : ajustez aussi WordPress, mais au bon endroit.

Où coller le code : dans wp-config.php, juste avant la ligne “That’s all, stop editing”. Sauvegardez avant de modifier.

<?php
// wp-config.php

// Augmente la mémoire que WordPress essaie d'utiliser (si PHP le permet).
// À placer avant "/* That's all, stop editing! */".
define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // Utile pour certaines opérations admin (miniatures, imports).

Pourquoi ça aide : la génération des miniatures peut consommer beaucoup de RAM, surtout avec de grandes images. Si PHP coupe le process (fatal error / out of memory), l’admin reçoit une réponse incomplète et affiche “Erreur HTTP”.

Référence PHP : memory_limit.

Étape C : traiter le cas Imagick instable (forcer GD pour tester)

Sur certains serveurs, Imagick est présent mais instable (policy.xml trop restrictive, version compilée bizarrement, manque de délégués). Pour isoler le problème, vous pouvez forcer WordPress à utiliser GD temporairement.

Où coller le code : créez un mu-plugin (plugin must-use) pour éviter qu’un thème/page builder le désactive. Chemin : wp-content/mu-plugins/force-gd-image-editor.php. Si le dossier mu-plugins n’existe pas, créez-le.

<?php
/**
 * Plugin Name: Force GD Image Editor (diagnostic)
 * Description: Force l'utilisation de GD au lieu d'Imagick pour diagnostiquer les erreurs d'upload/miniatures.
 * Author: Votre Nom
 * Version: 1.0.0
 *
 * À retirer après diagnostic.
 */

defined( 'ABSPATH' ) || exit;

/**
 * Filtre = "hook" qui modifie une valeur.
 * Ici, on modifie la liste des éditeurs d'image disponibles.
 */
add_filter( 'wp_image_editors', function( array $editors ): array {
	// GD en premier, Imagick ensuite.
	return array(
		'WP_Image_Editor_GD',
		'WP_Image_Editor_Imagick',
	);
} );

Pourquoi ça corrige (ou confirme) : si l’upload refonctionne avec GD, vous avez un signal fort que le problème vient d’Imagick côté serveur. À ce stade, la “vraie” correction est souvent serveur : mettre à jour ImageMagick/Imagick, corriger les policies, ou demander à l’hébergeur.

Doc filtre (API Hooks) : Hooks (actions & filtres).

Étape D : vérifier la taille réellement envoyée (413 / limites proxy)

Si votre console réseau montre un 413 Request Entity Too Large, WordPress n’y peut rien : c’est Nginx/Apache/CDN qui refuse.

Nginx : client_max_body_size
Apache : parfois via directives/proxy
Cloudflare/WAF : limites selon plan

Dans ce cas, augmentez la limite côté serveur, ou compressez l’image avant upload (solution de contournement).

Solution 2 : Réparer les permissions / le dossier uploads et les chemins WordPress

Quand WordPress ne peut pas écrire dans wp-content/uploads, l’upload peut échouer avec “Erreur HTTP” (ou parfois “Impossible de créer le répertoire”). C’est très fréquent après une migration, un restore, ou un changement de propriétaire de fichiers.

Étape A : diagnostic rapide (sans code)

Vérifiez l’espace disque et les inodes (cPanel/Panel hébergeur).
Testez l’upload d’un petit JPG (50 Ko). Si même ça échoue, suspectez permissions/403.
Dans Santé du site → Info → Répertoires et tailles, repérez si uploads est accessible.

Étape B : corriger un “mauvais chemin uploads” (AVANT / APRÈS)

J’ai vu des sites avec une constante UPLOADS définie dans wp-config.php (vieille astuce) ou un plugin de “media offload” mal configuré. Résultat : WordPress pointe vers un dossier inexistant.

AVANT (cassé)

Où ça se trouve : souvent dans wp-config.php après une migration.

<?php
// wp-config.php

// Ancienne bidouille : force un chemin custom qui n'existe plus après migration.
define( 'UPLOADS', 'wp-content/uploads-old' );

APRÈS (corrigé)

Supprimez la constante si vous n’avez pas un besoin réel de chemin custom.

<?php
// wp-config.php

// Supprimez la ligne define('UPLOADS', ...) si présente.
// WordPress utilisera wp-content/uploads par défaut.

Pourquoi ça corrige : WordPress redevient cohérent avec son arborescence standard, et les fonctions d’upload retrouvent le bon répertoire.

Étape C : corriger les permissions via SSH (cas courant)

Attention sécurité : n’appliquez pas du 777 “pour que ça marche”. C’est une porte ouverte sur un serveur mutualisé mal isolé.

Où agir : côté serveur (SSH). Si vous n’avez pas SSH, utilisez le gestionnaire de fichiers de l’hébergeur et corrigez propriétaire/droits.

# Depuis la racine WordPress
# Ajustez "www-data" selon votre serveur (parfois "apache", "nginx", ou votre user FTP).

sudo chown -R www-data:www-data wp-content/uploads

# Dossiers : 755 ; fichiers : 644
find wp-content/uploads -type d -exec chmod 755 {} ;
find wp-content/uploads -type f -exec chmod 644 {} ;

Pourquoi ça corrige : PHP (donc WordPress) doit pouvoir créer des dossiers (année/mois) et écrire les fichiers image. Un mauvais propriétaire après migration casse exactement cette étape.

Étape D : vérifier WP_HOME / WP_SITEURL (cas “upload en boucle”)

Plus rare, mais réel : si votre site a des URL incohérentes (http vs https, domaine différent), l’upload peut échouer (redirections, cookies admin, REST). Vérifiez dans Réglages → Général, ou dans wp-config.php si vous forcez ces valeurs.

Doc officielle (références) : wp-config.php.

Solution 3 : Traquer un blocage serveur (ModSecurity/WAF) ou un échec REST/AJAX

Si l’erreur est aléatoire, dépend du navigateur, ou arrive après activation d’un plugin de sécurité, je suspecte un blocage WAF. J’ai souvent croisé ça avec des règles ModSecurity trop agressives, ou des WAF “gérés” qui voient des faux positifs dans les uploads multipart.

Étape A : regarder la console du navigateur (preuve rapide)

Ouvrez DevTools (F12) → Réseau, puis refaites un upload. Cliquez sur la requête :

403 : blocage WAF/ModSecurity, parfois un plugin sécurité.
500 : erreur serveur (souvent PHP/mémoire) — retournez à la Solution 1.
413 : limite de taille proxy/CDN.
0 / CORS : redirection, mixed content, ou domaine différent.

Étape B : isoler un conflit plugin/thème sans casser le site (Health Check)

Health Check permet un “mode dépannage” qui désactive plugins/thème uniquement pour votre session admin. C’est parfait sur un site en production.

Installez : Health Check & Troubleshooting
Activez le mode dépannage
Désactivez d’abord : sécurité, cache, optimisation d’images, CDN, “media offload”
Retestez l’upload

Si ça remarche, réactivez un par un. Le coupable est presque toujours dans cette famille.

Étape C : cas ModSecurity (solution côté hébergeur)

Vous ne pouvez pas “corriger” ModSecurity avec un snippet WordPress. Il faut :

demander à l’hébergeur les logs WAF autour de l’heure du test,
faire whitelister l’URL /wp-admin/async-upload.php ou la règle qui déclenche,
ou désactiver ModSecurity pour votre vhost (si l’hébergeur le permet).

Ce que vous pouvez fournir au support : statut HTTP (403), URL exacte, user-agent, taille du fichier, et si possible l’ID de règle bloquante.

Étape D : ajouter un log ciblé sur l’upload (diagnostic, pas “solution magique”)

Quand je n’ai pas accès aux logs serveur, j’ajoute parfois un log minimal côté WordPress pour confirmer que le fichier arrive bien jusqu’à WordPress, ou si ça casse avant.

Où coller le code : dans un mu-plugin wp-content/mu-plugins/upload-debug.php. Retirez-le après.

<?php
/**
 * Plugin Name: Upload Debug Log (diagnostic)
 * Description: Journalise les erreurs d'upload WordPress dans wp-content/debug.log (si WP_DEBUG_LOG activé).
 * Version: 1.0.0
 */

defined( 'ABSPATH' ) || exit;

/**
 * Action = "hook" qui exécute du code à un moment donné.
 * Ici : quand WordPress a traité l'upload.
 */
add_action( 'wp_handle_upload', function( array $upload ): array {
	if ( defined( 'WP_DEBUG' ) && WP_DEBUG && defined( 'WP_DEBUG_LOG' ) && WP_DEBUG_LOG ) {
		$context = array(
			'file'  => $upload['file'] ?? null,
			'url'   => $upload['url'] ?? null,
			'type'  => $upload['type'] ?? null,
			'error' => $upload['error'] ?? null,
		);
		error_log( '[upload-debug] ' . wp_json_encode( $context ) );
	}
	return $upload;
}, 10, 1 );

Pourquoi c’est utile : si vous ne voyez jamais ce log, l’échec se produit avant que WordPress ne finalise l’upload (WAF, limite serveur, timeout). Si vous voyez une clé error, vous avez une piste plus concrète que “Erreur HTTP”.

Doc API JSON : wp_json_encode().

Vérifications après correction

Uploadez 3 fichiers : un petit JPG (50–200 Ko), un JPG “smartphone” (2–5 Mo), un PNG (1–3 Mo).
Ouvrez la médiathèque et vérifiez que :
- l’image s’affiche,
- les tailles sont générées (Miniature / Moyen / Grand selon votre thème),
- aucune erreur n’apparaît dans Santé du site.
Si vous avez Query Monitor, vérifiez qu’aucune erreur PHP n’apparaît pendant l’upload.
Videz les caches :
- cache plugin (si présent),
- cache serveur/CDN,
- cache navigateur (ou test en navigation privée).

Sur Divi 5 / Elementor / Avada : refaites un test d’insertion d’image depuis le builder. Si l’upload marche dans Médias mais pas dans le builder, vous avez probablement un conflit JS (rare) ou une restriction de rôle/capacité côté plugin.

Si ça ne marche toujours pas

Voici une procédure que j’applique dans cet ordre, parce qu’elle évite de partir dans tous les sens.

1) Activez un debug propre (temporaire)

Où : dans wp-config.php. Sauvegardez avant.

<?php
// wp-config.php (temporaire)
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false ); // Évite d'afficher des erreurs aux visiteurs

Refaites un upload, puis ouvrez wp-content/debug.log. Si vous voyez “Allowed memory size exhausted”, revenez à la Solution 1. Si vous voyez des erreurs de chemins/permissions, Solution 2.

2) Vérifiez la réponse HTTP exacte

DevTools → Réseau → requête d’upload
Notez le statut (403/413/500) et le “Response”

3) Testez sans conflit (Health Check)

Désactivez en mode dépannage :

plugins de cache/minification,
plugins de sécurité (WAF applicatif),
plugins d’optimisation d’images,
plugins d’upload vers S3/Cloud (offload).

4) Confirmez les extensions PHP

Vous voulez au minimum :

fileinfo (détection MIME),
GD et/ou Imagick (traitement image),
une configuration PHP cohérente avec vos tailles d’images.

5) Vérifiez les limites “invisibles” côté hébergeur

disque plein / quota dépassé,
limite d’inodes,
timeout proxy,
règles ModSecurity.

6) Réinitialisez les permaliens (rare, mais rapide)

Réglages → Permaliens → Enregistrer. Ce n’est pas la cause la plus fréquente pour l’upload pur, mais je l’ai déjà vu corriger des incohérences REST après migration.

Pièges et erreurs courantes

Symptôme	Cause probable	Vérification	Solution
“Erreur HTTP” uniquement sur images lourdes	memory_limit trop bas / timeout	debug.log → out of memory ; statut 500	Augmenter mémoire PHP + WP_MEMORY_LIMIT (Solution 1)
Échec immédiat, même sur petite image	Permissions uploads / disque plein	Test écriture sur wp-content/uploads ; quota	Réparer droits/propriétaire (Solution 2)
Statut 403 sur async-upload.php	WAF/ModSecurity / plugin sécurité	Console réseau + logs hébergeur	Désactiver/whitelister règle (Solution 3)
Statut 413	Limite Nginx/CDN	Console réseau : 413	Augmenter limite serveur ou réduire taille image
Upload OK, mais miniatures manquantes	Imagick/GD échoue au resize	debug.log ; test “forcer GD”	Forcer GD (diagnostic) + corriger Imagick serveur (Solution 1)

Erreurs de mise en œuvre que je vois tout le temps

Copier le code au mauvais endroit : mettre des define() dans functions.php au lieu de wp-config.php.
Oublier un point-virgule dans un snippet : ça provoque une erreur fatale et vous perdez l’accès à l’admin.
Tester sur production sans sauvegarde : surtout quand vous touchez à wp-config.php.
Utiliser un vieux tutoriel qui conseille chmod -R 777 : mauvais et dangereux.
Confondre action et filtre : une action exécute, un filtre retourne une valeur. Si vous “echo” dans un filtre, vous cassez parfois les réponses AJAX.
Oublier de vider les caches (plugin + CDN + navigateur) et croire que “ça ne marche pas”.
Snippet cassé par un plugin de snippets : certains plugins appliquent le code trop tard, ou le désactivent sur erreur silencieuse.

Variante / alternative

Méthode sans code (plugin)

Health Check pour isoler les conflits (le plus efficace sans toucher au code) : plugin officiel.
Query Monitor pour voir les erreurs et requêtes : plugin.

Méthode plus avancée (développeurs) : WP-CLI pour vérifier l’upload et régénérer

Si vous avez WP-CLI, vous pouvez au moins vérifier que WordPress fonctionne et que le système de fichiers est OK. Par exemple, régénérer les miniatures (si l’upload passe mais pas les tailles) avec un outil adapté. WP-CLI n’est pas livré par défaut, et la commande exacte dépend des packages/plugins disponibles sur votre serveur.

Référence WP-CLI (projet) : wp-cli/wp-cli.

Éviter ce problème à l’avenir

Redimensionnez avant upload : pour un blog, une photo de 6000px de large est rarement utile. Visez 2000–2560px max selon votre design.
Surveillez la mémoire : si vous publiez beaucoup d’images, fixez une mémoire PHP réaliste (256M est un bon point de départ, parfois 512M sur sites lourds).
Gardez un œil sur les plugins “image optimizer” : certains interceptent l’upload et peuvent casser la réponse AJAX si le serveur est lent.
Évitez les bidouilles UPLOADS : si vous externalisez les médias (S3, etc.), documentez la config et testez après mise à jour.
Ajoutez un monitoring de logs : même basique. Le message “Erreur HTTP” est trop pauvre sans logs.

Si vous gérez plusieurs sites, je recommande un mu-plugin minimal qui refuse les images démesurées (prévention). Attention : c’est un choix éditorial, pas une “solution universelle”.

Où coller le code : mu-plugin wp-content/mu-plugins/limit-image-upload-size.php.

<?php
/**
 * Plugin Name: Limit Image Upload Size (prévention)
 * Description: Refuse les images trop lourdes pour éviter des erreurs serveur lors de la génération des miniatures.
 * Version: 1.0.0
 */

defined( 'ABSPATH' ) || exit;

/**
 * Filtre sur les données du fichier uploadé avant traitement.
 */
add_filter( 'wp_handle_upload_prefilter', function( array $file ): array {
	// Limite simple : 10 Mo (à ajuster).
	$max_bytes = 10 * 1024 * 1024;

	if ( ! empty( $file['size'] ) && (int) $file['size'] > $max_bytes ) {
		$file['error'] = 'Fichier trop volumineux. Réduisez l’image (max 10 Mo) puis réessayez.';
	}

	return $file;
} );

Pourquoi ça aide : vous évitez de déclencher des traitements coûteux (resize) qui font tomber PHP en timeout/mémoire. C’est aussi plus confortable pour vos contributeurs.

Ressources

Questions fréquentes

Pourquoi WordPress affiche “Erreur HTTP” au lieu d’un vrai message ?

Parce que l’upload passe par une requête asynchrone (AJAX). Si le serveur renvoie un statut non prévu, coupe la réponse, ou renvoie une page HTML d’erreur (WAF/500), l’interface se contente parfois d’un message générique.

Est-ce que Divi 5 / Elementor / Avada peuvent causer l’erreur ?

Ils peuvent la révéler, mais la cause est presque toujours serveur (mémoire, permissions, WAF) ou un plugin qui intercepte l’upload. Testez toujours dans Médias → Ajouter pour comparer.

J’ai augmenté WP_MEMORY_LIMIT, mais ça ne change rien

WP_MEMORY_LIMIT ne peut pas dépasser memory_limit côté PHP. Si PHP est à 128M, WordPress ne pourra pas “forcer” 512M. Il faut changer la valeur côté hébergeur (ou demander au support).

Dois-je mettre les permissions en 777 sur uploads ?

Non. 777 est une mauvaise pratique de sécurité. Préférez corriger le propriétaire (chown) et utiliser 755/644. Si vous n’avez pas la main, demandez à l’hébergeur.

Comment savoir si c’est ModSecurity / un WAF ?

Le signe le plus net est un statut 403 sur la requête d’upload, souvent avec une réponse générique. Le support hébergeur peut confirmer avec l’ID de règle bloquée.

Pourquoi l’upload marche pour de petits fichiers mais pas pour des PNG ?

Les PNG peuvent être très lourds et coûteux à redimensionner. La génération des miniatures consomme plus de mémoire/CPU. Testez en JPG ou WebP, ou réduisez les dimensions avant upload.

J’ai “Il y a eu une erreur critique” après l’upload

Activez WP_DEBUG_LOG et relisez wp-content/debug.log. Vous avez probablement une erreur fatale (mémoire, extension Imagick, ou un plugin qui casse la réponse).

Est-ce que le format WebP est en cause ?

En WordPress récent, WebP est généralement bien supporté, mais la capacité à traiter WebP dépend de votre bibliothèque (GD/Imagick) et de sa compilation côté serveur. Si WebP échoue et JPG passe, suspectez une limitation de la bibliothèque d’image.

J’ai migré le site et l’upload ne marche plus

Vérifiez en priorité : propriétaire/permissions de wp-content/uploads, espace disque, et toute constante UPLOADS ou config “offload” restée de l’ancien serveur.

Le support me demande des “logs”, je donne quoi ?

Donnez : l’heure du test, l’URL touchée (/wp-admin/async-upload.php), le statut HTTP (403/413/500), la taille/type du fichier, et si possible une capture de l’onglet Réseau. C’est ce qui permet de trouver la règle WAF ou la limite serveur en quelques minutes.

Corriger l’erreur HTTP d’upload d’images WordPress

Le problème

Résumé rapide

Les symptômes

Pourquoi ça arrive

Explication simple (débutant)

Explication technique (intermédiaire/pro)

Prérequis avant de commencer

Solution 1 : Corriger les limites mémoire (PHP) et les traitements d’image (Imagick/GD)

Étape A : vérifier les limites côté WordPress

Étape B : corriger un snippet “mémoire” mal fait (AVANT / APRÈS)

AVANT (cassé / inefficace)

APRÈS (corrigé)

Étape C : traiter le cas Imagick instable (forcer GD pour tester)

Étape D : vérifier la taille réellement envoyée (413 / limites proxy)

Solution 2 : Réparer les permissions / le dossier uploads et les chemins WordPress

Étape A : diagnostic rapide (sans code)

Étape B : corriger un “mauvais chemin uploads” (AVANT / APRÈS)

AVANT (cassé)

APRÈS (corrigé)

Étape C : corriger les permissions via SSH (cas courant)

Étape D : vérifier WP_HOME / WP_SITEURL (cas “upload en boucle”)

Solution 3 : Traquer un blocage serveur (ModSecurity/WAF) ou un échec REST/AJAX

Étape A : regarder la console du navigateur (preuve rapide)

Étape B : isoler un conflit plugin/thème sans casser le site (Health Check)

Étape C : cas ModSecurity (solution côté hébergeur)

Étape D : ajouter un log ciblé sur l’upload (diagnostic, pas “solution magique”)

Vérifications après correction

Si ça ne marche toujours pas

1) Activez un debug propre (temporaire)

2) Vérifiez la réponse HTTP exacte

3) Testez sans conflit (Health Check)

4) Confirmez les extensions PHP

5) Vérifiez les limites “invisibles” côté hébergeur

6) Réinitialisez les permaliens (rare, mais rapide)

Pièges et erreurs courantes

Erreurs de mise en œuvre que je vois tout le temps

Variante / alternative

Méthode sans code (plugin)

Méthode plus avancée (développeurs) : WP-CLI pour vérifier l’upload et régénérer

Éviter ce problème à l’avenir

Ressources

Questions fréquentes

Pourquoi WordPress affiche “Erreur HTTP” au lieu d’un vrai message ?

Est-ce que Divi 5 / Elementor / Avada peuvent causer l’erreur ?

J’ai augmenté WP_MEMORY_LIMIT, mais ça ne change rien

Dois-je mettre les permissions en 777 sur uploads ?

Comment savoir si c’est ModSecurity / un WAF ?

Pourquoi l’upload marche pour de petits fichiers mais pas pour des PNG ?

J’ai “Il y a eu une erreur critique” après l’upload

Est-ce que le format WebP est en cause ?

J’ai migré le site et l’upload ne marche plus

Le support me demande des “logs”, je donne quoi ?

Articles connexes

Submit a Comment Cancel reply