WP_DEBUG não está definido, mas ainda estou recebendo avisos

Se WP_DEBUG não estiver definido, como eu o entendo, você nunca deverá ver avisos. Mas em alguns sites em alguns servidores, ainda estou vendo alguns. Nem todos os avisos que seriam exibidos se WP_DEBUG foi definido, mas alguns selecionados.

Tentei alterar o nível de erro no php.ini, mas isso parece não ter efeito se os avisos aparecem ou não, mas eles aparecem em quantidades diferentes em servidores diferentes (ou seja, nenhum aviso no desenvolvimento, um aviso no preparo e mais alguns avisos de produção).

WP_DEBUG não tem impacto na saída de erro do PHP. Além da configuração error_reporting, defina display_errors = 0 no seu arquivo php.ini. É ativado por padrão para desenvolvimento. Mas você vai querer isso em servidores de produção.

Substituir

define('WP_DEBUG', false);

com isso:

ini_set('log_errors','On');

ini_set('display_errors','Off');

ini_set('error_reporting', E_ALL );

define('WP_DEBUG', false);

define('WP_DEBUG_LOG', true);

define('WP_DEBUG_DISPLAY', false);

Também é possível que essa linha já esteja configurada como false. Nesse caso, você verá o seguinte código:

define('WP_DEBUG', false);

Nos dois casos, você precisa substituir esta linha pelo seguinte código:

ini_set('display_errors','Off');
ini_set('error_reporting', E_ALL );
define('WP_DEBUG', false);
define('WP_DEBUG_DISPLAY', false);

Não esqueça de salvar as alterações e fazer upload do arquivo wp-config.php de volta ao servidor.

Tente desativar / suprimir todos os avisos / avisos de erro no seu wp-config.php(na parte superior). Enfim: erros não são nada ruins. Eles dão a você a chance de corrigir seu código.

Para ambientes WordPress, geralmente não há razão para usar, ini_setporque é isso que as constantes definidas fornecidas pelo WordPress Core já estão alcançando. A maneira como o PHP funciona é que determinadas configurações podem ser substituídas no seu CMS (WordPress), em scripts individuais e até mesmo por usuário ou por diretório (para grande frustração dos hosts e agências da web).

Para desativar a exibição de erros na página no WordPress, a única configuração que você realmente precisa é:

define('WP_DEBUG', false);

... porque quando WP_DEBUGestá desativado, as subopções ficam inativas:

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

Lembre-se de que a WP_DEBUG_LOGopção confusa refere-se apenas à criação de debug.logdentro do diretório wp-contente não afeta outras configurações de log etc.

Novamente, as configurações do WordPress podem substituir as configurações padrão do PHP, portanto, as configurações do PHP não importam tanto quanto ter as configurações corretas no wp-config.phparquivo, que são carregadas antes de outros componentes do WP.

Dito isto, é uma boa ideia implementar as configurações padrão, como abaixo na produção:

error_reporting = E_ERROR | E_WARNING | E_PARSE
display_errors = Off
display_startup_errors = Off
log_errors = On
error_log = /var/www/logs/error.log
log_errors_max_len = 1024
ignore_repeated_errors = On
ignore_repeated_source = Off
report_memleaks = On
xmlrpc_errors = 0
html_errors = Off

Para um exemplo completo, consulte o nosso arquivo slickStack php.ini otimizado para Nginx e PHP-FPM.

Em um caso, após horas de pesquisa, percebemos que um plugin (ou tema) estava substituindo as várias configurações de tratamento de erros definidas anteriormente em php.inie wp-config.php. A única maneira de evitar isso é remover o plug-in ou tema do WordPress que está tentando "hackear" suas configurações de PHP ou pedir para removê-lo, porque isso é uma prática muito ruim para as extensões substituírem as opções de depuração do seu CMS.

No SlickStack, criamos um script Bash que "sinaliza" qualquer ini_sete error_reportinglinhas de arquivos PHP nos diretórios /themes/e /plugins/, destacando essas instâncias usando um MU Plugin (script PHP) que exibe uma lista desses "hacks" no WP Admin Dashboard.