Aller au contenu
Configuration

Augmenter la taille maximale des fichiers uploadés dans WordPress

Trois réglages contrôlent votre limite d'upload WordPress, et ils doivent tous être cohérents entre eux. La limite effective est la plus petite valeur entre upload_max_filesize, post_max_size,

Publié

Sautez la lecture — utilisez l'outil Correcteur de taille de téléversement maximale Augmentez la limite de téléversement — et rendez les trois valeurs cohérentes

Trois réglages contrôlent votre limite d’upload WordPress, et ils doivent tous être cohérents entre eux. La limite effective est la plus petite valeur entre upload_max_filesize, post_max_size et le plafond de requête de votre serveur web. Augmentez l’un des trois en laissant les deux autres bas, et rien ne change — c’est exactement pour ça que la plupart des gens concluent que leur correctif « n’a pas marché ». Vérifiez d’abord vos valeurs actuelles avec l’outil de taille maximale d’upload WordPress ; il lit les mêmes valeurs que celles remontées par WordPress et vous montre laquelle vous bloque.

Pourquoi cette limite existe et où elle se trouve

WordPress ne fixe pas la limite d’upload. Il ne fait que la remonter. Quand vous voyez « The uploaded file exceeds the upload_max_filesize directive in php.ini », ce message vient directement de PHP.

Trois valeurs distinctes conditionnent un upload, et le vrai plafond correspond à la plus basse des trois :

  • upload_max_filesize (PHP) — le plus gros fichier unique que PHP acceptera.
  • post_max_size (PHP) — le plus gros corps de requête POST au total. Votre fichier voyage à l’intérieur de la requête POST avec les autres champs du formulaire, donc cette valeur doit être supérieure à upload_max_filesize.
  • La limite de corps de requête du serveur web — client_max_body_size sur Nginx, ou LimitRequestBody sur Apache. Celle-ci vit entièrement en dehors de PHP, et c’est pourquoi les correctifs purement PHP échouent silencieusement derrière Nginx.

Une quatrième valeur, max_execution_time, ne limite pas la taille mais interrompra un upload volumineux et lent en pleine transmission sur une mauvaise connexion. C’est un symptôme à part, pas un élément du plafond de taille.

Le piège : vous réglez upload_max_filesize = 256M, vous rechargez, et vous ne pouvez toujours pas uploader un fichier de 100 Mo — parce que post_max_size est encore à 8M. PHP rejette la requête sur le corps total avant même d’inspecter le fichier. La limite ne vous a pas ignoré. Une autre limite l’a intercepté en premier.

Comment corriger le problème, dans l’ordre

Procédez de la solution la plus susceptible de tenir jusqu’au dernier recours.

1. Modifiez php.ini (le bon endroit). Trouvez le fichier que votre site charge réellement — exécutez une page contenant <?php phpinfo(); et lisez « Loaded Configuration File », ou demandez à votre hébergeur. Réglez les deux valeurs PHP, et gardez post_max_size plus grand que upload_max_filesize :

upload_max_filesize = 256M
post_max_size = 260M
max_execution_time = 300

Redémarrez PHP-FPM (sudo systemctl restart php8.2-fpm) ou Apache. Les changements n’ont aucun effet tant que le processus PHP n’a pas redémarré.

2. Pas d’accès à php.ini ? Utilisez .htaccess (Apache + mod_php uniquement). Ajoutez ceci au .htaccess situé à la racine de votre WordPress :

php_value upload_max_filesize 256M
php_value post_max_size 260M
php_value max_execution_time 300

Cela ne fonctionne que lorsque PHP tourne en tant que module Apache. Sous PHP-FPM, CGI ou FastCGI, php_value déclenche une erreur 500 — cet échec signifie que vous êtes sur la mauvaise piste, pas que la valeur est mauvaise. Passez alors à .user.ini :

upload_max_filesize = 256M
post_max_size = 260M

3. Augmentez la limite du serveur web — l’étape que tout le monde oublie. Sur Nginx, PHP ne voit même jamais une requête trop grosse ; Nginx renvoie 413 Request Entity Too Large en premier. Dans votre bloc serveur :

client_max_body_size 256M;

Rechargez avec sudo nginx -t && sudo systemctl reload nginx. Si vous êtes sous Nginx et que vos modifications PHP « n’ont rien changé », c’est presque toujours la raison.

Après chaque changement, revérifiez les valeurs remontées. L’outil de taille maximale d’upload vous indiquera le nouveau plafond effectif et générera le bon extrait de configuration pour votre setup, pour que vous n’ayez pas à deviner laquelle des trois valeurs est encore trop basse.

Ce qu’il ne faut pas faire

Ne modifiez pas wp-config.php en espérant que ça relève la limite. La ligne massivement recopiée ne fait pas ce que les articles de blog prétendent :

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

upload_max_filesize est de type PHP_INI_PERDIR. Elle ne peut pas être modifiée depuis PHP à l’exécution avec ini_set(). Elle n’accepte de nouvelles valeurs que depuis php.ini, .htaccess ou .user.ini — jamais depuis le code applicatif. La ligne s’exécute sans erreur et ne fait rien, ce qui en fait l’un des conseils erronés les plus répétés avec assurance dans le monde WordPress.

Ne collez pas non plus @ini_set('post_max_size', ...) — même restriction, même absence d’effet silencieuse.

Ne réglez pas WP_MEMORY_LIMIT en pensant que c’est la limite d’upload. Cela contrôle le plafond mémoire de PHP pour l’exécution du code. Ça n’a aucun rapport avec la taille de fichier que le serveur accepte.

Ne vous arrêtez pas à un seul fichier. L’échec le plus courant, de loin, consiste à changer upload_max_filesize tout seul puis à déclarer que le correctif ne marche pas. Changez les trois valeurs, et gardez post_max_size au-dessus de upload_max_filesize.

Ne fixez pas des limites absurdement hautes « par sécurité ». Une limite de 2 Go invite les problèmes d’épuisement des ressources et n’aide en rien — si vous avez réellement besoin de fichiers de plusieurs gigaoctets, uploadez-les en dehors du navigateur (SFTP, ou un plugin d’upload par morceaux) plutôt que de les forcer à passer par une seule requête POST PHP.

Toujours bloqué ?

Si les trois valeurs sont relevées et que vous butez encore sur un mur, la requête est plafonnée quelque part en amont de votre serveur : un CDN ou un proxy (le tableau de bord de Cloudflare plafonne la taille du corps d’upload de son côté), une limite de plateforme d’un hébergeur infogéré qui ignore votre php.ini, ou un .user.ini qui ne s’est pas encore rafraîchi — il respecte le user_ini.cache_ttl de PHP, donc il peut avoir quelques minutes de retard après votre enregistrement. Confirmez ce que le serveur remonte réellement, pas ce que vous avez écrit dans un fichier, et corrigez la couche qui est encore trop basse. Quand la valeur remontée finit par correspondre à votre cible, l’upload fonctionne.