Ativar WP_DEBUG_LOG no WordPress: log de erros sem aparecer na tela

Tela branca ou fatal error no ar e a mensagem não pode aparecer pro visitante. O caminho é jogar tudo num arquivo: WP_DEBUG liga o relatório, WP_DEBUG_LOG grava e WP_DEBUG_DISPLAY corta a saída na tela.

As três linhas no wp-config.php

Elas ficam acima do comentário /* That's all, stop editing! */. Depois dessa linha o wp-settings.php já rodou, e a wp_debug_mode() não olha mais pras constantes. Não é superstição, é ordem de carregamento.

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

WP_DEBUG chama error_reporting( E_ALL ). WP_DEBUG_LOG em true aponta o error_log do PHP pra wp-content/debug.log. E WP_DEBUG_DISPLAY em false faz o próprio WordPress rodar ini_set( 'display_errors', 0 ) — você não precisa repetir isso à mão, como muito tutorial manda. Está tudo em wp-includes/load.php.

Onde cai o log e como acompanhar

O arquivo nasce na primeira notice. Eu deixo um tail aberto num terminal e reproduzo o erro no navegador, assim dá pra amarrar cada linha à requisição que gerou ela. Pra ligar sem abrir editor, o WP-CLI já ancora as constantes no lugar certo do arquivo:

cd /var/www/seusite/html
sudo -u www-data wp config set WP_DEBUG true --raw
sudo -u www-data wp config set WP_DEBUG_LOG true --raw
sudo -u www-data wp config set WP_DEBUG_DISPLAY false --raw

tail -f wp-content/debug.log

Tire o log de dentro do docroot

wp-content/debug.log responde por URL. Quem acertar o endereço lê caminho de servidor, prefixo de tabela e trecho de query. Desde o WordPress 5.1 a constante aceita um caminho em vez de true, então aponte pra fora da pasta pública:

define( 'WP_DEBUG_LOG', '/var/log/wordpress/meusite-debug.log' );

O usuário do PHP-FPM (normalmente www-data) precisa poder escrever nesse arquivo, senão o log some sem aviso. Terminado o diagnóstico, devolva WP_DEBUG pra false e apague o arquivo: com um plugin barulhento ele passa de 1 GB numa semana e enche o disco no pior horário possível.