WP_DEBUG no está configurado, pero sigo recibiendo advertencias

14

Si WP_DEBUG no está configurado, según tengo entendido, nunca debería ver advertencias. Pero en algunos sitios en algunos servidores, todavía veo algunos. No todas las advertencias que se mostrarían si se configurara WP_DEBUG, pero algunas selectas.

Intenté cambiar el nivel de error en php.ini, pero eso parece no tener efecto sobre si aparecen o no advertencias, pero aparecen en diferentes cantidades en diferentes servidores (es decir, no hay advertencias sobre el desarrollo, una advertencia sobre la puesta en escena, y algunas advertencias más sobre la producción).

tomdxw
fuente
¿Estas son definitivamente advertencias o errores fatales?
TheDeadMedic
Tuve exactamente el mismo problema, fueron ADVERTENCIAS de GravityForms en mi caso, la salida de advertencia fue - Advertencia: el interruptor de orientación "continuar" es equivalente a "romper". ¿Querías usar "continuar 2"? en /plugins/gravityforms/common.php - La respuesta de Logic Digger a continuación funcionó copiar / pegar para que yo arregle este primer intento, gracias.
OG Sean

Respuestas:

8

WP_DEBUG no tiene impacto en la salida de error de PHP. Además de la configuración de error_reporting, configure display_errors = 0 en su archivo php.ini. Está habilitado de forma predeterminada para el desarrollo. Pero lo querrá en los servidores de producción.

Dave Konopka
fuente
Parafraseando wp-includes / load.php: if (WP_DEBUG) error_reporting (E_ALL). Pero parece que varios complementos están jugando con error_reporting y display_errors cuando probablemente no deberían serlo.
tomdxw
1
Ah, tienes razón, display_errors se configuró en On en mi php.ini. Supuse que WP_DEBUG se hizo cargo de todos los errores. Gracias.
tomdxw
22

Reemplazar

define('WP_DEBUG', false);

con este:

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);
RAM
fuente
44
Agregue una explicación a su respuesta.
fuxia
Probablemente los errores en la pantalla estén apagados, pero puede verlos en su servidor en el registro de errores
user2060451
4

También es posible que esta línea ya esté establecida en falso. En ese caso, verá el siguiente código:

define('WP_DEBUG', false);

En cualquier caso, debe 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 olvide guardar sus cambios y cargar su archivo wp-config.php nuevamente en el servidor.

Buscador de lógica
fuente
1
Gracias, esto funcionó para ocultar advertencias en la parte delantera para mí. WP_DEBUG ya estaba establecido en falso.
OG Sean
1

Intente desactivar / suprimir todas las advertencias / avisos de error en su wp-config.php(en la parte superior). De todos modos: los errores no son nada malo. Te dan la oportunidad de arreglar tu código.

emperador
fuente
Creo que fueron los complementos de otras personas jugando con error_reporting lo que causó esto.
tomdxw
1

Para los entornos de WordPress, generalmente no hay razón para usar ini_setporque eso es lo que las constantes definidas proporcionadas por WordPress Core ya están logrando. La forma en que funciona PHP es que ciertas configuraciones pueden anularse dentro de su CMS (WordPress), dentro de scripts individuales, e incluso por usuario o por directorio (para frustración de los servidores web y agencias).

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

define('WP_DEBUG', false);

... porque cuando WP_DEBUGestá desactivado, las subopciones están inactivas:

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

Tenga en cuenta que la WP_DEBUG_LOGopción confusa solo se refiere a la creación debug.logdentro del directorio wp-contenty no afecta a otras configuraciones de registro, etc.

Una vez más, la configuración en WordPress puede anular la configuración predeterminada de PHP, por lo que su configuración de PHP no importa tanto como tener la configuración correcta en su wp-config.phparchivo, que se carga antes que otros componentes de WP.

Dicho esto, es una buena idea implementar la configuración predeterminada como se muestra a continuación 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, consulte nuestro archivo SlickStack php.ini optimizado para Nginx y PHP-FPM.

En un caso, después de horas de investigación, nos dimos cuenta de que un complemento (o tema) estaba anulando las diversas configuraciones de manejo de errores establecidas previamente en php.iniy wp-config.php. La única forma de evitar esto es eliminar el complemento o tema de WordPress que está tratando de "piratear" la configuración de PHP, o decirles que lo eliminen porque es una muy mala práctica que las extensiones anulen las opciones de depuración de su CMS.

En SlickStack, creamos un script bash que "banderas" cualquier ini_sety error_reportinglíneas de un fichero PHP en la cara /themes/y /plugins/directorios, poniendo de relieve esas instancias con un plugin de MU (script PHP) que muestra una lista de estos "cortes" en el tablero de instrumentos de administración de WP.

Jesse Nickles
fuente