Mémoire PHP épuisée dans WordPress : corriger l’action qui échoue

Confirmer une erreur de mémoire pendant la bonne action

Vous lancez un import, un export ou une modification précise, puis WordPress affiche une erreur contenant « Allowed memory size » et « exhausted ». Le journal peut donner le même message alors que l’écran montre seulement une erreur critique ou un statut 500. Le traitement a atteint une limite de mémoire ; augmenter n’importe quel nombre dans WordPress ne suffit pas à expliquer pourquoi.

Le but est de terminer l’action utile avec des données intactes et une consommation maîtrisée. Trois voies existent selon le diagnostic : réduire le travail demandé, corriger un composant qui consomme anormalement ou ajuster la limite réellement appliquée par l’hébergement.

Un écran lent ou une page 500 ne prouve pas un épuisement de mémoire. Relevez le message correspondant à l’heure de l’action dans les journaux privés. Si le site entier est devenu inaccessible, utilisez d’abord le guide d’erreur critique pour récupérer l’accès, puis reprenez ici le traitement en cause.

Préserver l’original et vérifier ce qui a déjà été fait

Arrêtez les répétitions automatiques. Un import peut avoir créé une partie des éléments avant son arrêt ; une mise à jour peut avoir modifié des fichiers. Conservez le fichier d’origine, les paramètres de l’action et son compte rendu. Ne supprimez pas les éléments partiels sans vérifier leur usage et la méthode de reprise prévue par l’outil.

Si du texte non enregistré reste visible, copiez-le dans un document privé. Pour un traitement commercial ou un envoi, faites contrôler son état avant toute relance afin d’éviter les doublons. Le message de mémoire ne garantit pas une annulation de tous les effets déjà produits.

Vérifiez les sauvegardes disponibles, leur date et leur périmètre. La base et les fichiers sont distincts ; leur restauration peut remplacer des données récentes. Une sauvegarde de configuration privée facilite un retour sur un réglage sans revenir sur tout le site.

Notez l’heure avec le fuseau, l’action, son volume et le dernier fonctionnement connu. Ces éléments permettront de comparer deux essais équivalents plutôt que de changer en même temps la taille, le composant et les limites.

Distinguer mémoire, taille d’envoi et espace de stockage

Le poids d’un fichier sur votre ordinateur ne représente pas toute la mémoire nécessaire à son traitement. Une image compressée doit être décodée ; des données importées peuvent être transformées en nombreux objets. Un fichier relativement petit peut donc demander beaucoup de mémoire pendant une étape particulière.

La limite d’envoi contrôle ce que la requête peut transporter. L’espace disque indique ce que le compte peut stocker. La limite de mémoire PHP concerne ce qu’un script peut allouer pendant son exécution. Modifier upload_max_filesize n’accorde pas davantage de mémoire au traitement déjà reçu.

Distinguez aussi cette limite de la capacité totale du serveur. Plusieurs demandes peuvent consommer en parallèle. Un message de limite PHP et un processus arrêté par le système ne fournissent pas le même diagnostic ; l’hébergeur peut devoir examiner plusieurs journaux.

Si le message porte sur un fichier trop volumineux, une écriture refusée ou un délai dépassé, choisissez le guide correspondant. Ne traitez pas chaque échec d’import ou d’image comme une preuve qu’il faut augmenter la mémoire.

Relever la limite et le contexte qui échouent

Consultez les journaux privés du site à l’heure exacte de l’incident. Conservez le message de mémoire, la quantité annoncée et le chemin du fichier. La ligne où l’allocation échoue peut être le dernier consommateur, sans être l’origine de toute la consommation. Ne supprimez pas ce fichier sur la seule base de son nom.

Dans l’administration accessible, ouvrez Outils, Santé du site, puis Informations. Relevez la version PHP et les limites visibles dans les rubriques du serveur. Elles décrivent le contexte consulté ; un export par terminal ou une tâche planifiée peut utiliser une autre configuration.

Précisez donc où l’action s’exécute : navigateur, tâche de fond ou commande technique déjà utilisée. Le support peut vérifier la limite effective dans ce contexte. Ne créez pas une page publique phpinfo() et ne partagez pas toute la configuration pour obtenir cette information.

