WP_MEMORY_LIMIT ou memory_limit PHP : lequel arbitre en cas de fatal error

Fatal error: Allowed memory size of 268435456 bytes exhausted. Ce message persiste malgré une constante WP_MEMORY_LIMIT relevée à 512M dans wp-config.php, ce qui laisse penser à une configuration ignorée ou à un cache non vidé. En réalité, le chiffre affiché dans le message d’erreur, 268 435 456 octets, correspond très précisément à 256 Mo : c’est la limite réellement appliquée par PHP lui-même, indépendamment de ce que WordPress demande.

Deux réglages qui ne vivent pas au même niveau

memory_limit est un réglage de PHP, défini dans php.ini ou dans la configuration du pool PHP-FPM, qui impose un plafond dur à tout script PHP exécuté sur le serveur, quel que soit le logiciel qui tourne dessus. WP_MEMORY_LIMIT, à l’inverse, est une constante propre à WordPress, qui ne fait qu’appeler la fonction native ini_set( 'memory_limit', ... ) en coulisses.

// wp-includes/default-constants.php (comportement simplifié)
if ( function_exists( 'ini_set' ) ) {
    ini_set( 'memory_limit', WP_MEMORY_LIMIT );
}

La règle qui explique tout : ini_set ne peut jamais dépasser un plafond serveur

La fonction ini_set() permet d’augmenter memory_limit à l’exécution, mais uniquement si la configuration du serveur l’autorise. Certains hébergeurs mutualisés verrouillent ce réglage au niveau du pool PHP-FPM avec la directive php_admin_value, qui rend tout appel ultérieur à ini_set() totalement sans effet :

; dans le pool PHP-FPM
php_admin_value[memory_limit] = 256M

Quand cette directive est présente, relever WP_MEMORY_LIMIT à n’importe quelle valeur dans wp-config.php ne change strictement rien : le plafond serveur reste absolu et prioritaire.

Diagnostiquer la vraie limite appliquée

Le moyen le plus fiable de savoir quelle limite est réellement active consiste à l’interroger directement depuis WordPress, plutôt que de se fier à ce qui est écrit dans les fichiers de configuration :

wp eval 'echo ini_get( "memory_limit" );'

Si la valeur retournée ne correspond pas à celle attendue dans wp-config.php, la cause se trouve presque toujours dans la configuration du pool PHP-FPM, accessible uniquement avec un accès serveur, ou dans une limite imposée globalement par l’hébergeur sur les offres mutualisées.

WP_MAX_MEMORY_LIMIT : la deuxième constante souvent oubliée

WordPress distingue en réalité deux constantes : WP_MEMORY_LIMIT, appliquée au chargement normal du site, et WP_MAX_MEMORY_LIMIT, appliquée uniquement dans l’administration et lors des tâches lourdes comme les mises à jour d’extensions. Oublier la seconde explique pourquoi une page classique fonctionne alors qu’une mise à jour groupée échoue toujours :

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

Ce qu’il faut vérifier dans l’ordre

• La valeur réellement active via ini_get( 'memory_limit' ), pas la constante déclarée ;
• La présence éventuelle d’un php_admin_value verrouillé dans le pool PHP-FPM du serveur ;
• La distinction entre WP_MEMORY_LIMIT et WP_MAX_MEMORY_LIMIT selon le contexte de l’erreur ;
• Le rôle de l’extension elle-même : une fuite mémoire réelle dans le code ne se résout jamais en augmentant simplement les limites.

Un réflexe qui fait gagner du temps sur ce diagnostic précis : toujours lire le chiffre exact du message d’erreur en octets, le convertir en mégaoctets, et le comparer à la valeur attendue avant de modifier quoi que ce soit.

Quand augmenter la limite ne fait que masquer le problème

Relever indéfiniment memory_limit face à une erreur récurrente traite le symptôme, jamais la cause. Une fuite mémoire dans une boucle mal écrite, par exemple une requête qui charge tous les articles d’un site volumineux en une seule fois via get_posts() sans limite explicite, continuera de consommer toujours plus de mémoire à mesure que le contenu du site grandit, quelle que soit la limite fixée :

// à éviter sur un site volumineux
$articles = get_posts( array( 'numberposts' => -1 ) );

// préférable : traiter par lots
$articles = get_posts( array( 'numberposts' => 200, 'offset' => $decalage ) );

Le cas particulier des tâches WP-CLI en ligne de commande

Une commande WP-CLI exécutée en SSH ne suit pas toujours la même configuration memory_limit que les requêtes web servies par PHP-FPM, car elle peut utiliser un binaire PHP en ligne de commande configuré séparément. Il est donc possible qu’un import fonctionne sans erreur en SSH alors que la même opération échoue depuis l’interface d’administration, un écart qui surprend souvent la première fois qu’il est observé.

En résumé

memory_limit défini côté serveur prime toujours sur WP_MEMORY_LIMIT défini côté WordPress, jamais l’inverse. Une erreur fatale de mémoire qui persiste malgré une constante relevée signale presque systématiquement un plafond imposé plus bas dans la pile, au niveau du pool PHP-FPM, que seul un accès serveur permet de corriger.