WP_DEBUG no está configurado, pero sigo recibiendo advertencias

Reemplaza

define('WP_DEBUG', false);

con esto:

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);

También es posible que esta línea ya esté configurada como false. En ese caso, verás el siguiente código:

define('WP_DEBUG', false);

En cualquier caso, necesitas reemplazar esta línea con el siguiente código:

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

No olvides guardar los cambios y subir tu archivo wp-config.php de vuelta al servidor.

Para entornos de WordPress, generalmente no hay razón para usar ini_set porque eso es lo que ya logran las constantes definidas proporcionadas por WordPress Core. La forma en que funciona PHP es que ciertas configuraciones se pueden anular dentro de tu CMS (WordPress), dentro de scripts individuales e incluso por usuario o por directorio (para gran frustración de los hosts web y agencias).

Para desactivar la visualización de errores en la página en WordPress, la única configuración que realmente necesitas es:

define('WP_DEBUG', false);

...porque cuando WP_DEBUG está desactivado, las subopciones también se inactivan:

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

Ten en cuenta que la opción confusa WP_DEBUG_LOG solo se refiere a la creación de debug.log dentro del directorio wp-content y no afecta otras configuraciones de registro, etc.

Nuevamente, las configuraciones en WordPress pueden anular las configuraciones predeterminadas de PHP, por lo que tus configuraciones de PHP no importan tanto como tener configuraciones correctas en tu archivo wp-config.php, que se carga antes que otros componentes de WP.

Dicho esto, es una buena idea implementar configuraciones predeterminadas como las siguientes en producción:

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 un ejemplo completo, consulta nuestro archivo php.ini de SlickStack optimizado para Nginx y PHP-FPM.

En un caso, después de horas de investigación, nos dimos cuenta de que un plugin (o tema) estaba anulando las diversas configuraciones de manejo de errores establecidas previamente en php.ini y wp-config.php. La única forma de evitar esto es eliminar el plugin o tema de WordPress que intenta "hackear" tus configuraciones de PHP, o pedirles que lo eliminen porque es una muy mala práctica que las extensiones anulen las opciones de depuración de tu CMS.

En SlickStack, creamos un script Bash que "marca" cualquier línea ini_set y error_reporting de los archivos PHP en los directorios /themes/ y /plugins/ resaltando dichas instancias mediante un MU Plugin (script PHP) que muestra una lista de dichos "hacks" en el Panel de Administración de WordPress.

Intenta desactivar/suprimir todos los avisos/notificaciones de error en tu archivo wp-config.php (en la parte superior). De todos modos: Los errores no son algo malo. Te dan la oportunidad de corregir tu código.

Ninguna de las soluciones anteriores me ha funcionado.

Para mí, la solución fue agregar un archivo php en la carpeta mu-plugins. Solo crea un archivo php y añade la siguiente línea.

error_reporting(E_ALL & ~( E_NOTICE ));

Después de eso, súbelo a la carpeta mu-plugins (si la carpeta no existe, créala dentro de la carpeta wp-content).

En mi caso, el problema era que WP_DEBUG estaba configurado como 'false' en lugar de false, lo que supongo que se evalúa como verdadero, ya que es una cadena.

Así que prueba con

define('WP_DEBUG', false);

si tienes

define('WP_DEBUG', 'false');