WP_MEMORY_LIMIT no WordPress: resolver memória esgotada no PHP 8.3

A importação morre na metade e o painel cospe “Fatal error: Allowed memory size of 134217728 bytes exhausted”. O processo bateu no teto do PHP. No WordPress esse teto passa por duas constantes diferentes, e mexer na errada não muda nada.

As duas constantes do wp-config.php

Elas precisam ficar acima da linha require_once ABSPATH . 'wp-settings.php';. Depois dela o WordPress já resolveu os padrões e o seu define é ignorado:

define( 'WP_MEMORY_LIMIT', '256M' );     // site todo, padrão 40M
define( 'WP_MAX_MEMORY_LIMIT', '512M' ); // wp-admin e imagens, padrão 256M
                                         // ou o php.ini, se ele já for maior

A primeira vale pro front-end. A segunda é o teto que o wp-admin e o redimensionamento de imagem pedem através de wp_raise_memory_limit(). O detalhe que confunde: o WordPress só sobe o limite, nunca desce. Se o php.ini já está em 512M, declarar 256M não reduz coisa alguma.

Conferir o valor que vale de verdade

Cuidado com o teste pelo WP-CLI: ele roda no SAPI de linha de comando e lê o cli/php.ini, que quase nunca é o mesmo do site. O número que vale pro visitante está no pool do PHP-FPM, e o painel mostra em Ferramentas > Saúde do site > Informações, no campo Limite de memória do PHP.

sudo -u www-data wp eval 'echo ini_get("memory_limit"), PHP_EOL;'  # valor do CLI
grep -ri memory_limit /etc/php/8.3/fpm/pool.d/                      # valor do site

Quando o define é puro enfeite

O WordPress aplica a constante chamando ini_set(). Se o pool trava o valor com php_admin_value, o ini_set falha em silêncio e a constante vira decoração. Troque por php_value[memory_limit] se quiser que o site consiga subir sozinho, e recarregue com sudo systemctl reload php8.3-fpm.

Antes de sair jogando 1G, olhe o que estourou: nove em cada dez vezes é um plugin puxando o catálogo inteiro num WP_Query com posts_per_page em -1. Memória extra compra tempo, não conserta a consulta.