Augmenter la mémoire PHP sur WordPress facilement

Si vous avez déjà vu “Allowed memory size of X bytes exhausted” dans une page blanche ou dans vos logs, vous avez rencontré la limite mémoire PHP — et WordPress 6.9.4 n’y peut pas grand-chose tant que le serveur n’autorise pas plus de RAM.

Le besoin / Le problème serveur

Le symptôme le plus courant, c’est un site qui plante lors d’une action “lourde” : import, sauvegarde, mise à jour d’extensions, génération d’images, ou édition avec Elementor/Divi/Avada sur une page chargée. Parfois vous ne voyez rien côté navigateur (HTTP 500), et l’erreur n’apparaît que dans error_log ou dans les logs PHP-FPM.

Le problème vient d’un empilement de limites. WordPress a sa propre “cible” de mémoire, mais PHP impose une limite réelle (memory_limit). Si PHP dit 128M, WordPress ne pourra pas consommer 256M, même si vous le demandez.

À la fin, vous saurez :

• Mesurer la limite mémoire “effective” (celle qui s’applique vraiment).
• Augmenter proprement la mémoire via wp-config.php (côté WordPress).
• Augmenter memory_limit via php.ini, .user.ini ou PHP-FPM (côté serveur).
• Comprendre quand .htaccess fonctionne… et quand il ne sert à rien.
• Vérifier et diagnostiquer avec SSH, WP-CLI, curl et les logs.

Résumé rapide

• Votre objectif est d’augmenter PHP memory_limit (serveur) et éventuellement la cible WordPress (wp-config).
• wp-config.php ne peut pas dépasser PHP : si PHP reste à 128M, WordPress restera bridé.
• .htaccess ne marche pas avec Nginx et souvent pas avec PHP-FPM (selon configuration).
• Sur hébergement mutualisé, la voie la plus fiable est souvent .user.ini (si autorisé) ou le panneau d’hébergement (mais ici on reste sur code/commandes).
• Testez avec un script PHP minimal + WP-CLI + lecture des logs, pas “au feeling”.

Avant de commencer (prérequis)

Vous allez toucher à des réglages serveur. Une faute de frappe (un point-virgule manquant) peut casser PHP, donc casser WordPress. J’ai souvent vu des sites tomber à cause d’un php.ini mal formaté ou d’un wp-config.php édité en UTF-8 avec BOM.

Accès nécessaires

• SSH (recommandé) : pour éditer des fichiers, relancer PHP-FPM, lire les logs, lancer WP-CLI.
• FTP/SFTP : si vous n’avez pas SSH, au minimum pour modifier wp-config.php et déposer .user.ini.
• WP-CLI : idéal pour vérifier WordPress sans passer par le navigateur.
• Accès aux logs : /var/log/nginx/error.log, /var/log/apache2/error.log, logs PHP-FPM, ou logs de l’hébergeur.

Sauvegarde obligatoire (avant toute modification)

Avant de changer quoi que ce soit, sauvegardez fichier + base. Voici des commandes typiques (à adapter à votre serveur). Je vous les donne parce que le “je modifie vite fait” finit souvent en restauration.

Cette commande copie wp-config.php avec un horodatage :

# Remplacez /var/www/site par le chemin réel de votre WordPress
cd /var/www/site

# Sauvegarde du wp-config.php
cp wp-config.php "wp-config.php.bak.$(date +%F-%H%M%S)"

Cette commande exporte la base via WP-CLI (si WP-CLI est disponible et configuré) :

# Export SQL de la base (dans le répertoire courant)
wp db export "db-backup.$(date +%F-%H%M%S).sql"

Versions serveur ciblées (avril 2026)

• WordPress : 6.9.4 (cible de cet article).
• PHP : 8.1+ (minimum recommandé). Si vous êtes encore en 7.x, vous cumulez lenteur + incompatibilités + risques.
• MySQL/MariaDB : peu impacté par la mémoire PHP, mais utile pour le diagnostic global.
• Serveur web : Apache ou Nginx (les méthodes diffèrent).

