In-Portal Developers Guide

This is a wiki-based Developers Guide for In-Portal Open Source CMS. The purpose of this guide is to provide advanced users, web developers and programmers with documentation on how to expand, customize and improve the functionality and the code the In-Portal software. Please consider contributing to our documentation writing effort.

K4:Debugger

From In-Portal Developers Guide

Revision as of 14:59, 25 December 2008 by Alex (Talk)
(diff) ←Older revision | Current revision (diff) | Newer revision→ (diff)
Jump to: navigation, search
Отладка приложения Отладка приложения
Статьи в этой категории
  • Debugger

Неотъемлемой частью процесса программирования является тестирование кода. Незаменимую помощь в этом процессе оказывает возможность отладки кода в реальном времени предоставляемая программным продуктом Zend Studio. Несмотря на это бывают ситуации, когда требуется оперативно получить требуемую информацию не запуская Zend Debugger. A иногда он просто не доступен из-за того, что сайт уже выложен на live/dev сервер и требуется устранить проблему на месте. В таком случае Ваш верный друг, это debugger, встроенный в K4.

Contents

Что такое Debugger

Debugger - это плотно интегрированный с K4 скрипт, который накапливает информацию о ходе выполнения скрипта в файл отчёта и потом (уже после показывания страницы пользователю) позволяет вывести этот отчёт на экран. Сам отчёт хранится на сервере и не загружается вместе со страницей и тем самым не задерживает её загрузку. При нажатии на F12 посылается AJAX запрос (без перезагрузки страницы) на сервер и полученный отчёт отображается в элементе типа div (он же Debugger Layer). Отчёт можно спрятать ещё раз нажав F12 или ESC. В браузерах, построенных на движке IE (напр. Maxthorn, MyIE2, и т.п.) может не работать событие OnKeyDown для функциональных клавиш (F1-F12). Чтобы пользоваться debugger в таком браузере надо использовать debugger toolbar (опция DBG_TOOLBAR_BUTTONS, в админе всегда включена).

Debugger накапливает разнообразную информацию в процессе работы скрипта. Вот лишь малая её часть:

  • sql запросы сделанные к базе данных
  • время выполнения каждого sql запроса
  • количество обращений к базе данных
  • потребление оперативной памяти сервера скриптом
  • общее время работы скрипта

Так-же собирается и другая информация, которая после выполнения скрипта позволяет проанализировать результаты его работы.

Распечатка массива $_REQUEST

Каждая из колонок на изображении так или иначе характеризует переменную:

название колонки описание колонки
Src Местонахождение переменной:
  • GE - $_GET;
  • PO - $_POST;
  • CO - $_COOKIE.
Name Название переменной.
Value Значение переменной.

Всегда будет переменная с именем env (кроме случая, когда включён mod-rewrite режим). Это "переменная окружения" (environment) для K4. Правильно понимая что в ней находиться можно понять какое действие будет предпринимать K4 если в него передать то или иное значение данной переменной. Более подробную информацию о переменных в окружении можно получить по этой ссылке.

Переменная окружения содержит:

  1. идентификатор сессии (SID), если он не находится в cookie
  2. текущий шаблон (template), если он напрямую не передан из $_POST
  3. индивидуальные переменные окружения от пользовательских префиксов

Если рассмотреть изображённый выше пример, то получится, что

  1. идентификатор сессии: отсутствует
  2. шаблон: in-portal/users/users_list
  3. индивидуальные переменные окружения: m0--1--r- (это переменные для префикса "m")
Пример данных из запроса пользователя
Пример данных из запроса пользователя

Распечатка kHTTPQuery

Содержание реестра kHTTPQuery
Содержание реестра kHTTPQuery

Левее приведён один из возможных примеров распечатки результата работы класса kHTTPQuery. Содержание изображённого массива может варьироваться в зависимости от входных параметров K4. Более подробная информация о том что откуда берётся в данном массиве доступна по этой ссылке.

Распечатка сессии

Данные для распечатки берутся из того момента, когда скрипт закончил свою работу.

Результат распечатки сессии чем-то похож на результат распечатки kHTTPQuery. Визуально так оно и есть. Правда в сессии не хранятся массивы, из-за этого их приходится сворачивать (serialize) перед записью в сессию и из-за этого их не очень удобно читать. Поэтому перед показыванием содержания сессии проверяется значение каждой переменной на предмет присутствия в нём serialized массива и если так, то просто показывается его развёрнутая (unserialized) версия. Само содержание сессии может варьироваться от проекта к проекту, но есть переменные, которые будут всегда. К числу таких переменных можно отнести:

название переменной описание переменной
user_id ID текущего пользователя (важно его брать именно отсюда, а не из kHTTPQuery)
admin пометка о том, что это админовская сессия (не говорит о том прошёл пользователь идентификацию или нет)

Для проверки в админе мы или нет надо использовать метод Application->IsAdmin. Для того чтобы определить прошёл пользователь идентификацию или нет надо использовать метод Application->LoggedIn. За полным списком переменных, доступных в сессии следует обратиться к этой статье.

Пример данных из сессии
Пример данных из сессии

Вывод SQL запросов

Вывод SQL запроса.
Вывод SQL запроса.

Если опция DBG_SQL_PROFILE включена, то каждый SQL запрос будет попадать в отчёт отладчика. О каждом запросе будет выведена следующая информация:

  • его содержание, которое будет отформатировано для наглядности независимо от того был ли сам запрос отформатирован в PHP коде;
  • его время выполнения в секундах;
  • файл и строка, откуда запрос был вызван (т.е. было обращение к методам класса kDBConnection).

Под каждым запросом также отображается:

  • общее время всех запросов (длинна полосы);
  • общее время всех запросов до этого запроса (синяя полоса);
  • время выполнения этого запроса на фоне остальных запросов (красная полоса);
  • время, оставшееся для выполнения остальных запросов (серая полоса).

Вывод php ошибок

Если используется отладчик, то он перехватывает все происходящие во время работы скрипта ошибки (напр., о неопределенных переменных, ключах массива, и т.п.) и добавляет их в свой отчёт. Их также будет видно и в Zend Debugger, когда он будет использоваться. О каждой ошибке известно:

  • важность (Notice, Warning, Fatal Error);
  • текст ошибки
  • источник ошибки (файл и строка).

