Definir WP_DEBUG condicionalmente / solo para administradores / registrar errores (¿agregar parámetro de consulta para todos los enlaces?)
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!

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. :)

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!

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.

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

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ó.

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.

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.

@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.

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.

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 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.

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

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.

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