---

Étape 1 : Diagnostiquer la limite mémoire réellement appliquée

Avant d’augmenter quoi que ce soit, mesurez. Le piège classique : vous modifiez wp-config.php, vous mettez “512M”, et rien ne change parce que PHP reste à 128M.

1) Vérifier la limite côté PHP (CLI vs Web)

PHP peut avoir une limite différente en ligne de commande (CLI) et via le serveur web (FPM/Apache). Cette commande affiche la limite côté CLI :

php -r 'echo "PHP CLI memory_limit = " . ini_get("memory_limit") . PHP_EOL;'

Si vous voyez -1, ça signifie “illimité” côté CLI. Ne vous laissez pas piéger : le web peut rester limité.

2) Vérifier la limite côté WordPress (WP-CLI)

Avec WP-CLI, vous pouvez lire des constantes et des infos utiles. Cette commande affiche la version et confirme que WP-CLI parle bien à ce site :

wp core version

Ensuite, vous pouvez afficher les constantes si elles existent (sinon WP-CLI renverra une erreur). Je montre volontairement une commande “robuste” qui n’échoue pas si la constante n’est pas définie :

wp eval 'echo "WP_MEMORY_LIMIT=" . (defined("WP_MEMORY_LIMIT") ? WP_MEMORY_LIMIT : "non_defini") . PHP_EOL;
echo "WP_MAX_MEMORY_LIMIT=" . (defined("WP_MAX_MEMORY_LIMIT") ? WP_MAX_MEMORY_LIMIT : "non_defini") . PHP_EOL;'

3) Vérifier la limite côté Web sans panneau (script minimal)

Si vous avez un accès fichiers, créez un fichier temporaire dans la racine WordPress, par exemple memcheck.php. L’idée : obtenir la valeur de memory_limit telle que PHP l’applique via le serveur web.

Créez le fichier, testez, puis supprimez-le (sécurité).

<?php
// Fichier temporaire de diagnostic : supprimez-le après test.
header('Content-Type: text/plain; charset=UTF-8');

echo "PHP SAPI: " . PHP_SAPI . "n";
echo "memory_limit: " . ini_get('memory_limit') . "n";
echo "max_execution_time: " . ini_get('max_execution_time') . "n";
echo "upload_max_filesize: " . ini_get('upload_max_filesize') . "n";
echo "post_max_size: " . ini_get('post_max_size') . "n";

Testez-le avec curl (vous verrez exactement ce que renvoie le serveur) :

curl -sS https://votre-domaine.tld/memcheck.php

Résultat attendu : une ligne memory_limit: 256M (ou autre). Si vous voyez encore 128M après vos changements, vous savez où creuser.

---

Étape 2 : Augmenter la mémoire côté WordPress (wp-config.php)

WordPress utilise deux constantes principales :

• WP_MEMORY_LIMIT : limite “normale” (front-office).
• WP_MAX_MEMORY_LIMIT : limite pour l’admin (tâches lourdes, import, mises à jour).

Ces constantes ne sont pas magiques : elles demandent à PHP plus de mémoire, mais PHP peut refuser si memory_limit est plus bas.

Où mettre le code

Dans wp-config.php, avant la ligne qui dit /* That's all, stop editing! */. Ne le mettez pas dans functions.php : c’est trop tard dans le chargement, et ça peut être ignoré.

Exemple de réglage raisonnable (256M / 512M admin)

Sur beaucoup de blogs, 256M suffit. Sur des sites avec Elementor + gros plugins (SEO, cache, sécurité), je monte souvent à 512M pour l’admin, surtout pendant les mises à jour.

<?php
/**
 * Réglages mémoire WordPress.
 * À placer dans wp-config.php, avant "That's all, stop editing!".
 */

// Mémoire pour le site (front)
define('WP_MEMORY_LIMIT', '256M');

// Mémoire pour l'administration (import, mises à jour, éditeur, etc.)
define('WP_MAX_MEMORY_LIMIT', '512M');

