Definir WP_DEBUG condicionalmente / solo para administradores / registrar errores (¿agregar parámetro de consulta para todos los enlaces?)

17 oct 2012, 16:16:40
Vistas: 19.7K
Votos: 22

Estoy desarrollando un sitio en un servidor al que el cliente también tiene acceso y me gustaría mostrar WP_DEBUG solo para administradores. Haciendo referencia al artículo de Yoast sobre una forma de hacer esto:

if ( isset($_GET['debug']) && $_GET['debug'] == 'true')
    define('WP_DEBUG', true);

esto mostraría WP_DEBUG solo para URLs que tengan ?debug=true adjunto, como http://domain.com/?debug=true

Estaba pensando que la Barra de Depuración podría tener algo de esta información por defecto (si WP_DEBUG está activado o no), pero creo que estaba equivocado ya que no creo que ese sea el caso.

Entonces, lo que pensé que sería útil, sería una verificación del usuario actual (que tenga la capacidad manage_options y luego procesar los enlaces a través de add_query_arg():

function zs_admin_debug() {
    if (!current_user_can('manage_options')) {
        add_query_arg('debug','true');
    }
}

pero de lo que no estoy seguro es - ¿hay algún gancho que pueda usar para afectar todos los enlaces de un sitio con esto? De esta manera, los administradores siempre verían la depuración, lo que pensé que sería extremadamente útil. ¡Gracias por cualquier ayuda como siempre!

1
Comentarios

Esta solución (de Yoast) es extremadamente útil para depuración al vuelo. También habilité el registro de logs que funciona bien. Modifiqué ligeramente mi código: if ( isset( $_GET['bug'] ) ) así que visito link/?bug para ver la depuración :)

Jarod Thornton Jarod Thornton
3 mar 2017 05:13:21
Todas las respuestas a la pregunta 6
3
17

No creo que exista un hook universal para URLs. Hay muchos hooks y puede que me haya pasado alguno, pero no creo que exista uno universal. Puedes revisar los hooks en adambrown.info. Hay muchos hooks relacionados con URLs, pero no uno universal.

Si me permites sugerir otra solución: registra los errores en un archivo.

/**
 * Esto registrará todos los errores, avisos y advertencias en un archivo llamado debug.log
 * dentro de wp-content (si Apache no tiene permisos de escritura, puede que necesites crear
 * el archivo primero y establecer los permisos apropiados (ej. usar 666))
 */
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors',0);

Ese código viene directamente de el Codex para el archivo wp-config.php. Si haces esto, no tendrás que preocuparte por manejar $_GET o determinar quién es y quién no es un administrador.

Edición:

Olvidé una posible solución. Puedes hacer esto con Javascript. Un pequeño script podría añadir tu parámetro a todas las URLs en la página, y puedes cargar el script fácilmente solo para los administradores.

Igual sugeriría la solución de 'registro' ya que los errores de todos quedan registrados. Si tu gente es como la mía y envía reportes de errores como "oye, el sitio se rompe cuando haces ese formulario", agradecerás tener el registro. :)

17 oct 2012 16:33:09
Comentarios

Supongo que estoy malcriado al verlos en la pantalla :) pero un archivo de registro tiene más sentido aquí. Investigaré un poco más por mi parte, pero esta parece ser la mejor solución que he encontrado hasta ahora. ¡Gracias!

Zach Zach
17 oct 2012 17:42:08

Ten en cuenta que el registro nativo está codificado para registrar en un archivo accesible desde la web, lo cual no es una buena idea en producción. Es mejor configurar una ubicación de archivo de registro privado (fuera de la carpeta web) mediante medios PHP para sitios en vivo.

Rarst Rarst
17 oct 2012 17:51:55

@Rarst +1!!! Y a partir de la versión 5.1 ahora podemos especificar la ubicación muy fácilmente, define('WP_DEBUG_LOG', '/ruta/del/servidor/aqui/debug.log');

deflime deflime
10 jun 2022 03:16:17
5
10

Aunque mi primer enfoque fue al basurero y la respuesta de s_ha_dum es una forma limpia, y probablemente la mejor, de abordarlo, permíteme ofrecer un escenario más funcional:

Lo siguiente establece una cookie válida por las próximas 24 horas (86400 segundos) cuando un administrador inicia sesión en el sistema. En wp-config.php, la constante WP_DEBUG se define condicionalmente dependiendo de la presencia y valor de dicha cookie.

Advertencia: WP_DEBUG se establecerá en true para todos los que inicien sesión desde el mismo navegador en la misma máquina durante el mismo día.

en functions.php (o como un plugin):

function wpse_69549_admin_debug( $user_login, $user )
{
    if ( in_array( 'administrator', $user->roles ) ) {
        setcookie( 'wp_debug', 'on', time() + 86400, '/', get_site_option( 'siteurl' ) );
    }
}
add_action( 'wp_login', 'wpse_69549_admin_debug', 10, 2 );

Ver: Codex > Referencia de Acciones > wp_login

en wp-config.php:

if ( isset( $_COOKIE['wp_debug'] ) && 'on' === $_COOKIE['wp_debug'] ) {
    define( 'WP_DEBUG', true );
} else {
    define( 'WP_DEBUG', false );
}
17 oct 2012 17:42:07
Comentarios

