Aller au contenu
Configuration

Corriger l'erreur "Allowed Memory Size Exhausted" dans WordPress

Si votre site affiche Fatal error: Allowed memory size of 268435456 bytes exhausted, ajoutez cette ligne dans wp-config.php au-dessus du / That's all, stop editing! /

Publié

Sautez la lecture — utilisez l'outil Générateur de wp-config.php Créez un wp-config.php correct sans copier-coller un article de blog de 2014

Si votre site affiche Fatal error: Allowed memory size of 268435456 bytes exhausted, ajoutez cette ligne dans wp-config.php, au-dessus du commentaire /* That's all, stop editing! */ : define( 'WP_MEMORY_LIMIT', '256M' );. Ça remet la plupart des sites en ligne en moins d’une minute. Mais lisez le reste de cette page avant de partir, car augmenter la limite est un diagnostic, pas un remède. Si le plantage revient à une valeur plus élevée, le vrai problème, c’est du code qui consomme de la mémoire sans limite, et un plafond plus haut ne fait que lui donner plus de corde pour se pendre.

Ce que l’erreur signifie vraiment

PHP suit la quantité de mémoire allouée par chaque requête. Quand une seule requête tente d’allouer au-delà du memory_limit défini dans php.ini (ou surchargé par WordPress), PHP tue la requête sur-le-champ avec une erreur critique et affiche le nombre d’octets atteint au moment du plantage. 268435456 bytes, c’est 256M. 134217728, c’est 128M. 536870912, c’est 512M. Le nombre après « tried to allocate » indique la taille de la goutte d’eau qui a fait déborder le vase, pas la taille du problème.

WordPress superpose ses propres limites à celles de PHP. WP_MEMORY_LIMIT (40M par défaut, ou la limite PHP si elle est plus élevée) régit la partie publique. WP_MAX_MEMORY_LIMIT (256M par défaut) régit les opérations côté admin comme la médiathèque et les mises à jour de plugins, qui ont légitimement besoin de plus. WordPress appelle ini_set('memory_limit', ...) au chargement en se basant sur ces constantes — mais seulement si votre hébergeur autorise ini_set, et seulement jusqu’au plafond strict qu’il impose. C’est cette dernière partie qui explique pourquoi modifier wp-config.php semble parfois ne rien changer.

Corriger le problème, dans l’ordre

1. Augmentez la limite WordPress dans wp-config.php. C’est la première chose à essayer, parce que c’est réversible et que ça ne touche à rien d’autre.

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Si vous n’êtes pas sûr de savoir où placer ces lignes, ou si vous voulez régler correctement les autres constantes courantes en même temps, notre générateur de wp-config écrit un bloc propre que vous n’avez plus qu’à coller. L’emplacement compte — tout ce qui se trouve sous la ligne « stop editing » est ignoré.

2. Si ça ne change rien, c’est votre hébergeur qui plafonne PHP. Augmentez memory_limit au niveau de PHP. Dans php.ini :

memory_limit = 256M

Sur beaucoup d’hébergements mutualisés, vous ne pouvez pas modifier php.ini directement. Essayez plutôt un fichier .user.ini à la racine de votre site, ou définissez la valeur via .htaccess sur une configuration Apache/mod_php :

php_value memory_limit 256M

Attention : php_value dans .htaccess déclenche une erreur 500 sur nginx ou sur les configurations PHP-FPM, car c’est une directive Apache/mod_php. Si vous obtenez une 500 après l’avoir ajoutée, c’est la raison — retirez-la et utilisez .user.ini.

3. Vérifiez la valeur réellement active. Ne vous fiez pas à ce que vous avez modifié ; fiez-vous à ce que PHP rapporte. Déposez un fichier d’une ligne à la racine de votre site :

<?php echo ini_get('memory_limit');

Chargez-le dans un navigateur, lisez la valeur, puis supprimez le fichier. S’il affiche toujours 128M après que vous avez mis 256M, c’est que votre hébergeur vous surcharge et vous devez le contacter ou utiliser le réglage de son panneau de contrôle.

La partie que la plupart des guides passent sous silence

Augmenter la limite, c’est du diagnostic. Voici comment en interpréter le résultat.

Si vous mettez 256M et que le site tient sous un trafic normal, c’est que vous aviez un plafond légitime, trop bas — fréquent sur les sites avec de grosses médiathèques, WooCommerce ou des page builders. Vous avez terminé.

Si vous mettez 256M et que ça plante encore, puis 512M et que ça plante encore, arrêtez d’augmenter. Une requête WordPress normale n’a pas besoin de 512M. Quand la consommation de mémoire grimpe sans plafond, c’est que quelque chose boucle ou s’accumule : un plugin qui charge une table de base de données entière dans un tableau, un add_action qui se déclenche récursivement lui-même, une routine d’import qui garde toutes les lignes en mémoire d’un coup, ou deux plugins qui se battent dans le même hook. Augmenter la limite ne corrige pas une boucle sans fin — ça ne fait que repousser le plantage de quelques secondes et le rendre plus difficile à reproduire.

Pour trouver le coupable, désactivez tous les plugins et basculez sur un thème par défaut comme Twenty Twenty-Four. Si l’erreur s’arrête, réactivez-les un par un jusqu’à ce qu’elle revienne. Activez le journal de débogage pour repérer où ça meurt :

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

La ligne d’erreur critique dans wp-content/debug.log nomme le fichier et le numéro de ligne qui a alloué le dernier bloc. C’est généralement la boucle elle-même, ou un appel de fonction à côté.

Ce qu’il ne faut pas faire

Ne mettez pas WP_MEMORY_LIMIT à -1 ou 1024M pour l’oublier ensuite. Une mémoire illimitée ne corrige pas une fuite ; elle laisse une requête emballée dévorer tout le serveur, ce qui peut faire tomber tous les autres sites de la même machine et vous valoir un appel de votre hébergeur. Un plafond est une sécurité. Gardez-en un.

Ne collez pas ini_set('memory_limit', '512M') dans functions.php comme correctif principal. Ça s’exécute trop tard pour certaines pannes — si le plantage survient pendant le chargement du cœur de WordPress, avant l’exécution du functions.php de votre thème, la ligne ne tourne jamais. wp-config.php se charge plus tôt et c’est le bon endroit.

Ne partez pas du principe que c’est un problème d’hébergement et ne montez pas votre offre. Parfois, l’hébergement est vraiment sous-dimensionné. Mais souvent, exactement le même plantage vous suit jusqu’à l’offre supérieure, parce que la cause a voyagé avec vos plugins. Écartez d’abord la boucle ; c’est gratuit.

N’augmentez pas memory_limit pour corriger une erreur max_execution_time. Ce sont des limites différentes, avec des messages différents. L’épuisement de la mémoire dit « Allowed memory size … exhausted ». Un dépassement de délai dit « Maximum execution time … exceeded ». Augmenter la mauvaise vous fait perdre une après-midi.

Toujours bloqué ?

Si vous avez confirmé que la limite active est réellement de 256M ou plus, que vous avez testé avec tous les plugins désactivés et un thème par défaut, et que la mémoire s’épuise encore, alors vous avez une vraie fuite à traquer dans le journal de débogage, pas un plafond à relever. Récupérez la ligne d’erreur critique, notez le répertoire de quel plugin elle pointe, et voilà votre rapport de bug. Réglez d’abord correctement les constantes de base de votre wp-config.php avec le générateur de wp-config, pour être sûr que les limites sont bien là où vous le croyez — puis allez lire le journal.