Pourquoi ça aide (et pourquoi parfois ça ne change rien)

Quand WordPress a la main, il peut appeler ini_set('memory_limit', ...) selon les cas. Mais si votre hébergeur verrouille memory_limit (directive PHP_INI_SYSTEM), WordPress ne pourra pas la dépasser. Vous aurez alors besoin de l’étape serveur (php.ini / FPM).

Compatibilité Divi 5 / Elementor / Avada

Ces page builders consomment surtout de la mémoire lors de l’édition (admin) et de la génération d’aperçus. Si l’éditeur se fige, ou si vous voyez des erreurs 500 à l’ouverture d’une page dans Elementor, commencez par WP_MAX_MEMORY_LIMIT… puis augmentez memory_limit côté PHP.

---

Étape 3 : Augmenter la mémoire côté PHP (php.ini / .user.ini / pool FPM)

La règle : c’est PHP qui tranche. Donc il faut ajuster memory_limit là où PHP le lit réellement pour le web.

Option A (mutualisé) : .user.ini dans la racine

Sur beaucoup d’hébergements en PHP-FPM, vous pouvez créer un fichier .user.ini dans la racine du site (ou dans public_html). PHP relira ce fichier périodiquement (avec un délai, parfois 5 minutes).

Créez .user.ini :

# À exécuter dans le dossier racine servi par le web (ex: public_html)
printf "memory_limit=512Mnmax_execution_time=120n" > .user.ini

Deux remarques :

• Le délai : ce n’est pas instantané. Si vous testez trop vite, vous croirez que “ça ne marche pas”.
• La portée : selon l’hébergeur, le fichier doit être au bon endroit (document root).

Option B (VPS/dédié) : php.ini (ou conf.d) côté FPM

Sur un serveur que vous administrez, vous avez généralement :

