Erreur de mémoire épuisée dans WordPress

Ce que signifie cette erreur et comment la reconnaître

• Une erreur fatale contient un texte similaire à Allowed memory size of 134217728 bytes exhausted (tried to allocate ... bytes).
• L’ensemble du site peut être inaccessible, ou le problème peut se limiter au tableau de bord, à l’écran d’un plugin, à un import, une migration ou une action groupée.
• L’erreur peut apparaître après l’installation ou la mise à jour d’un plugin ou d’un thème, le lancement d’une opération importante sur les données, ou le transfert du site vers un hébergement avec une limite de mémoire PHP plus basse.
• La page d’accueil peut se charger normalement tandis qu’un import, un écran de page builder, une synchronisation de produits ou une autre tâche gourmande en mémoire échoue.
• Augmenter la mémoire peut sembler corriger les pages ordinaires alors que l’opération initiale continue d’échouer.

Causes principales, classées par probabilité

1. La valeur PHP memory_limit est trop faible pour le site ou la requête. Le cœur de WordPress, le thème actif, les plugins, la requête en cours et les données traitées peuvent dépasser une valeur d’hébergement prudente par défaut.
2. Un plugin ou un thème consomme beaucoup de mémoire. Les page builders, outils d’import/export, logiciels de sauvegarde, outils de mise en cache et suites SEO ou marketing complètes peuvent utiliser nettement plus de mémoire pendant certaines tâches.
3. Une opération importante traite trop de données à la fois. Les imports de médias, synchronisations de produits, migrations et opérations de recherche-remplacement peuvent dépasser la limite même lorsque le chargement normal des pages fonctionne.
4. L’ensemble des plugins actifs présente une consommation de base élevée. Plusieurs consommateurs modérés peuvent dépasser la limite lorsqu’ils sont utilisés simultanément.
5. Les différentes couches de configuration ne concordent pas. wp-config.php, le panneau d’hébergement, php.ini, .user.ini et les paramètres applicables de .htaccess peuvent produire des valeurs effectives différentes pour les requêtes web.
6. Un composant suit un chemin de traitement inefficace ou présente une fuite mémoire. Cette possibilité devient plus probable lorsqu’une action précise échoue avec une charge modeste ou après des utilisations répétées, plutôt que seulement pendant une opération prévisiblement volumineuse.

Comment corriger le problème

1. Identifiez la requête qui échoue

Copiez le message complet de l’erreur fatale s’il est disponible. Notez si l’échec concerne toutes les pages, uniquement le tableau de bord, l’écran d’un plugin ou une opération particulière comme un import ou une modification groupée. Cette distinction permet de différencier une limite généralement trop basse d’un problème propre à une charge de travail.

2. Demandez davantage de mémoire à WordPress

Avant de modifier des fichiers, effectuez une sauvegarde ou vérifiez que vous pouvez restaurer la configuration actuelle. Avec SFTP ou le gestionnaire de fichiers de votre hébergeur, ouvrez wp-config.php et ajoutez cette ligne au-dessus de /* That's all, stop editing! */ :

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

Cela demande à WordPress d’utiliser 256 Mo lorsque le serveur l’autorise. Si la constante existe déjà, modifiez cette définition au lieu d’en ajouter une seconde. Certaines tâches d’administration peuvent utiliser un paramètre de mémoire distinct ; un échec limité au tableau de bord peut donc nécessiter une analyse complémentaire.

3. Vérifiez la limite PHP utilisée par le site

WP_MEMORY_LIMIT ne peut pas augmenter la mémoire PHP au-delà de la valeur memory_limit définie par le serveur. Consultez le panneau de contrôle de l’hébergement ou le php.ini utilisé par la version de PHP qui sert le site. Sur un VPS, la modification de la configuration PHP concernée peut nécessiter le redémarrage de PHP-FPM ou du service PHP applicable ; ne le faites qu’avec les accès et autorisations nécessaires.