Andrew Nacin comentó en ese artículo, mencionando que init es demasiado tarde para tener algún efecto. También probé esto y no funcionó.

Zach Zach
17 oct 2012 17:45:24

Las constantes no pueden redefinirse. Uno podría modificar el nivel de reporte de errores sin tocar la constante pero no es perfecto. Además hay muchas cosas que suceden antes de init que son de interés.

Rarst Rarst
17 oct 2012 17:46:33

Creo que la respuesta aceptada sigue siendo la solución más viable, sin embargo, en aras de la exhaustividad, este nuevo enfoque debería funcionar con los avisos de depuración en pantalla.

Johannes Pille Johannes Pille
17 oct 2012 19:33:08

Muy buena solución alternativa - definitivamente voy a probar esto

Zach Zach
17 oct 2012 23:53:39

@s_ha_dum: No es como si uno recordara cada respuesta - al menos yo no (he buscado en Google mis propias respuestas antes). Esta en particular sí la recuerdo. Fui el primero en responder y había escrito una completa tontería. No aplicaba en absoluto. Sigo una política de no responder a menos que esté al menos 99.5% seguro de estar calificado (supongo que lo mismo aplica para ti) - aquí me había equivocado totalmente. Eso me molestó muchísimo, así que unas horas después, cuando ya tenía una respuesta aceptada, seguía pensando en esto y se me ocurrió lo de arriba. A mí también me parece bastante ingenioso - gracias por notarlo.

Johannes Pille Johannes Pille
25 mar 2013 02:10:58
3

No responde exactamente a tu pregunta, pero por experiencia personal he encontrado que es mejor habilitar el modo de depuración coincidiendo con la dirección IP en lugar de la URL.

Esto requiere modificación de enlaces y resuelve cómo identificar al administrador antes de que WordPress cargue la funcionalidad de usuario requerida.

17 oct 2012 17:50:28
Comentarios

Realmente también me gusta esta idea, así que si hago algo como http://pastebin.com/m22KNakh eso podría... en teoría funcionar, ¿correcto? Ejecutar echo $_SERVER['REMOTE_ADDR'] devuelve ::1 que es lo esperado en localhost? Honestamente suena como un archivo de registro separado y esta forma (ya que las IPs domésticas parecen cambiar todo el tiempo) podría ser una buena idea.

Zach Zach
17 oct 2012 18:05:40

@Zach sí, ::1 es simplemente la versión IPv6 de 127.0.0.1. Las IP dinámicas lo hacen menos conveniente, pero de todos modos solo lo trato como una técnica temporal para solucionar problemas en producción. No reemplaza una configuración de depuración local adecuada.

Rarst Rarst
17 oct 2012 18:19:33

Ah, gracias por la información. Definitivamente me gustan ambas opciones aquí, voy a optar por la respuesta de @s_ha_dum (además de tu comentario que voté a favor) que también es genial. ¡Gracias de nuevo, realmente lo aprecio!

Zach Zach
17 oct 2012 18:21:34
0

Si tienes una IP estática, puedes hacer esto:

if ('TU_DIRECCION_IP' == $_SERVER['REMOTE_ADDR']) {
    define('WP_DEBUG', true);
} else {
    define('WP_DEBUG', false);   
}

Fuente: DEPURACIÓN EN WORDPRESS – CÓMO USAR WP_DEBUG EN SITIO EN PRODUCCIÓN

27 jun 2018 21:00:00
0

Este también es un truco posible, pero necesitas colocar esto en tu archivo wp-config.php ya que WP_DEBUG se define ahí:

if ( isset( $_GET['debugsecret'] ) && 'debugsecret' == $_GET['debugsecret'] ) {
      define( 'WP_DEBUG', true );         // Activa el modo de depuración si el parámetro debugsecret coincide
}

Añade ?debugsecret=debugsecret a la URL de la página que deseas depurar.

24 abr 2016 04:05:07
0

Para agregar otra opción, hice una combinación de varias respuestas. Esta te permite cambiar instantáneamente el estado del modo debug (activado/desactivado) por una hora con un parámetro en la URL y también restringir quién puede hacer el cambio por IP.

Reemplaza tu línea WP_DEBUG en wp-config.php con esto:

//Establece el modo debug por defecto. Normalmente debería ser false
$CURRENT_DEBUG_MODE=false;
//descomenta para establecer una restricción por IP
//$DEVEL_IP_ADDRESS = 'TU IP';

//usa cookies para establecer el modo debug por 1 hora con el parámetro ?debugmode = [on,off]
if (!isset($DEVEL_IP_ADDRESS) || $DEVEL_IP_ADDRESS == $_SERVER['REMOTE_ADDR'])
{
    if (isset($_GET['debugmode'])) {
        $CURRENT_DEBUG_MODE = 'on'==$_GET['debugmode']?true:false;
        setcookie("wp_debugmode", $_GET['debugmode'],time()+3600,'/');
    }
    else if (isset($_COOKIE['wp_debugmode'])) {$CURRENT_DEBUG_MODE = 'on'==$_COOKIE['wp_debugmode']?true:false;}
}
define('WP_DEBUG', $CURRENT_DEBUG_MODE);

Añade a cualquier URL de la página ?debugmode=on para activar el debug (si está desactivado) y ?debugmode=off para desactivarlo

22 feb 2021 12:17:22