• Un php.ini global.
• Des surcharges dans /etc/php/8.1/fpm/conf.d/*.ini (chemin variable selon distro).
• Une config de pool PHP-FPM (par site) du type /etc/php/8.1/fpm/pool.d/www.conf ou un pool dédié.

Commencez par localiser le fichier chargé par PHP-FPM. Cette commande affiche le chemin du php.ini pour le CLI, mais c’est déjà un indice :

php --ini

Pour PHP-FPM, vous pouvez aussi chercher dans la config du service (selon distribution). Dans le doute, le plus fiable est de lire memcheck.php (étape 1) et de vérifier si phpinfo() est autorisé (souvent non en prod).

Exemple : créer un fichier dédié dans conf.d (approche propre, facile à versionner) :

# Exemple Debian/Ubuntu (adaptez la version PHP et les chemins)
sudo tee /etc/php/8.1/fpm/conf.d/99-wordpress-memory.ini > /dev/null <<'EOF'
; Réglages PHP pour WordPress (PHP-FPM)
; Commentaires en français : gardez ce fichier simple pour éviter les erreurs de syntaxe.
memory_limit = 512M
max_execution_time = 120
max_input_time = 120
EOF

Puis redémarrez PHP-FPM (sinon rien ne change) :

# Service typique sur Debian/Ubuntu
sudo systemctl restart php8.1-fpm

# Vérification rapide du statut
sudo systemctl status php8.1-fpm --no-pager

Option C (VPS/dédié) : pool PHP-FPM par site (recommandé si multi-sites)

Si vous hébergez plusieurs sites, évitez d’augmenter la mémoire globalement pour tout le monde. Créez un pool dédié au site WordPress, avec une limite mémoire cohérente et des paramètres de process adaptés.

Exemple (extrait de pool) : /etc/php/8.1/fpm/pool.d/site.conf. Ici, je montre surtout php_admin_value[memory_limit] : c’est une directive “forte” qui ne peut pas être surchargée par ini_set.

sudo tee /etc/php/8.1/fpm/pool.d/site.conf > /dev/null <<'EOF'
; Pool PHP-FPM dédié à un site WordPress
[site]
user = www-data
group = www-data

listen = /run/php/php8.1-fpm-site.sock
listen.owner = www-data
listen.group = www-data

; Réglages process (exemples raisonnables, adaptez à la RAM/CPU)
pm = dynamic
pm.max_children = 10
pm.start_servers = 2
pm.min_spare_servers = 2
pm.max_spare_servers = 4

; Limites PHP appliquées à ce pool
php_admin_value[memory_limit] = 512M
php_admin_value[max_execution_time] = 120
EOF

Redémarrez ensuite PHP-FPM :

sudo systemctl restart php8.1-fpm

---

Étape 4 : .htaccess et cas Apache (mod_php / PHP-FPM)

.htaccess est spécifique à Apache. Avec Nginx, il est ignoré. Même sous Apache, l’efficacité dépend de la façon dont PHP est exécuté :

• Apache + mod_php : php_value dans .htaccess fonctionne souvent.
• Apache + PHP-FPM : php_value dans .htaccess provoque souvent une erreur 500 (directive non autorisée).

Tester si votre Apache accepte php_value

Si vous ajoutez php_value memory_limit 512M et que le site tombe en 500, retirez immédiatement la ligne : votre stack n’accepte pas ces directives dans .htaccess.

Exemple .htaccess (Apache mod_php uniquement)

Ajoutez ces lignes en haut de votre .htaccess (ou dans un bloc dédié). Faites-le uniquement si vous savez que mod_php est utilisé. Sinon, passez par .user.ini ou PHP-FPM.

# .htaccess (Apache) - uniquement si mod_php est actif
php_value memory_limit 512M
php_value max_execution_time 120

Si vous avez un doute, ne forcez pas .htaccess. J’ai vu des débutants casser un site en production avec une seule ligne php_value.

---

Étape 5 : Nginx + PHP-FPM (et pourquoi .htaccess ne sert à rien)

Nginx ne lit pas .htaccess. Donc pour la mémoire, tout se joue côté PHP-FPM (pool / ini) et éventuellement .user.ini (si autorisé par la config FPM).

Vérifier quel pool sert votre site

Si votre Nginx pointe vers un socket spécifique, vous saurez quel pool modifier. Cherchez la directive fastcgi_pass dans la conf du vhost :

# Exemple : lister les vhosts Nginx (chemins variables)
ls -la /etc/nginx/sites-enabled

# Chercher fastcgi_pass dans la conf
grep -R "fastcgi_pass" -n /etc/nginx/sites-enabled /etc/nginx/conf.d 2>/dev/null

Si vous voyez fastcgi_pass unix:/run/php/php8.1-fpm-site.sock;, vous savez quel pool vous devez ajuster.

Redémarrage : Nginx vs PHP-FPM

Augmenter la mémoire nécessite presque toujours un redémarrage de PHP-FPM (pas forcément Nginx). Quand on redémarre Nginx “par réflexe” et qu’on oublie PHP-FPM, on perd du temps.

sudo systemctl restart php8.1-fpm
sudo nginx -t
sudo systemctl reload nginx

---

Fichiers de configuration complets

Vous ne devez pas tout utiliser. Prenez le fichier correspondant à votre stack. Je fournis des versions “prêtes à copier-coller”, avec commentaires en français, et des valeurs réalistes pour WordPress 6.9.4 + PHP 8.1+.

wp-config.php (extrait complet à insérer)

Placez ce bloc avant la ligne “That’s all, stop editing!”.

<?php
/**
 * Extrait à ajouter dans wp-config.php (WordPress 6.9.4+).
 * Objectif : augmenter la mémoire que WordPress essaie d'utiliser.
 * Attention : PHP doit autoriser au moins ces valeurs.
 */

// Mémoire pour le front-office
define('WP_MEMORY_LIMIT', '256M');

// Mémoire pour l'administration (mises à jour, import, éditeurs visuels)
define('WP_MAX_MEMORY_LIMIT', '512M');

php.ini (fichier minimal utilisable)