Certaines configurations Apache utilisant mod_php permettent un paramètre tel que :

php_value memory_limit 256M

dans .htaccess. Cela ne s’applique pas à PHP-FPM et peut provoquer une erreur de configuration du serveur lorsque la directive n’est pas autorisée. Utilisez le panneau d’hébergement ou demandez conseil à l’hébergeur avant de l’ajouter. Un paramètre PHP exécuté en ligne de commande peut différer de la configuration utilisée par les requêtes web.

4. Répétez exactement l’action qui échoue

Relancez l’import, la modification groupée, l’opération du plugin ou la requête de page qui a produit l’erreur. Charger uniquement la page d’accueil ne suffit pas, car une page ordinaire peut utiliser beaucoup moins de mémoire que la tâche en échec. Si la tâche réussit, surveillez-la et n’augmentez pas davantage la limite, sauf si cette même opération nécessite encore plus de mémoire.

5. Réduisez l’utilisation maximale de mémoire de l’opération

Pour les imports, migrations, synchronisations ou modifications groupées, réduisez la taille des lots définie dans l’outil ou divisez le travail en groupes plus petits. C’est souvent plus sûr que d’attribuer une limite très élevée à chaque requête PHP. Exécuter les tâches importantes pendant une période plus calme peut réduire le risque opérationnel, mais cela ne diminue pas la quantité maximale de mémoire requise par la requête.

6. Isolez le plugin ou le thème probablement responsable

Si 256M ou 512M reste insuffisant, ou si le problème a commencé après une modification, testez le composant associé à l’écran ou à la tâche en échec. Utilisez une copie de staging lorsque c’est possible. Sur un site en production, effectuez d’abord une sauvegarde et désactivez les plugins un par un. Si le tableau de bord est inaccessible, utilisez SFTP ou le gestionnaire de fichiers pour renommer temporairement le répertoire du plugin suspect afin que WordPress ne puisse pas le charger.

Commencez par le composant récemment modifié et le plugin lié à l’échec, puis testez les page builders, outils d’import/export, outils de sauvegarde, outils de mise en cache et grandes suites tout-en-un. Si les pages publiques échouent, testez également avec un thème par défaut. Réactivez les composants non concernés après chaque test afin de savoir quelle configuration a été testée.

7. Comparez les valeurs de configuration effectives

Si la modification de WP_MEMORY_LIMIT n’a aucun effet visible, comparez la requête WordPress avec la valeur PHP utilisée par les requêtes web. Examinez le panneau d’hébergement, php.ini, .user.ini et les paramètres applicables de .htaccess, ainsi que tout plafond imposé par l’hébergeur. Demandez à l’hébergeur quelle configuration PHP s’applique si vous ne pouvez pas le vérifier vous-même.

8. Confirmez la correction durable

Exécutez à nouveau l’opération initialement en échec, puis vérifiez les pages publiques et administratives importantes. Si le site ne fonctionne qu’après la définition d’une limite très élevée, considérez cela comme un indice de diagnostic et poursuivez l’analyse du plugin, du thème, de la requête ou de la taille des lots responsables au lieu de considérer le problème comme définitivement résolu.

Prévention et vérification du correctif

• Définissez une valeur de mémoire WordPress réfléchie et prise en charge par l’hébergeur au lieu d’attendre l’échec d’une tâche en production.
• Supprimez les plugins inutilisés et examinez régulièrement l’ensemble des plugins actifs, car leur consommation de base est cumulative.
• Maintenez les lots d’import, de migration, de synchronisation et de modification groupée dans les limites de la mémoire PHP disponible.
• Testez les opérations importantes sur staging ou avec un jeu de données limité avant de traiter l’intégralité du site.
• Après une modification de plugin ou de configuration, répétez l’opération qui avait échoué et vérifiez les pages publiques et d’administration.
• Notez quelle configuration PHP s’applique aux requêtes web afin d’effectuer les futures modifications de mémoire au bon endroit.

Questions fréquentes