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 maiorA 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 siteQuando 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.