Немного поговорим про использование фильтров. Поскольку «Расширенная отладка» может выдать в лог очень много разной информации, то возникла необходимость как-то организовать отбор только нужных строк логов. Для этого я сделал фильтры.
Напомню, нужные нам запросы были по таблице 'cms_con_news'.
Сначала на вкладке «База данных» в настройках отладки в поле «Строка для фильтра SQL-запросов по части строки запроса» пропишем имя таблицы, к которой обращается запрос.
Сохраняем настройки и обновляем «Главную» страницу. Видим список всех запросов с участием этой таблицы. В логе получилось девять запросов.
Это много. И часть запросов сделана к таблицам с похожими именами, например, 'cms_con_news_cats' или 'cms_con_news_fields'. Нам это не подходит, поэтому изменим строку фильтра, добавив пробел и латинскую букву 'i' — алиас нашей таблицы в запросе.
Напомню первые строки запроса:
После обновления страницы остаются только запросы к таблице 'cms_con_news'
Найденные вхождения строки поиска по возможности будут подсвечены зелёным фоном. Оформление подсветки, при желании, можно изменить в css-файле отладки. Подсветка не сработает в случае, если в вашей строке поиска были двойные и более пробелы или строка поиска попадёт на часть запроса с переносом строки.
Всего к этой таблице было 3 запроса из 45 обращений к БД на странице. Это видно в колонке «Кол-во» напротив условия отбора для SQL-запросов в «Таблице выводимых типов лога» (маленькая таблица над логом, в которую выводятся все заданные в настройках отладки фильтры). В логе после применения фильтра остаются только отфильтрованные запросы. Это уже лучше, чем вручную просматривать почти полсотни запросов на этой странице (общее количество всех запросов на странице также видно в основной таблице отладки — значение 'sql-queries: — count:').
Для более точного отбора в поле «Строка для фильтра SQL-запросов по части строки запроса» можно использовать даже часть запроса. Писать весь запрос необязательно, достаточно будет неповторяющейся в других запросах подстроки. Если в этой части искомого запроса есть переводы строки, то вместо них поставьте пробел. Отладка при поиске нормализует и тексты запросов, и текст для поиска по пробелам, переносам и регистру букв. Поэтому даже если вы ошибётесь с количеством пробелов или регистром, то нужные запросы всё равно будут найдены, но подсветка может не всегда сработать, как я написал выше.
Кстати, описанная нормализация производится для всех строковых значений логов и полей фильтров, участвующих в фильтрации, а не только в тексте запроса. Для фильтров по спискам нормализация не требуется.
На заметку: При заданных фильтрах на вкладке «База данных» подключения к БД выводятся только если в строке фильтра задана подстрока (часть) из слова 'connect'.
В качестве строки поиска можно вписать:
• Имя вызывающего файла с путём, частью пути или без пути.
Будут отобраны только запросы из файлов, содержащих заданную строку в полном пути с именем файла.
Например, только из файла ядра для работы с пользователями – 'user.php’
• Часть пути к вызывающему файлу.
Будут отобраны только запросы из файлов, содержащих заданную строку в пути к файлу.
Например, только из контроллера контента – ‘/controllers/content/’
• Имя или часть имени вызывающей функции.
Будут отобраны лишь те запросы, у которых в любой доступной части трассировки присутствует такое имя функции
Например, только получение опций – 'getOptions’
• Имя класса
Будут отобраны запросы только в том случае, если в любой доступной части трассировки присутствует такое имя класса.
Например, только запросы из шаблона – 'cmsTemplate’
Найденные части путей/файлов/функций будут подсвечены в логе зелёным фоном.
Для примера, найдём на той же "Главной странице" демо-сайта запросы списков пользователей из 'modelUsers->getUsers'. В поле "Строка для фильтра SQL-запросов по пути/имени вызывающего файла или класса/функции" впишем эту подстроку и очистим поле фильтра по подстроке текста запроса.
После обновления страницы останутся только запросы из нужного нам метода
Принцип поиска по трассировке:
Сначала искомая подстрока ищется в файле и функции, которые непосредственно вызывают запрос. То есть, те, которые в логах находятся в первой строке, после надписи «Query #» и времени.
Если там подстрока не найдена, то в случае, если включена трассировка, то поиск производится по ней на всю глубину, которая задана в настройках и отображается в логе.
То есть, при таком поиске лучше включать трассировку на глубину хотя бы 2-3 уровня, чтобы точно найти интересующие вас вызывающие файлы/классы/функции.
Например, найдём на "Главной странице" демо-сайта запросы из слайдера контента и сделаем фильтр по классу 'widgetContentSlider'. В поле "Строка для фильтра SQL-запросов по пути/имени вызывающего файла или класса/функции" впишем эту подстроку. И увидим пустой лог, так как строка 'widgetContentSlider' находится в глубине трассировки, запрос к БД производится не непосредственно из виджета, а из какой-то модели (что соответствует требованиям модели MVC). Поэтому нужно включить полную трассировку для запросов.
После обновления страницы видим запросы, выполненные по требованию слайдера.
Например, можно посмотреть, где и как подключаются файлы вашего контроллера, задав строку ‘/system/controllers/имя_вашего_контроллера/’.
Вот файлы компонента 'content' на Главной:
Фильтр позволяет отобрать события и хуки только по конкретному событию. Можете сделать выбор событий из выпадающего списка (красная рамка на скрине) или ввести вручную (зелёная рамка) имя события полностью или частично. Если событие задано в строке, то выпадающий список событий не используется.
Поскольку нет программной возможности без просмотра всех файлов скриптов узнать вообще все доступные события во всех установленных компонентах CMS, в том числе и в сторонних, то в список выводятся лишь зарегистрированные в обработчиках события.
Выбор из выпадающего списка с перечнем установленных в систему контроллеров. Применяется только к хукам. События выводятся без учёта этого фильтра, так как только в хуках станет известно, какой контроллер их обработает.
Совет: Если вам нужно отобрать события из какого-то контроллера, то укажите его в этом фильтре.
Если посмотреть «Виджеты» в Админке, то можно заметить, что есть несколько «общих» виджетов, компоненты которых не зарегистрированы в списке компонентов системы. Как раз для того, чтобы можно было отобрать такие виджеты и служит пункт «Пусто» в этом списке контроллеров.
Аналогичны уже знакомым вам фильтрам. Можно отбирать строки по пути/имени используемого файла шаблона или по контроллеру. Так же, как и в виджетах, можно ообрать только шаблоны без компонента (например, меню, хлебные крошки и т.п.)
Позволяют фильтровать по имени ключа кеша или по типу операции SET/GET.
Важное примечание. В стандартном режиме "Расширенной отладки" некоторые фильтры не будут работать вообще, или будут срабатывать частично или не всегда.
Это не ошибки отладки. Причина в нехватке структурированных данных в стандартном режиме. Такие фильтры в настройках отладки помечены звёздочкой *.
Для полноценной работы всех фильтров нужен полнофункциональный режим отладки со сбором дополнительных данных ядра. Подробнее о режимах тут.
Думаю, что реализованных фильтров хватит для большинства исследовательских и отладочных задач. Но если у вас возникнут ещё идеи, сообщайте мне. По возможности постараюсь реализовать те из них, которые покажутся мне подходящими под цели «Расширенной отладки».
Фильтры для SQL-запросов
Фильтр по тексту запроса
В предыдущем посте «Использование расширенной отладки. Часть 4. Трассировка» я сказал, что нужный SQL-запрос можно легко отобрать из всех запросов с помощью фильтров. Давайте это сделаем.Напомню, нужные нам запросы были по таблице 'cms_con_news'.
Сначала на вкладке «База данных» в настройках отладки в поле «Строка для фильтра SQL-запросов по части строки запроса» пропишем имя таблицы, к которой обращается запрос.
Сохраняем настройки и обновляем «Главную» страницу. Видим список всех запросов с участием этой таблицы. В логе получилось девять запросов.
Напомню первые строки запроса:
После обновления страницы остаются только запросы к таблице 'cms_con_news'
Найденные вхождения строки поиска по возможности будут подсвечены зелёным фоном. Оформление подсветки, при желании, можно изменить в css-файле отладки. Подсветка не сработает в случае, если в вашей строке поиска были двойные и более пробелы или строка поиска попадёт на часть запроса с переносом строки.
Всего к этой таблице было 3 запроса из 45 обращений к БД на странице. Это видно в колонке «Кол-во» напротив условия отбора для SQL-запросов в «Таблице выводимых типов лога» (маленькая таблица над логом, в которую выводятся все заданные в настройках отладки фильтры). В логе после применения фильтра остаются только отфильтрованные запросы. Это уже лучше, чем вручную просматривать почти полсотни запросов на этой странице (общее количество всех запросов на странице также видно в основной таблице отладки — значение 'sql-queries: — count:').
Для более точного отбора в поле «Строка для фильтра SQL-запросов по части строки запроса» можно использовать даже часть запроса. Писать весь запрос необязательно, достаточно будет неповторяющейся в других запросах подстроки. Если в этой части искомого запроса есть переводы строки, то вместо них поставьте пробел. Отладка при поиске нормализует и тексты запросов, и текст для поиска по пробелам, переносам и регистру букв. Поэтому даже если вы ошибётесь с количеством пробелов или регистром, то нужные запросы всё равно будут найдены, но подсветка может не всегда сработать, как я написал выше.
Кстати, описанная нормализация производится для всех строковых значений логов и полей фильтров, участвующих в фильтрации, а не только в тексте запроса. Для фильтров по спискам нормализация не требуется.
На заметку: При заданных фильтрах на вкладке «База данных» подключения к БД выводятся только если в строке фильтра задана подстрока (часть) из слова 'connect'.
Фильтр по пути/имени вызывающего файла или класса/функции
Точно так же можно отобрать только запросы, которые вызываются из определённых классов/функций или файлов. Для этого на вкладке «База данных» есть поле «Строка для фильтра SQL-запросов по пути/имени вызывающего файла или класса/функции».В качестве строки поиска можно вписать:
• Имя вызывающего файла с путём, частью пути или без пути.
Будут отобраны только запросы из файлов, содержащих заданную строку в полном пути с именем файла.
Например, только из файла ядра для работы с пользователями – 'user.php’
• Часть пути к вызывающему файлу.
Будут отобраны только запросы из файлов, содержащих заданную строку в пути к файлу.
Например, только из контроллера контента – ‘/controllers/content/’
• Имя или часть имени вызывающей функции.
Будут отобраны лишь те запросы, у которых в любой доступной части трассировки присутствует такое имя функции
Например, только получение опций – 'getOptions’
• Имя класса
Будут отобраны запросы только в том случае, если в любой доступной части трассировки присутствует такое имя класса.
Например, только запросы из шаблона – 'cmsTemplate’
Найденные части путей/файлов/функций будут подсвечены в логе зелёным фоном.
Для примера, найдём на той же "Главной странице" демо-сайта запросы списков пользователей из 'modelUsers->getUsers'. В поле "Строка для фильтра SQL-запросов по пути/имени вызывающего файла или класса/функции" впишем эту подстроку и очистим поле фильтра по подстроке текста запроса.
После обновления страницы останутся только запросы из нужного нам метода
Принцип поиска по трассировке:
Сначала искомая подстрока ищется в файле и функции, которые непосредственно вызывают запрос. То есть, те, которые в логах находятся в первой строке, после надписи «Query #» и времени.
Если там подстрока не найдена, то в случае, если включена трассировка, то поиск производится по ней на всю глубину, которая задана в настройках и отображается в логе.
То есть, при таком поиске лучше включать трассировку на глубину хотя бы 2-3 уровня, чтобы точно найти интересующие вас вызывающие файлы/классы/функции.
Например, найдём на "Главной странице" демо-сайта запросы из слайдера контента и сделаем фильтр по классу 'widgetContentSlider'. В поле "Строка для фильтра SQL-запросов по пути/имени вызывающего файла или класса/функции" впишем эту подстроку. И увидим пустой лог, так как строка 'widgetContentSlider' находится в глубине трассировки, запрос к БД производится не непосредственно из виджета, а из какой-то модели (что соответствует требованиям модели MVC). Поэтому нужно включить полную трассировку для запросов.
После обновления страницы видим запросы, выполненные по требованию слайдера.
Фильтры для автозагрузок и инклудов
Фильтр по пути/имени подключаемого файла
Отфильтровывает автозагрузки или инклуды только нужного файла или файлов. Можно указывать любую часть полного пути с именем файла: только файл, файл с частью или полным путём, часть пути к файлу.Например, можно посмотреть, где и как подключаются файлы вашего контроллера, задав строку ‘/system/controllers/имя_вашего_контроллера/’.
Вот файлы компонента 'content' на Главной:
Фильтр по пути/имени вызывающего файла или класса/функции
Аналогичен такому же фильтру в SQL-запросах.Фильтры для событий и хуков
Фильтровать события/хуки по событию
Фильтр позволяет отобрать события и хуки только по конкретному событию. Можете сделать выбор событий из выпадающего списка (красная рамка на скрине) или ввести вручную (зелёная рамка) имя события полностью или частично. Если событие задано в строке, то выпадающий список событий не используется.
Поскольку нет программной возможности без просмотра всех файлов скриптов узнать вообще все доступные события во всех установленных компонентах CMS, в том числе и в сторонних, то в список выводятся лишь зарегистрированные в обработчиках события.
Фильтровать хуки по обрабатывающему контроллеру
Выбор из выпадающего списка с перечнем установленных в систему контроллеров. Применяется только к хукам. События выводятся без учёта этого фильтра, так как только в хуках станет известно, какой контроллер их обработает.
Фильтр по пути/имени вызывающего файла или класса/функции
Этот фильтр применяется и к событиям, и к хукам. Аналогичен такому же фильтру в SQL-запросах и автозагрузках/инклудах.Совет: Если вам нужно отобрать события из какого-то контроллера, то укажите его в этом фильтре.
Фильтры для виджетов
Фильтровать по имени или названию виджета
Строка для ввода имени или заголовка виджета, полностью или частично..Фильтровать по контроллеру
Выпадающий список контроллеров, аналогичный списку в Событиях и хуках". Позволяет отобрать виджеты любого контроллера из этого списка.Если посмотреть «Виджеты» в Админке, то можно заметить, что есть несколько «общих» виджетов, компоненты которых не зарегистрированы в списке компонентов системы. Как раз для того, чтобы можно было отобрать такие виджеты и служит пункт «Пусто» в этом списке контроллеров.
Фильтры шаблонов
Аналогичны уже знакомым вам фильтрам. Можно отбирать строки по пути/имени используемого файла шаблона или по контроллеру. Так же, как и в виджетах, можно ообрать только шаблоны без компонента (например, меню, хлебные крошки и т.п.)
Фильтры кеша
Позволяют фильтровать по имени ключа кеша или по типу операции SET/GET.
Важное примечание. В стандартном режиме "Расширенной отладки" некоторые фильтры не будут работать вообще, или будут срабатывать частично или не всегда.
Это не ошибки отладки. Причина в нехватке структурированных данных в стандартном режиме. Такие фильтры в настройках отладки помечены звёздочкой *.
Для полноценной работы всех фильтров нужен полнофункциональный режим отладки со сбором дополнительных данных ядра. Подробнее о режимах тут.
Думаю, что реализованных фильтров хватит для большинства исследовательских и отладочных задач. Но если у вас возникнут ещё идеи, сообщайте мне. По возможности постараюсь реализовать те из них, которые покажутся мне подходящими под цели «Расширенной отладки».
Я точно так же заинтересован в развитии Инстанта, как и вы все. Помогаю чем могу.
Но ваша разработка позволяет более подробно узнать принципы работы движка 2-й версии.
Плюсую за ваш вклад! Думаю он многим пригодиться!
Удачных Вам в ваших начинаниях и творческого вдохновения :)