Selon votre hébergement, vous n’aurez pas le droit d’éditer le php.ini global. Sur VPS/dédié, préférez un fichier conf.d (plus propre). Si vous devez fournir un php.ini local, gardez-le minimal.

; php.ini - réglages minimaux orientés WordPress
; Commentaires en français : évitez les réglages inutiles.

memory_limit = 512M
max_execution_time = 120
max_input_time = 120
post_max_size = 64M
upload_max_filesize = 64M

.user.ini (mutualisé / PHP-FPM)

; .user.ini - à placer dans le document root (ex: public_html)
; Peut mettre quelques minutes à être pris en compte.

memory_limit=512M
max_execution_time=120
max_input_time=120
post_max_size=64M
upload_max_filesize=64M

.htaccess (Apache) complet, sans réglages PHP dangereux

Je vous donne un .htaccess “safe” pour WordPress, sans php_value. Si vous êtes en mod_php et que vous voulez quand même tenter, ajoutez les lignes php_value à part et testez immédiatement.

# .htaccess - base WordPress + quelques durcissements simples
# Note : N'ajoutez pas de directives PHP ici si vous êtes en PHP-FPM (risque de 500).

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteRule .* - [E=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
RewriteBase /
RewriteRule ^index.php$ - [L]
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]
</IfModule>
# END WordPress

# Empêcher l'accès direct à certains fichiers sensibles (selon vos besoins)
<Files wp-config.php>
Require all denied
</Files>

nginx.conf (server block minimal + WordPress + PHP-FPM)

Exemple de vhost Nginx. L’augmentation de mémoire ne se fait pas ici, mais je l’inclus parce que c’est souvent le fichier que vous ouvrez pour comprendre quel pool FPM est utilisé.

server {
    listen 80;
    server_name exemple.tld www.exemple.tld;

    root /var/www/exemple.tld/public;
    index index.php index.html;

    access_log /var/log/nginx/exemple.access.log;
    error_log  /var/log/nginx/exemple.error.log;

    location / {
        try_files $uri $uri/ /index.php?$args;
    }

    location ~ .php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

        # IMPORTANT : c'est ici que vous voyez quel pool PHP-FPM sert le site
        fastcgi_pass unix:/run/php/php8.1-fpm.sock;
    }

    # Bloquer l'accès aux fichiers cachés
    location ~ /.(?!well-known) {
        deny all;
    }
}

---

Vérification

Vérifiez toujours en trois points : PHP web, WordPress, et logs. Une validation “à moitié” vous fera perdre du temps au prochain crash.

1) Vérifier PHP côté web (curl)

Si vous avez utilisé memcheck.php :

curl -sS https://votre-domaine.tld/memcheck.php | sed -n '1,5p'

Vous devez voir memory_limit: 512M (ou la valeur choisie).

2) Vérifier WordPress via WP-CLI

WP-CLI ne reflète pas toujours la limite web, mais c’est utile pour confirmer vos constantes :

wp eval 'echo "WP_MEMORY_LIMIT=" . (defined("WP_MEMORY_LIMIT") ? WP_MEMORY_LIMIT : "non_defini") . PHP_EOL;
echo "WP_MAX_MEMORY_LIMIT=" . (defined("WP_MAX_MEMORY_LIMIT") ? WP_MAX_MEMORY_LIMIT : "non_defini") . PHP_EOL;'

3) Vérifier les logs (les erreurs mémoire laissent une trace)

Sur Nginx :

sudo tail -n 80 /var/log/nginx/error.log

Sur Apache (chemin fréquent) :

sudo tail -n 80 /var/log/apache2/error.log

Sur PHP-FPM (chemins variables) :

# Cherchez les logs php-fpm
sudo journalctl -u php8.1-fpm -n 120 --no-pager

Tableau de diagnostic rapide