Sur une installation gérée par un tiers, demandez-lui ces relevés. Votre rôle WordPress ne fournit pas automatiquement les droits de modifier PHP. Les accès doivent rester ceux des personnes autorisées.

Sur des versions PHP récentes, un arrêt Hard memory limit peut interrompre immédiatement le processus sans passer par le journal PHP habituel. Si aucune ligne n’apparaît malgré un arrêt reproductible, demandez le journal du processus ou du serveur au même horaire ; l’absence de debug.log ne prouve pas que la mémoire est suffisante.

Choisir la réduction, la correction ou l’ajustement

La première approche réduit le travail utile lorsque l’opération porte sur un volume important : images immenses, export trop large ou import que l’outil sait découper. Elle permet parfois de terminer sans changer le serveur, tout en gardant l’original.

La deuxième recherche une régression : une action de taille habituelle échoue depuis une modification, ou un élément précis déclenche une consommation anormale. Elle nécessite une comparaison contrôlée et, pour les changements de composants, une copie protégée.

La troisième ajuste la limite effective lorsqu’un besoin légitime et proportionné dépasse ce qui est accordé. Elle suppose l’accord de l’hébergeur sur la capacité et la méthode, puis une vérification de la valeur chargée.

Ces trois approches ne sont pas des réglages à cumuler. Commencez par l’indice le mieux établi et gardez un point de comparaison stable. Si réduire le volume change aussi le format et le composant utilisé, vous ne saurez pas quelle différence a compté.

Approche 1 : alléger ce que le traitement doit préparer

Pour une image, conservez l’original et préparez une copie aux dimensions adaptées à son usage. Réduire les pixels peut diminuer le travail de décodage et de transformation. Modifier uniquement le nom de fichier ou son extension ne change pas cette charge. Le guide de traitement des images détaille la préparation et les contrôles visuels.

Pour un export natif d’articles, Outils → Exporter permet de limiter le contenu par type, auteur, catégorie, dates et statut selon les filtres proposés. Un export portant sur une seule période réduit le travail, mais conserve uniquement ce périmètre. Le fichier XML ne constitue pas une sauvegarde complète : les fichiers médias ne sont pas empaquetés avec le texte. Pour un autre outil d’export, utilisez uniquement ses filtres documentés.

Pour un import, cherchez la fonction de traitement par lots prévue par l’éditeur. Les réglages peuvent dépendre de la version et du type de données. Ne découpez pas arbitrairement une archive de migration ou un document structuré en plusieurs fichiers : son format peut exiger un ensemble cohérent.

Testez une copie représentative et notez son volume. Si elle réussit, vous obtenez un indice de charge et une méthode possible ; cela ne prouve pas que tout le site dispose désormais de suffisamment de mémoire. Pour les données importées, utilisez uniquement une annulation ciblée et documentée des éléments réellement créés.

1. Si l’export natif est l’action en échec, ouvrez Outils → Exporter et sélectionnez Articles.
2. Relevez les filtres initiaux, puis choisissez une courte plage de dates contenant des articles connus et le statut utile.
3. Cliquez sur Télécharger le fichier d’export ; gardez ce fichier sous un nom indiquant sa période. Comparez les titres attendus avec son contenu dans un éditeur de texte local.
4. Si l’export reste en erreur ou incomplet, conservez le compte rendu. Rétablissez les filtres initiaux avant un autre essai ; ne concaténez pas plusieurs XML pour fabriquer un export global.

Fractionner uniquement avec une reprise maîtrisée

Avant de traiter plusieurs lots, vérifiez comment l’outil reconnaît les éléments déjà présents. Il peut créer un doublon, mettre à jour une entrée ou reprendre à partir d’un point enregistré. Ces comportements ne sont pas interchangeables. Consultez la documentation de la version utilisée et gardez l’identifiant du premier lot.

Commencez avec un petit ensemble représentatif, sur une copie lorsque l’import modifie des données importantes. Contrôlez le nombre d’éléments, leurs relations et les pièces associées. Une importation qui termine sans message mais oublie des images ou des associations n’est pas une réussite complète.

Préservez la distinction entre données de test et production. Un import de commandes, d’utilisateurs ou de notifications demande la neutralisation des effets externes sur la copie. Ne reprenez pas un lot interrompu en production avant d’avoir identifié ce qui est déjà enregistré.

