Самый интересный вопрос для любого разработчика: «Что там, внутри моего кода, на самом деле происходит с данными?». Потому, что реальность иногда отличается от задумки из-за стратегических, логических и синтаксических ошибок в коде. И чтобы привести их в соответствие, нужно знать, какие данные поступают на вход той или иной части скрипта, и какие результаты обработки данных получаются на выходе.
«Расширенная отладка» предлагает два варианта получения такой информации:
1. Для основных операций можно посмотреть их данные и/или результаты при помощи мышки, без какой-либо правки кода.
2. Для любых мест в коде скрипта увидеть вообще любые данные – при помощи вставки всего одной команды.
В этой части мы рассмотрим первую возможность.
Чтобы посмотреть эти строки обычным образом, нам нужно было бы по трассировке найти место в коде, где вызывается этот запрос. Потом пройти по коду чуть дальше, туда, где из объекта-результата запроса получается массив (если такое есть в коде) и только потом вывести этот массив на экран операторами echo var_dunp или print_r в текущем месте страницы в вперемешку с её элементами. Да ещё нужно условиями ограничить вывод только нужного запроса.
Вот какую кашу выдаёт "удобочитаемая" функция" print_r, если её вывод не обернуть дополнительно в теги <pre>.
И это данные запроса, возвращающего всего одну строку!
А вот более разборчивый вариант внутри тегов <pre>:
Если бы запрос был не в виджете, а внутри какого-то шаблона, тогда весь этот вывод был бы внутри его элементов на странице, разрушая вёрстку и визуально усложняя чтение.
А в случае, когда объект-результат запроса не преобразуется в массив целиком, а обрабатывается построчно, пришлось бы ставить такие конструкции кода для вывода внутри цикла, и тогда каша на странице из её элементов и вывода print_r могла быть ещё более крутой.
А что если посмотреть нужно на работающем сайте на хостинге? Например, при возникновении непоняток с компонентом на сайте в продакшене (это, конечно, крайне не рекомендуется делать, но иногда нужно). Тут вообще без вариантов, только писать свою обработку для вывода результатов запроса в текстовый лог на сервере и потом искать, какая же строка из него соответствует проблемной странице.
Давайте, для примера рассмотрим 11-й запрос из темы про трассировку — он возвращает всего одну строку, она поместится на небольшой скрин:
В строке лога добавилось поле с красиво оформленным, наглядным выводом уже преобразованного в массив результата этого запроса к БД.
Кликом мышки по ссылке под 'Result' можно развернуть или опять свернуть поле результата. Также можно заранее снять или включить галку "Сворачивать большие блоки данных и результатов в строках лога" на вкладке "Вид" в настройках отладки.
Можно выводить результаты для всех запросов или только для отобранных фильтрами. Хоть вообще только для одного нужного запроса. Естественно, результаты выводятся лишь для запросов на выборку, которые возвращают хотя бы одну строку. Для пустых запросов, запросов на изменение/удаление и ошибочных запросов выводить нечего.
Так же, как и в случае с SQL-запросами, чтобы посмотреть эти данные и результаты обычным образом, нужно в нескольких местах кода вписывать свои специализированные функции вывода этих данных. Это также приводит к сложностям и неудобствам.
В «Расширенной отладке» достаточно на вкладе «События и хуки» включить галку «Выводить в лог данные и результаты событий и хуков», и в лог будут выводиться не только описания событий и хуков, но и их данные/результаты тоже!
Например, данные и результаты хука 'menu_messages':
Мы сразу видим, что при возникновении события «меню уведомлений» 'menu_messages' происходит вызов хука 'menu_messages' в компоненте обработки сообщений 'messages', который во входных данных получает пункт меню уведомлений. И возвращает ссылку на чтение сообщений '[uгl] => /messages' и количество сообщений '[counter] => 0'
Или второй пример с другой частью того же меню — данные и результаты хука 'menu_groups':
Естественно, вы с помощью фильтров можете оставить в логе только интересующие вас события и хуки для большего удобства при их анализе.
Обратите внимание. При параллельной схеме обработки события, данные события для каждого хука остаются одинаковыми. И в логе эти данные хуков всегда совпадают с данными события. А при последовательной схеме данные от события передаются по цепочке от первого хука к последнему и на входе в каждый хук они могут отличаться от данных события. Поэтому в отладке сделан вывод и данных событий, и данных хуков.
Подробнее про схемы работы событий смотрите в посте Что такое события и хуки (без PHP и с картинками)
Справа от слова 'Result' в скобках показаны два числа: количество элементов массива на первом уровне и на всех уровнях вместе. Элементами считаются обычные значения, массивы, объекты или перечисляемые элементы объектов. Если объект не поддерживает перечисление (не countable), то его элементы не считаются.
В качестве примера посмотрим на виджет "Уведомления" для изученного выше меню уведомлений
Если интересно чуть лучше изучить виджеты, смотрите пост Как работают виджеты (без PHP и с картинками)
В первую очередь разработчикам компонентов и шаблонов, это понятно.
Во вторую, всем тем, кто начинает разбираться в работе Двойки или уже разобрался, но хочет уточнить детали.
В третью, всем пользователям, кто использует на своём сайте сторонние компоненты. Вы сможете отправлять логи разработчикам этих компонентов, чтобы они меньше мучили вас вопросами, зато имели более точную и полную картину происходящего.
Теперь вы в любой момент, на локальной копии и на работающем сайте, при изучении и при отладке сможете посмотреть данные и результаты основных операций в InstantCMS 2 всего несколькими щелчками мышки без любого вмешательства в код системы. Надеюсь, вам этот инструмент будет так же полезен, как мне.
Обратите внимание! Поскольку выводимые данные и результаты обрабатываются функциями подсветки, то их вывод может тормозить как работу сервера, так и рендеринг страницы в браузере. Включайте эту возможность только при необходимости.
«Расширенная отладка» предлагает два варианта получения такой информации:
1. Для основных операций можно посмотреть их данные и/или результаты при помощи мышки, без какой-либо правки кода.
2. Для любых мест в коде скрипта увидеть вообще любые данные – при помощи вставки всего одной команды.
В этой части мы рассмотрим первую возможность.
Есть же var_dump и print_r! В чём проблема пользоваться ими?
В посте «Использование расширенной отладки. Часть 4. Трассировка» мы рассматривали пример SQL-запроса на главной странице демо-сайта. И увидели в информации о запросе, что он был успешным и вернул пять строк. Но вот вопрос: какие?Чтобы посмотреть эти строки обычным образом, нам нужно было бы по трассировке найти место в коде, где вызывается этот запрос. Потом пройти по коду чуть дальше, туда, где из объекта-результата запроса получается массив (если такое есть в коде) и только потом вывести этот массив на экран операторами echo var_dunp или print_r в текущем месте страницы в вперемешку с её элементами. Да ещё нужно условиями ограничить вывод только нужного запроса.
Вот какую кашу выдаёт "удобочитаемая" функция" print_r, если её вывод не обернуть дополнительно в теги <pre>.
И это данные запроса, возвращающего всего одну строку!
А вот более разборчивый вариант внутри тегов <pre>:
Но чтобы это вывести пришлось нагородить вот такой код:
А в случае, когда объект-результат запроса не преобразуется в массив целиком, а обрабатывается построчно, пришлось бы ставить такие конструкции кода для вывода внутри цикла, и тогда каша на странице из её элементов и вывода print_r могла быть ещё более крутой.
А что если посмотреть нужно на работающем сайте на хостинге? Например, при возникновении непоняток с компонентом на сайте в продакшене (это, конечно, крайне не рекомендуется делать, но иногда нужно). Тут вообще без вариантов, только писать свою обработку для вывода результатов запроса в текстовый лог на сервере и потом искать, какая же строка из него соответствует проблемной странице.
Данные, возвращаемые из SQL-запросов
«Расширенная отладка» предлагает намного более простой и наглядный вариант. Достаточно зайти на вкладку «База данных» страницы настроек отладки, и включить галку «Выводить в лог результаты SQL-запросов». И всё! После сохранения настроек можно обновлять исследуемую страницу и смотреть результаты.Давайте, для примера рассмотрим 11-й запрос из темы про трассировку — он возвращает всего одну строку, она поместится на небольшой скрин:
В строке лога добавилось поле с красиво оформленным, наглядным выводом уже преобразованного в массив результата этого запроса к БД.
Кликом мышки по ссылке под 'Result' можно развернуть или опять свернуть поле результата. Также можно заранее снять или включить галку "Сворачивать большие блоки данных и результатов в строках лога" на вкладке "Вид" в настройках отладки.
И это всё делается без программирования, несколькими кликами мышки!
Можно выводить результаты для всех запросов или только для отобранных фильтрами. Хоть вообще только для одного нужного запроса. Естественно, результаты выводятся лишь для запросов на выборку, которые возвращают хотя бы одну строку. Для пустых запросов, запросов на изменение/удаление и ошибочных запросов выводить нечего.
Данные и результаты хуков
Дальше становится ещё интереснее. 😉 Как мы знаем из документации, при работе CMS происходят события (events), которые перехватываются хуками (hooks). При этом события передают определённые данные хукам, а хуки после обработки возвращают свои результаты обратно в источники событий для дальнейшей работы с ними.Так же, как и в случае с SQL-запросами, чтобы посмотреть эти данные и результаты обычным образом, нужно в нескольких местах кода вписывать свои специализированные функции вывода этих данных. Это также приводит к сложностям и неудобствам.
В «Расширенной отладке» достаточно на вкладе «События и хуки» включить галку «Выводить в лог данные и результаты событий и хуков», и в лог будут выводиться не только описания событий и хуков, но и их данные/результаты тоже!
Например, данные и результаты хука 'menu_messages':
Мы сразу видим, что при возникновении события «меню уведомлений» 'menu_messages' происходит вызов хука 'menu_messages' в компоненте обработки сообщений 'messages', который во входных данных получает пункт меню уведомлений. И возвращает ссылку на чтение сообщений '[uгl] => /messages' и количество сообщений '[counter] => 0'
Или второй пример с другой частью того же меню — данные и результаты хука 'menu_groups':
Точно так же видно, что хук получает пункт меню и возвращает массив пунктов для создания подменю "Мои группы"
Естественно, вы с помощью фильтров можете оставить в логе только интересующие вас события и хуки для большего удобства при их анализе.
Обратите внимание. При параллельной схеме обработки события, данные события для каждого хука остаются одинаковыми. И в логе эти данные хуков всегда совпадают с данными события. А при последовательной схеме данные от события передаются по цепочке от первого хука к последнему и на входе в каждый хук они могут отличаться от данных события. Поэтому в отладке сделан вывод и данных событий, и данных хуков.
Подробнее про схемы работы событий смотрите в посте Что такое события и хуки (без PHP и с картинками)
Справа от слова 'Result' в скобках показаны два числа: количество элементов массива на первом уровне и на всех уровнях вместе. Элементами считаются обычные значения, массивы, объекты или перечисляемые элементы объектов. Если объект не поддерживает перечисление (не countable), то его элементы не считаются.
Данные и результаты виджетов
Если на вкладке «Виджеты» включить галку «Выводить в лог данные и результаты виджетов», то можно будет посмотреть данные и результаты виджетов. Естественно, не все виджеты возвращают результаты. Некоторые просто тихо делают своё дело. Но всё, что можно показать – отладка отобразит в логе.В качестве примера посмотрим на виджет "Уведомления" для изученного выше меню уведомлений
Видим, что на входе виджета есть его данные и опции, а результат виджета — FALSE, поэтому на страницу виджет не выведен.
Если интересно чуть лучше изучить виджеты, смотрите пост Как работают виджеты (без PHP и с картинками)
Данные кеша
Данные записи и чтения кеша выводятся в лог аналогично. Например, вот кешированные данные для меню "Мои группы".Итоги
Кому будут нужны трассировки, фильтры, данные/результаты операций?В первую очередь разработчикам компонентов и шаблонов, это понятно.
Во вторую, всем тем, кто начинает разбираться в работе Двойки или уже разобрался, но хочет уточнить детали.
В третью, всем пользователям, кто использует на своём сайте сторонние компоненты. Вы сможете отправлять логи разработчикам этих компонентов, чтобы они меньше мучили вас вопросами, зато имели более точную и полную картину происходящего.
Теперь вы в любой момент, на локальной копии и на работающем сайте, при изучении и при отладке сможете посмотреть данные и результаты основных операций в InstantCMS 2 всего несколькими щелчками мышки без любого вмешательства в код системы. Надеюсь, вам этот инструмент будет так же полезен, как мне.
Обратите внимание! Поскольку выводимые данные и результаты обрабатываются функциями подсветки, то их вывод может тормозить как работу сервера, так и рендеринг страницы в браузере. Включайте эту возможность только при необходимости.
Кто солидарен со мной отпишитесь ниже?