Symptôme	Cause probable	Vérification	Solution
Erreur “Allowed memory size … exhausted”	memory_limit trop bas	memcheck.php + logs PHP	Augmenter memory_limit via php.ini/.user.ini/pool FPM
HTTP 500 juste après ajout de php_value dans .htaccess	Apache en PHP-FPM (directive interdite)	Logs Apache/Nginx	Retirer php_value, utiliser .user.ini ou FPM
Vous mettez 512M dans wp-config, mais WordPress plante pareil	PHP refuse la hausse	memcheck.php montre 128M	Modifier la config PHP (pas seulement WordPress)
WP-CLI indique une valeur, le web une autre	CLI et FPM ont des configs différentes	php -r ... vs curl memcheck.php	Modifier le bon php.ini (FPM) / pool

---

Si ça ne marche pas

Quand la mémoire ne bouge pas, il y a presque toujours une explication simple : vous n’avez pas modifié le bon fichier, ou le serveur ignore la méthode.

1) Vous n’êtes pas sur le bon PHP (multi-versions)

Sur certains serveurs, vous avez PHP 8.1 pour CLI, mais PHP 8.2/8.3 pour FPM (ou l’inverse). Vérifiez la version côté web via memcheck.php en ajoutant temporairement :

<?php
// Ajoutez cette ligne temporairement dans memcheck.php
echo "PHP_VERSION: " . PHP_VERSION . "n";

2) .user.ini ignoré

Certains hébergeurs désactivent .user.ini ou changent son emplacement. Vérifiez si PHP lit des fichiers utilisateur. Sans phpinfo(), vous le déduisez en testant une directive simple (ex: max_execution_time) et en observant si elle change après quelques minutes.

3) Cache serveur / OPcache : vous testez trop vite

OPcache ne “cache” pas memory_limit directement, mais il peut vous donner l’impression que rien n’a changé si vous ne redémarrez pas FPM. Redémarrez PHP-FPM, puis retestez.

4) Vous avez cassé la syntaxe d’un fichier

Deux erreurs que je vois tout le temps :

• Dans wp-config.php : une quote manquante, ou le code placé après “stop editing”.
• Dans un fichier ini : un caractère invisible, ou une ligne non valide.

Pour Nginx, testez la config :

sudo nginx -t

Pour PHP-FPM, le plus simple est de lire les erreurs de service :

sudo journalctl -u php8.1-fpm -n 200 --no-pager

5) Votre hébergeur verrouille la directive

Si memory_limit est configuré en mode “système”, vous ne pourrez pas le changer via ini_set, .user.ini, ni parfois via php.ini local. Dans ce cas, la solution réelle est : changer l’offre, ou demander au support d’augmenter la limite.

---

Pièges et erreurs courantes

Erreur	Cause	Solution
Coller les define() dans functions.php	Trop tard dans le chargement WordPress	Mettre dans wp-config.php avant “stop editing”
Oublier le point-virgule dans wp-config.php	Erreur de syntaxe PHP, site HS	Restaurer le backup, puis réappliquer proprement
Ajouter php_value dans .htaccess sur un site Nginx	Nginx ignore .htaccess	Modifier PHP-FPM / .user.ini
Ajouter php_value en Apache+PHP-FPM	Directive interdite, HTTP 500	Retirer et passer par .user.ini ou pool FPM
Tester sur production sans sauvegarde	Restauration compliquée en cas d’erreur	Backup fichier + DB avant chaque changement
Suivre un vieux tuto (PHP 7.x, directives obsolètes)	Incompatibilités ou chemins différents	Cibler PHP 8.1+ et WordPress 6.9.4, vérifier les chemins réels
Confondre mémoire WordPress et mémoire PHP	Deux couches différentes	Mesurer avec memcheck.php + définir les constantes WP
Oublier de redémarrer PHP-FPM	Les nouveaux ini ne sont pas chargés	systemctl restart php8.1-fpm puis retest
Changer la mémoire mais laisser post_max_size trop bas	Imports/éditeurs échouent malgré la RAM	Ajuster aussi post_max_size/upload_max_filesize

---

Sécurité serveur