Si le premier petit lot échoue avec le même message mémoire, cessez de réduire au hasard. L’opération de départ ou un élément particulier peut déjà provoquer une consommation excessive. Passez à l’analyse du composant avec ce cas réduit et les observations conservées.

Approche 2 : comparer une régression sur une copie

Une action jusque-là banale peut devenir défaillante après une mise à jour, un changement de PHP ou un nouveau réglage. Reconstituez les versions et l’ordre des interventions. La chronologie aide à préparer une comparaison, sans prouver que la dernière extension installée est responsable.

Utilisez une copie récente avec ses propres fichiers, sa propre base, un accès protégé et des effets externes neutralisés avant démarrage. Vérifiez qu’elle reproduit les versions et la limite utiles au diagnostic. Une copie avec beaucoup plus de mémoire que la production peut faire disparaître le symptôme sans montrer sa cause. Un alias de domaine utilisant les données actives n’est pas une copie de test.

Sur cette copie, ouvrez Extensions, puis Extensions installées. Relevez l’état du composant suspect et désactivez uniquement cette extension si elle n’est pas indispensable à l’action testée. Reproduisez le même cas réduit, conservez le résultat, puis réactivez-la avant de passer à une autre. Si la copie ne réalise plus la même opération sans elle, la comparaison n’est pas probante : restaurez son état et recherchez un réglage ou un correctif propre au composant.

Si une correction de l’éditeur existe, vérifiez-la dans ce contexte. Un retour de version doit rester compatible avec les données et les évolutions de structure ; ne remplacez pas les fichiers d’une extension au hasard.

Mesurer une page encore accessible avec Query Monitor

Query Monitor, de John Blackbourn, apporte un relevé supplémentaire sur une copie qui peut encore afficher ses pages. Cette extension gratuite n’augmente pas la mémoire. La version 4.1.1 vérifiée le 3 novembre 2026 demande WordPress 6.3 et PHP 7.4 au minimum, avec un test déclaré jusqu’à WordPress 7.1.4 ; utilisez une version de PHP maintenue par l’hébergeur. Par défaut, ses résultats sont visibles aux administrateurs, ou aux super-administrateurs d’un multisite.

Le pic mémoire affiché correspond au chargement courant. Il ne constitue pas un historique, ni une répartition exacte de la mémoire entre extensions. Le panneau de requêtes peut regrouper le SQL par composant, mais le temps SQL ne mesure pas toute la consommation PHP. Un traitement Ajax, REST ou de fond distinct ne se résume pas au pic de la page qui l’a déclenché.

L’outil consomme lui-même des ressources, notamment s’il recueille beaucoup de requêtes. S’il aggrave l’erreur, désactivez-le et revenez aux journaux existants. Un arrêt brutal peut empêcher ses panneaux d’apparaître. N’installez pas un second outil de mesure pour compenser cette absence ; fournissez alors le cas réduit au mainteneur.

1. Sur la copie protégée, ouvrez Extensions → Ajouter une extension, recherchez Query Monitor et confirmez John Blackbourn comme auteur. Installez et activez avec un accès aux fichiers disponible pour annuler.
2. Connecté comme administrateur, chargez une page représentative qui fonctionne encore. Dans la barre d’administration, le menu chiffré affiche notamment le pic mémoire ; cliquez dessus pour ouvrir Overview, ou Vue d’ensemble selon la traduction.
3. Notez l’adresse, le volume traité et ce pic. Dans Environment, ou Environnement, relevez la limite PHP et sa version. Gardez ces informations techniques privées.
4. Refaites le même chargement après une seule correction sur la copie. Si l’opération étudiée s’exécute dans une autre requête, demandez au mainteneur de relever cette requête séparément ; ne concluez pas à partir du seul écran initial.
5. Après le relevé, désactivez Query Monitor dans Extensions installées et contrôlez le même cas sans cette instrumentation. Si son activation bloque l’administration, renommez seulement son dossier query-monitor dans wp-content/plugins via votre accès aux fichiers, puis rétablissez son nom une fois l’accès récupéré sans le réactiver.

Transmettre au mainteneur un cas exploitable

