Wordpress

Erro crítico neste site: usar o modo de recuperação do WordPress 6.9

Atualizou um plugin, o site caiu e todo visitante vê “Ocorreu um erro crítico neste site. Verifique a caixa de entrada do e-mail do administrador do site para obter instruções”. O WordPress 6.9 já gerou o link do modo de recuperação — o que falha é o endereço pra onde ele foi, quase sempre um e-mail antigo que ninguém abre há anos.

Veja o destinatário e force um novo envio

cd /var/www/seusite/html
sudo -u www-data wp option get admin_email --skip-plugins --skip-themes
sudo -u www-data wp option delete recovery_mode_email_last_sent --skip-plugins --skip-themes

O aviso sai uma vez a cada 24 horas, e o carimbo desse limite fica guardado na opção recovery_mode_email_last_sent. Apagando a opção, o próximo acesso ao /wp-admin/ ou ao /wp-login.php dispara outro e-mail: o WordPress só manda o link quando o erro fatal acontece numa área protegida, nunca na página pública. Pra mandar o link pra uma caixa que você lê de verdade, sem trocar o e-mail administrativo da loja, declare a constante no wp-config.php, acima da linha que manda parar de editar:

define( 'RECOVERY_MODE_EMAIL', 'voce@seudominio.com.br' );

O link vale pelo mesmo período do limite de envio, 24 horas por padrão, e abre o painel numa sessão em que os plugins com erro fatal ficam pausados só pra você. O resto do mundo continua vendo o site quebrado até você desativar de fato.

Quando o e-mail não sai de jeito nenhum

SMTP configurado no plugin que morreu, servidor sem serviço de envio, domínio novo caindo em spam. Nesses casos vá pelo terminal: o --skip-plugins carrega o WordPress sem o culpado, então o WP-CLI roda mesmo com o site fatal.

sudo -u www-data wp plugin list --status=active --skip-plugins --skip-themes
sudo -u www-data wp plugin deactivate nome-do-plugin --skip-plugins --skip-themes

Pra ver o erro real em vez da mensagem genérica, são quatro linhas no wp-config.php. O WP_DEBUG_LOG só grava se o WP_DEBUG estiver em true, e o display em false evita jogar o stack trace na cara do visitante:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
define( 'WP_DISABLE_FATAL_ERROR_HANDLER', true );

Tire as quatro linhas e apague o wp-content/debug.log assim que terminar: o arquivo fica ao alcance de quem souber o caminho, e sem o handler o próximo fatal derruba o site sem rede de proteção.

Post Recentes

Timeout do PHP-FPM na chamada de IA: tire do request e jogue no CLI

504 no nginx quando a API de IA demora? Quem desiste primeiro é o nginx, não o PHP. Enfileire o…

5 horas atrás

NumberFormatter no PHP: R$ formatado e valor por extenso em pt-BR

O number_format não põe o R$ nem escreve o valor por extenso. Veja como usar NumberFormatter com CURRENCY e SPELLOUT…

1 dia atrás

Could not ping search engine no Magento 2: OpenSearch fora do ar

Categoria vazia e busca sem resultado no Magento 2.4.8? Teste o OpenSearch com curl, confira o bloco catalog/search do env.php…

2 dias atrás

Bookmarks da grid do Magento 2: colunas somem e o filtro fica preso

Editou o listing.xml e o admin continua com as colunas antigas ou um filtro travado? O estado da grid está…

3 dias atrás

array_chunk no PHP: processar 50 mil registros em lotes sem estourar memória

Importação morrendo com Allowed memory size exhausted? Fatie o processamento com array_chunk e, quando nem o array couber, leia o…

3 dias atrás

Unknown module in the enabled modules list: erro no Magento 2

Apagou a pasta do módulo e agora todo bin/magento morre reclamando de módulo desconhecido? A lista continua no app/etc/config.php, e…

4 dias atrás