Le message est toujours le même : « Le fichier dépasse la taille maximale pour les téléversements ». Ce qui change, c’est la cause. J’ai vu ce message bloquer un import de 8 Mo sur un serveur configuré pour accepter 64 Mo, simplement parce qu’un des quatre réglages en jeu n’avait pas été touché.
Ce mode debug part du symptôme le plus visible — le message dans WordPress — pour remonter jusqu’au réglage serveur qui bloque réellement, sans deviner.
Symptôme : le message WordPress
Dans la médiathèque, WordPress affiche sous le bouton d’import la taille maximale qu’il a détectée, calculée par la fonction wp_max_upload_size(). C’est le point de départ du diagnostic : cette valeur est le minimum entre upload_max_filesize et post_max_size côté PHP.
<?php
// À placer temporairement dans un fichier accessible, jamais en production ouverte
echo size_format( wp_max_upload_size() );
Diagnostic : quatre suspects, un seul coupable
Chaque réglage agit à un niveau différent de la chaîne, et le plus restrictif des quatre l’emporte toujours.
1. upload_max_filesize (php.ini)
Contrôle la taille d’un seul fichier téléversé par PHP. Une valeur de 2M alors que le thème attend des images de 5 Mo bloque systématiquement, quel que soit le réglage WordPress.
2. post_max_size (php.ini)
Limite la taille totale de la requête POST, fichier et champs de formulaire compris. Elle doit toujours être supérieure ou égale à upload_max_filesize : si elle est plus basse, elle prend le dessus silencieusement.

3. client_max_body_size (Nginx)
Sur un serveur Nginx en frontal de PHP-FPM, cette directive coupe la requête avant même qu’elle n’atteigne PHP. Le symptôme change alors : on obtient souvent une erreur 413 « Request Entity Too Large » plutôt que le message WordPress, ce qui est un bon indice pour orienter le diagnostic.
4. La limite définie par WordPress lui-même
Certains hébergements mutualisés ou certaines extensions ajoutent un filtre sur upload_size_limit ou une contrainte via wp_handle_upload_prefilter. Un grep -r "upload_size_limit" wp-content/ permet de vérifier si un plugin impose sa propre limite.
Correctif : ajuster dans le bon ordre
Je procède toujours du plus bas niveau vers le plus haut, pour ne pas modifier un réglage inutile.
- Vérifier la valeur réelle avec
phpinfo()ouphp -i | grep max_filesizeen ligne de commande. - Modifier
php.inisi l’accès est possible, ou le.user.inisur un hébergement mutualisé :upload_max_filesize = 64M post_max_size = 64M memory_limit = 256M - Sur Nginx, augmenter la directive dans le bloc
serveroulocation:client_max_body_size 64M; - Redémarrer PHP-FPM et recharger Nginx : une modification de
.inisans redémarrage du pool reste sans effet.
Sur un hébergement mutualisé sans accès à php.ini, la seule solution propre reste souvent de placer ces directives dans un fichier .user.ini à la racine, pris en compte par PHP-FPM après quelques minutes (le temps du cache de configuration).
Prévention
Pour éviter de refaire ce diagnostic à chaque projet, j’ajoute un contrôle dans le tableau de bord d’administration qui affiche la valeur calculée par wp_max_upload_size(), avec une alerte si elle descend sous un seuil défini par le projet.
add_action( 'admin_notices', function () {
if ( wp_max_upload_size() < 20 * MB_IN_BYTES && current_user_can( 'manage_options' ) ) {
echo '<div class="notice notice-warning"><p>';
esc_html_e( 'La taille maximale d’upload est basse, vérifiez la configuration serveur.', 'mon-theme' );
echo '</p></div>';
}
} );
Un message d’erreur générique cache presque toujours un réglage précis. Le bon réflexe n’est pas d’augmenter tout au hasard, mais de mesurer la valeur réelle avant de la corriger.
En résumé
Quatre réglages, quatre niveaux de la chaîne de traitement : PHP limite le fichier, PHP limite la requête, Nginx limite le corps de la requête, et parfois WordPress ou une extension ajoute sa propre contrainte. Le diagnostic va toujours plus vite en mesurant la valeur réelle avec wp_max_upload_size() plutôt qu’en modifiant les fichiers de configuration à l’aveugle.