Réduisez l’exemple aux données nécessaires tout en conservant le problème, lorsque c’est possible. Donnez le volume, le format, les versions, la limite effective et l’erreur correspondant au même essai. Un fichier client complet n’est pas à envoyer publiquement si un exemple nettoyé suffit.

Le mainteneur doit distinguer le traitement attendu d’un chargement disproportionné, d’une répétition ou d’un conflit. Un nom de fichier du cœur dans le journal ne signifie pas automatiquement que le cœur est défectueux. Une fonction peut échouer sur l’allocation finale après une accumulation initiée ailleurs.

Approche 3 : ajuster la limite depuis l’hébergement

Demandez au prestataire si une hausse proportionnée est autorisée pour le domaine et compatible avec les ressources. Donnez l’action, son volume et la limite constatée. Le nombre proposé doit répondre au besoin démontré, pas à une valeur présentée comme idéale pour tous les sites.

Avec cPanel, si l’outil est disponible, ouvrez Logiciel → MultiPHP INI Editor, puis Basic Mode. Sélectionnez le domaine concerné, plutôt que Home Directory qui peut viser tous les sites du compte. Avant Apply, conservez les valeurs initiales et une copie privée des fichiers de configuration concernés. Le panneau peut écrire dans php.ini, .user.ini et .htaccess selon la directive ; ne remplacez aucun de ces fichiers en bloc.

1. Dans Basic Mode, confirmez le domaine et notez memory_limit ainsi que l’heure du relevé.
2. Modifiez uniquement memory_limit avec la valeur autorisée par le prestataire, puis cliquez sur Apply.
3. Revenez dans Outils → Santé du site → Informations → Serveur pour le contexte Web. Pour une tâche de fond ou une commande, faites vérifier séparément sa configuration chargée.
4. Refaites seulement le cas prévu, après contrôle des écritures déjà réalisées. Si la valeur ne change pas, n’ajoutez pas une seconde configuration au hasard.
5. Pour annuler, remettez la valeur relevée dans le même champ et appliquez. Vérifiez ensuite la valeur effective ; conservez les autres réglages.

Adapter wp-config.php seulement si cette méthode est prévue

WordPress utilise notamment WP_MEMORY_LIMIT et WP_MAX_MEMORY_LIMIT. La première intervient pendant son initialisation ; la seconde sert aux demandes de hausse de certains traitements, notamment d’administration, d’images et de tâches. Elles ne réservent pas de RAM et ne permettent pas de dépasser un plafond imposé par l’hébergement.

Cette variante concerne l’autohébergement où le prestataire confirme que WordPress peut augmenter memory_limit à l’exécution. Utilisez son panneau si c’est la méthode prévue. L’extrait ci-dessous illustre un accord explicite pour 256M dans les deux contextes, avec une valeur effective actuellement inférieure. Ce nombre n’est pas une recommandation universelle. S’il est déjà atteint ou dépassé, recopier cet exemple ne résoudra pas l’incident.

L’initialisation de WordPress ne ramène pas une limite PHP déjà supérieure vers une valeur plus basse simplement parce que WP_MEMORY_LIMIT est plus petit. WP_MAX_MEMORY_LIMIT peut aussi être modifié par des filtres. Contrôlez donc la valeur effective du traitement après le changement, et pas seulement les constantes écrites dans le fichier. Gardez à l’esprit que plusieurs demandes simultanées restent à la charge du même hébergement.

1. Par SFTP ou gestionnaire de fichiers autorisé, retrouvez le wp-config.php de cette installation. Téléchargez une copie privée, hors du répertoire servi sur le Web.
2. Recherchez les définitions WP_MEMORY_LIMIT et WP_MAX_MEMORY_LIMIT dans tout le fichier. Si elles existent, modifiez les lignes concernées ; si elles sont fournies par un autre fichier ou une variable d’environnement, faites corriger cette source.
3. Si les définitions sont absentes et que cette méthode est validée, ajoutez les lignes dans le code PHP existant, avant le commentaire de fin de configuration et avant le chargement de wp-settings.php. Ne remettez pas de balise PHP et ne dupliquez pas les définitions.
4. Adaptez les deux valeurs à l’accord reçu, enregistrez, puis vérifiez l’administration et la limite du même contexte avant une seule reprise maîtrisée.
5. En cas d’erreur PHP, rétablissez immédiatement la copie privée par le même accès. Pour abandonner cet essai, remettez les anciennes lignes ou retirez uniquement les deux ajouts, puis contrôlez de nouveau.

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