Augmenter la mémoire, c’est aussi augmenter ce qu’un processus PHP peut consommer. Sur un petit VPS, si vous mettez 1024M partout, vous pouvez provoquer de la swap, des timeouts, voire un serveur instable. J’ai déjà vu un site “réparé” côté WordPress, mais le serveur tomber dès qu’un bot déclenchait plusieurs requêtes lourdes.

• Évitez “illimité” (memory_limit=-1) sur le web. C’est tentant, et c’est une mauvaise idée : un plugin buggué peut épuiser la RAM.
• Couplez avec des limites FPM : sur PHP-FPM, configurez pm.max_children selon votre RAM, sinon chaque process peut prendre 512M et tout s’écroule.
• Supprimez les scripts de diagnostic : memcheck.php doit disparaître après usage. Sinon vous exposez des infos (versions, limites) utiles à un attaquant.
• Surveillez les logs : une hausse de mémoire masque parfois un problème de fond (boucle, requête énorme, plugin mal optimisé).

---

Ressources

• WordPress.org — Editing wp-config.php
• Developer Resources — wp-config.php (référence)
• WordPress.org Support — Mémoire épuisée (memory exhausted)
• PHP.net — Directive memory_limit
• PHP.net — Configuration PHP-FPM
• GitHub — WordPress (wordpress-develop)

---

FAQ

Quelle valeur choisir : 256M, 512M, 1024M ?

Pour un blog “classique”, 256M est souvent suffisant. Si vous utilisez Elementor/Divi/Avada avec plusieurs plugins lourds, 512M côté PHP est une valeur réaliste. 1024M se justifie surtout sur des sites très chargés (e-commerce, gros imports) et sur un serveur avec assez de RAM.

J’ai mis WP_MEMORY_LIMIT à 512M, mais l’erreur persiste. Pourquoi ?

Parce que PHP refuse. Vérifiez memory_limit côté web avec memcheck.php. Tant que PHP est à 128M, WordPress ne dépassera pas 128M.

Est-ce que .htaccess marche chez moi ?

Uniquement si vous êtes sur Apache, et surtout si PHP tourne en mod_php. Avec PHP-FPM, php_value dans .htaccess déclenche souvent un 500. Avec Nginx, .htaccess est ignoré.

Pourquoi WP-CLI affiche une valeur différente du navigateur ?

WP-CLI utilise PHP en mode CLI, qui peut charger un autre php.ini. Le navigateur passe par PHP-FPM/Apache. Comparez php -r ... et curl memcheck.php.

Dois-je augmenter aussi max_execution_time ?

Souvent oui, parce que les mêmes opérations qui consomment de la mémoire (import, génération) prennent aussi du temps. 120 secondes est une valeur raisonnable sur beaucoup de sites.

Mon site est en staging : puis-je tester librement ?

C’est le bon réflexe. Testez d’abord en staging, puis reproduisez exactement la même méthode en production. Le piège courant : le staging est sur un autre pool PHP avec une autre config.

Est-ce que ça peut masquer un bug de plugin ?

Oui. Augmenter la mémoire “fait passer” une opération, mais si un plugin a une fuite mémoire ou charge trop de données, vous repousserez juste le problème. Surveillez les logs et désactivez temporairement les plugins suspects si l’explosion mémoire continue.

Que faire si l’hébergeur bloque toute modification ?

Si vous ne pouvez pas changer memory_limit via .user.ini ou un php.ini local, il faut demander au support d’augmenter la limite, ou changer d’offre (ou d’hébergeur). WordPress ne peut pas contourner un verrou serveur proprement.

Est-ce risqué d’augmenter la mémoire ?

Oui si vous ne dimensionnez pas PHP-FPM. 10 process à 512M peuvent théoriquement consommer 5 Go. Ajustez pm.max_children selon votre RAM, et évitez les valeurs extrêmes.

Je dois supprimer memcheck.php après ?

Oui. C’est un fichier de diagnostic qui expose des informations techniques. Gardez-le le temps du test, puis supprimez-le immédiatement.