Название файла является ссылкой на открытие его во внешнем редакторе (см. расширение Launchy). Сам отладчик понимает передачу строки с ошибкой в редактор, но [Zend Studio этого не понимает. Из-за этого он будет всегда открывать новый файл (который ещё не открыт в редакторе) на первой строке. Для устранения данной проблемы рекомендуется после открытия файла нажать Ctrl+G (Go To Line) и ввести туда номер строки самому.

Настройка

Настройка производиться через указание значений опций (ключей) массива $dbg_options в файле debug.php. Ниже приведены все возможные опции, при помощи которых можно контролировать то что попадает в отчёт debugger и как это будет выглядеть, а также их значение по умолчанию.

название опции описание опции значение по умолчанию
DBG_IP Разделённый точкой с запятой список IP адресов, для которых разрешён debug mode (можно использовать адреса подсетей) 193.68.72.64/26
DEBUG_MODE Включён или выключен debug mode (надо указать опцию DBG_IP для того, чтобы эта опция работала 0
DBG_LOCAL_BASE_PATH Название папки на mapped диске где лежат сайты w:
DBG_DOMVIEWER путь к DOMViewer скрипту /temp/domviewer.html
DBG_TOOLBAR_BUTTONS Показывать-ли панель инструментов debugger на Front-End 0
DBG_USE_HIGHLIGHT Использовать функцию highlight_string для оформления отчёта debugger 1
DBG_RAISE_ON_WARNINGS Показывать отчёт debugger при наличии любых некритичных ошибок (Notice, Warning) 0
DBG_HANDLE_ERRORS Выводить все ошибки на сайте в отчёт вместо экрана 1
DBG_SQL_PROFILE Показывать все SQL запросы и аналитическую информацию о них в отчёте 1
DBG_SQL_EXPLAIN Добавлять результат анализа (explain) запроса после текста самого запроса в отладчик. Доступно с Core v 4.3.1. 0
DBG_SQL_FAILURE Рассматривать SQL ошибки как Fatal Error для PHP 1
DBG_SHOW_HTTPQUERY Показывать содержание kHTTPQuery 1
DBG_SHOW_SESSIONDATA Показывать содержание сессии 1
DBG_SHOW_PERSISTENTDATA Показывать содержание постоянной сессии (по ID пользователя) 0
DBG_EDIT_HELP Показывать название файла справки (help filename) на экране со справкой 0
DBG_HELP Показывать FCK редактор на экране со справкой 0
DBG_FORCE_THEME Всегда использовать это ID темы, вместо того, что в передано в url -
DBG_PHRASES Показывать не переведённые фразы в виде ссылок на форму для их перевода 1
DBG_WINDOW_WIDTH Ширина отчёта debugger (в пикселях) 700
DBG_REDIRECT Показывать ссылку для ручного перенаправления (redirect) вместо автоматического перенаправления (для отладки собственно перенаправлений после событий 0
DBG_VALIDATE_CONFIGS Проверять unit configs на предмет совпадения со структурой таблиц в базе данных -
DBG_SHOW_TAGS Показывать тэги, которые обрабатываются на текущем шаблоне 0
DBG_PRE_PARSE Показывать тело заново скомпилированных блоков 0
DBG_DECORATE_BLOCKS Рисовать div с подсказкой (в виде tooltip с именем блока) вокруг каждого блока, прошедшего через метод kApplication:ParseBlock. Помогает определить название блока, который используется на шаблоне. Доступно с Core v 4.3.0.
DBG_SHOW_TREE_PRIORITY Показывать приоритет секций в дереве 0
DBG_SKIP_AJAX Не сохранять отчёты от AJAX запросов 0
DBG_PAYMENT_GW Все запросы к payment gateway будут в TEST MODE -
DBG_IMAGE_RECOVERY Не заменять отсутствующие картинки на noimage.gif 0
DBG_SQL_MODE Проверка всех SQL запросов на валидность (только в MySQL 5+) -
DBG_FAST_INSTALL Ускоренная инсталляция (только для In-Portal) -
DBG_USE_SHUTDOWN_FUNC Выводить отчёт на экран используя функцию register_shutdown_function 1
DBG_CACHE Показывать статистику использования внутреннего кеша, который можно использовать через методы kАpplication::getCache и kАpplication::setCache. 0

Помимо опций, касающихся debugger в файле debug.php находятся несколько полезных констант:

название константы описание константы
SILENT_LOG записывать все ошибки, происходящие на сайте в специальный файл (FULL_PATH.'/silent_log.txt')
DBG_REQUREST_LOG записывать все обращения к сайту (только от зарегистрированных пользователей) в указанный файл (FULL_PATH.'/'.<value>)
DBG_SITE_PATH принудительно заданный альтернативный путь к сайту из браузера (только для In-Portal)
DBG_ZEND_PRESENT не выключать debugger при использовании Zend Studio (нужно для отладки debugger)
SA_IP Список IP адресов с которых можно заходить на сайт в режиме SUPER ADMIN (193.68.72.64/26)
DBG_CAPTURE_STATISTICS Говорит о том, что требуется собирать информацию о нагрузке, которую скрипт производит на сервер и писать её (информацию) в таблицы StatisticsCapture (производительность) и SlowSqlCapture (самые медленные запросы). Доступно с Core v 4.3.1.
Image:Infobox Icon.gif Работает только при выключенном debug mоde.
DBG_MAX_SQL_TIME Максимально допустимое время выполнения одного запроса к базе данных, превысив которое запрос считается медленным (slow query). Данные об этих запросах попадают в таблицу SlowSqlCapture. Задаётся в секундах. Доступно с Core v 4.3.1.
Image:Infobox Icon.gif Работает только при выключенном debug mоde.
DBG_EMAIL Эта опция позволяет указывать почтовый адрес, куда должны приходит все отсылаемые системой письма. Указанный адрес будет заменять собой установленный в письме адрес получателя. Если в качестве значения данной опции указать домен, начинающийся с "@" то:
  • символ "@" в почтовом адресе получателя будет заменён на "_at_";
  • указанный в данной опции домен будет добавлен к полученной строке.

Например при значении опции равном "@test.com" и адресе получателя равном "to_email@sample.com" получиться "to_email_at_sample.com@test.com". Доступно с Core v 5.0.0.

Объявление всех констант кроме SA_IP закомментировано. Для использования той или иной константы надо раскомментировать её декларацию.

Image:Tipbox Icon.gif Поскольку данные, накопленные при использовании константы DBG_REQUREST_LOG могут содержать конфиденциальную информацию клиентов сайта, то НЕ РЕКОМЕНДУЕТСЯ хранить этот файл под DocumentRoot сайта.

Добавление пользовательской информации в отчёт

У объекта Application->Debugger есть общедоступные методы для добавления пользовательской информации в его отчёт.

название метода описание метода
appendHTML Позволяет добавлять любой HTML код.
appendTrace Добавляет весь путь до выполнения метода (см. описание функции debug_backtrace, чтобы понять что будет добавлено).
dumpVars Позволяет вывести содержание любого количества переменных в отчёт. Если задать последним параметром слово STRICT, то будет видно и тип переменной.
highlightString Отформатировать переданную строку как PHP код.
ProfilePoint Позволяет узнать откуда и сколько раз вызывается указанный метод (тот метод, из которого вызван этот).

Все методы, которые начинаются со слова append, добавляют свой результат в отчёт в том месте, где их вызывали, а не в конец отчёта.