Si le nombre enregistré ne devient pas effectif

Ne répétez pas la même valeur dans plusieurs fichiers pour forcer son application. Demandez quel moteur traite la demande et quels fichiers de configuration il charge. PHP utilisé dans un terminal peut lire d’autres paramètres que PHP appelé par le serveur web.

Un mécanisme .user.ini peut exister en CGI ou FastCGI, avec un délai de relecture configurable. Il ne s’applique pas identiquement à tous les environnements. Faites confirmer son usage, son emplacement et le délai par le prestataire au lieu de créer un fichier supplémentaire à côté d’un panneau qui gère déjà les paramètres.

Depuis PHP 8.5, max_memory_limit peut fixer un plafond aux valeurs de memory_limit. Les versions disposant de memory_hard_limit_percent appliquent aussi un arrêt brutal au-delà d’un seuil distinct. Ne modifiez pas ces protections pour masquer l’erreur : faites identifier le seuil atteint et la marge autorisée par l’hébergeur. Une valeur affichée dans WordPress ne garantit pas que le processus peut consommer autant sans autre limite du compte.

Si la mémoire effective augmente mais que l’action échoue encore, comparez le message et le volume au même essai. Une nouvelle limite atteinte peut révéler un besoin plus grand ou une consommation anormale ; elle ne justifie pas une escalade indéfinie vers une valeur illimitée.

Adapter la solution à WordPress.com et au multisite

Sur WordPress.com, la documentation du service indique une limite de mémoire fixe qui ne peut pas être augmentée par le client. Ne transposez pas les modifications cPanel ou php.ini à cette plateforme. Réduisez l’opération lorsque c’est pertinent et faites examiner le composant ou le cas concerné par son support.

Sur une autre offre gérée, demandez ce que votre contrat et vos outils permettent réellement. Un panneau absent ne signifie pas qu’un fichier de thème constitue une solution de remplacement. Une extension ne crée pas la mémoire que le prestataire ne peut pas accorder.

En multisite, associez le responsable du réseau avant de modifier une configuration partagée. Distinguez le site concerné, les composants activés pour le réseau et le contexte qui exécute l’action. Une hausse ou une isolation peut affecter plusieurs sites.

Même avec davantage de mémoire par demande, plusieurs traitements simultanés peuvent rester trop exigeants pour le compte. Faites donc examiner leur concurrence si le problème est une interruption globale du service, plutôt qu’une seule limite PHP atteinte.

Valider l’opération complète et les données produites

Reprenez d’abord le cas représentatif conservé, dans l’environnement de test adapté. Vérifiez le résultat utile : éléments importés, champs, associations, images et éventuelles lignes ignorées. Un journal sans erreur mémoire ne prouve pas que tout le fichier a été traité.

Avant une reprise en production, identifiez ce qui existe déjà et la méthode de continuation autorisée par l’outil. Gardez l’original et le compte rendu jusqu’à validation. Si un lot doit être annulé, faites préparer une suppression ciblée des éléments effectivement créés, avec sauvegarde ; ne restaurez pas toute la base par commodité.

Contrôlez ensuite le même volume habituel avec les réglages définitifs. Pour une tâche planifiée, observez son passage normal plutôt que la relancer pour gagner du temps. Les opérations de paiement et d’envoi demandent une validation métier propre.

Faites retirer les réglages temporaires, rétablir les composants nécessaires et confirmer la consommation auprès du support si elle était en cause. Le retour de la page de fin doit s’accompagner de données complètes, sans doublons ni effets externes inattendus.

Documenter la correction pour les prochains traitements

Conservez l’action, le volume traité, les versions, le message initial et les limites réellement appliquées avant et après. Indiquez aussi ce qui a changé : copie réduite, lot plus petit, composant corrigé ou valeur ajustée par le prestataire. Cette trace permet de reproduire une méthode utile au prochain besoin.

Évitez les lots simultanés inutiles et préparez les fichiers à leur usage. Conservez les originaux pour ne pas dégrader les données à chaque tentative. Avant une mise à jour importante du composant concerné, vérifiez le même cas sur une copie comparable.