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

Erro 500 no Magento 2: achar o relatório em var/report pelo ID da tela

O hash que o Magento mostra junto do erro é o nome de um arquivo em var/report. Veja como abrir,…

23 horas atrás

Campo extra no checkout em blocos do WooCommerce sem voltar pro shortcode

Seu snippet com woocommerce_checkout_fields parou de aparecer no checkout em blocos. Registre o campo pela API nova e leia o…

2 dias atrás

Fuso horário no PHP 8.3: log com 3 horas de diferença no servidor

O pedido entrou às 21h e o relatório mostra 00h do dia seguinte. Onde setar date.timezone no PHP 8.3 e…

2 dias atrás

Magento 2 não envia e-mail de pedido: async sending e cron parado

O pedido entra na loja e o e-mail nunca sai: antes de culpar o SMTP, veja o envio assíncrono, a…

3 dias atrás

cron_schedules WordPress: intervalo de 5 minutos no WP-Cron

O WordPress só oferece hourly, twicedaily, daily e weekly. Use o filtro cron_schedules para criar um intervalo de 5 minutos…

4 dias atrás

E-mails do WooCommerce não chegam: como testar o envio de um pedido real

Dispare pela linha de comando o e-mail de um pedido que já existe na loja e descubra se a falha…

4 dias atrás