Включение WP_DEBUG только для администраторов / условно / логирование ошибок (добавление query параметра для всех ссылок?)
Я разрабатываю сайт на сервере, к которому также имеет доступ клиент, и хотелось бы показывать WP_DEBUG
только для администраторов. Ссылаясь на статью Yoast о возможном решении:
if ( isset($_GET['debug']) && $_GET['debug'] == 'true')
define('WP_DEBUG', true);
будет показывать WP_DEBUG
только для URL-адресов с параметром ?debug=true
, например http://domain.com/?debug=true
Я думал, что Debug Bar может содержать эту информацию по умолчанию (включен ли WP_DEBUG
), но, похоже, я ошибался, так как это не так.
Поэтому я подумал, что было бы полезно проверять текущего пользователя (имеющего право manage_options
) и затем обрабатывать ссылки через add_query_arg()
:
function zs_admin_debug() {
if (!current_user_can('manage_options')) {
add_query_arg('debug','true');
}
}
но я не уверен - есть ли хук, который я могу использовать, чтобы применить это ко всем ссылкам на сайте? Таким образом, администраторы всегда будут видеть отладочную информацию, что, на мой взгляд, было бы крайне полезно. Спасибо за любую помощь!
Я не думаю, что существует универсальный хук для URL. Существует множество хуков, и, возможно, я что-то упустил, но универсального хука, похоже, нет. Вы можете просмотреть список хуков на adambrown.info. Там много хуков, связанных с URL, но универсального среди них нет.
Если позволите, предложу альтернативное решение: записывайте ошибки в файл.
/**
* Это будет записывать все ошибки, уведомления и предупреждения в файл debug.log
* в папке wp-content (если у Apache нет прав на запись, возможно, потребуется
* создать файл вручную и установить соответствующие права (например, 666))
*/
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
@ini_set('display_errors', 0);
Этот код взят прямо из Codex для файла wp-config.php. Если вы сделаете так, вам не придётся беспокоиться о работе с $_GET
или разбираться, кто является администратором, а кто нет.
Обновление:
Я забыл об одном возможном решении. Вы можете сделать это с помощью JavaScript. Небольшой скрипт может добавить ваш параметр ко всем URL на странице, и вы можете легко загружать этот скрипт только для администраторов.
Я всё же рекомендую решение с логом, поскольку ошибки будут записываться для всех. Если ваши сотрудники такие же, как мои, и отправляют отчёты об ошибках вроде "эй, сайт ломается, когда заполняешь ту форму", вы оцените наличие лога. :)

Наверное, я просто избалован тем, что вижу их на экране :) но лог-файл действительно больше подходит в данном случае. Проведу ещё немного исследований, но это пока лучшее решение, с которым я столкнулся. Спасибо!

Обратите внимание, что нативное логирование по умолчанию записывает в файл, доступный из веба, что не очень хорошая идея для продакшена. Лучше настроить расположение приватного (вне веб-папки) лог-файла через средства PHP для рабочих сайтов.

Хотя мой первый подход оказался мусорным, а ответ s_ha_dum представляет собой чистое и, вероятно, лучшее решение, позвольте предложить еще один рабочий вариант:
Следующий код устанавливает cookie, действительный в течение следующих 24 часов (86400 секунд), когда администратор входит в систему. В файле wp-config.php константа WP_DEBUG
условно определяется в зависимости от наличия и значения этого cookie.
Примечание: WP_DEBUG
будет установлен в true
для всех, кто входит в систему с того же браузера на том же компьютере в течение того же дня.
В functions.php (или в виде плагина):
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 );
См.: Codex > Action Reference > wp_login
В wp-config.php:
if ( isset( $_COOKIE['wp_debug'] ) && 'on' === $_COOKIE['wp_debug'] ) {
define( 'WP_DEBUG', true );
} else {
define( 'WP_DEBUG', false );
}

Эндрю Нацин прокомментировал эту статью, упомянув, что init
уже слишком поздно для какого-либо эффекта. Я также пробовал это, и это не сработало.

Константы не могут быть переопределены. Можно изменить уровень отчетности об ошибках, не трогая константу, но это не идеально. Кроме того, много чего происходит до init
, что представляет интерес.

Я считаю, что принятый ответ остается наиболее жизнеспособным решением, тем не менее, для полноты картины, этот новый подход должен справиться с отображением отладочных уведомлений на экране.

@s_ha_dum: Не то чтобы каждый ответ помнишь — по крайней мере, я нет (я даже гуглил свои собственные ответы). Но этот запомнил. Я был первым, кто ответил, и написал полную ерунду. Совершенно не подходило. Я придерживаюсь правила не отвечать, если я хотя бы на 99,5% не уверен, что квалифицирован (предполагаю, у вас то же самое) — а тут я сильно промахнулся. Это вывело меня из себя по-серьёзному, поэтому через несколько часов, когда уже был принятый ответ, я всё ещё размышлял над этим вопросом и придумал решение выше. Мне тоже кажется, что оно довольно изящное — спасибо, что заметили.

Это не совсем точно отвечает на ваш вопрос, но из личного опыта я обнаружил, что лучше включать режим отладки по совпадению IP-адреса, а не по URL.
Это требует модификации ссылок и решает проблему идентификации администратора до того, как WordPress загрузит необходимую пользовательскую функциональность.

Мне тоже нравится эта идея - так что если я сделаю что-то вроде http://pastebin.com/m22KNakh, это... в теории может сработать, верно? Выполнение echo $_SERVER['REMOTE_ADDR']
возвращает ::1
, что ожидаемо на localhost? Честно говоря, звучит как отдельный лог-файл, и такой способ (поскольку домашние IP, кажется, меняются постоянно) может быть хорошей идеей.

@Zach да, ::1
— это просто IPv6 версия 127.0.0.1
. Динамический IP делает это менее удобным, но в любом случае я рассматриваю это как временный метод диагностики для рабочего окружения. Это не заменяет правильную настройку локальной отладки.

Если у вас статический IP-адрес, вы можете сделать так:
if ('ВАШ_IP_АДРЕС' == $_SERVER['REMOTE_ADDR']) {
define('WP_DEBUG', true);
} else {
define('WP_DEBUG', false);
}
Источник: ОТЛАДКА WORDPRESS – КАК ИСПОЛЬЗОВАТЬ WP_DEBUG НА ПРОДУКЦИОННОМ САЙТЕ

Это также возможный трюк, но вам нужно добавить это в ваш файл wp-config.php
, так как WP_DEBUG
определен именно там:
if ( isset( $_GET['debugsecret'] ) && 'debugsecret' == $_GET['debugsecret'] ) {
define( 'WP_DEBUG', true );
}
Добавьте ?debugsecret=debugsecret
к URL страницы, которую вы хотите отладить.

В качестве ещё одного варианта, я объединил несколько решений. Этот способ позволяет мгновенно изменить состояние режима отладки (включен / выключен) на один час с помощью параметра URL, а также ограничить, кто может выполнить изменение по IP.
Замените строку WP_DEBUG в wp-config.php на эту:
//Установите режим отладки по умолчанию. Обычно он должен быть false
$CURRENT_DEBUG_MODE=false;
//раскомментируйте, чтобы установить ограничение по IP.
//$DEVEL_IP_ADDRESS = 'ВАШ IP';
//используйте cookie для установки режима отладки на 1 час с помощью параметра URL ?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);
Добавьте к любому URL страницы ?debugmode=on
, чтобы включить отладку (если она выключена), и ?debugmode=off
, чтобы выключить её.
