Как эффективно продебажить сайт на Magento 2

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.

Привет! Я — Игорь Шатило, Back-end Developer в NIX. Занимаюсь программированием с 12 лет, а с NIX познакомился в 14 лет и уже тогда решил серьезно погрузиться в IT. В основном, участвую в больших проектах, где нужно анализировать и обрабатывать данные на бекенде. Иногда перехожу на «светлую» сторону — фронтенд и mobile :) Также в последнее время работаю с Magento. Это отличная платформа для относительно быстрого старта крупных интернет-магазинов.

В разработке сайтов и мобильных приложений, чтобы получить идеальный конечный продукт, вы должны позаботиться о многом. Тестирование, улучшение производительности, настройка безопасности и отладка — мастхэв. В этой статье я сосредоточусь на важной части процесса разработки любого e-commerce решения — отладке кода на примере Magento 2.

Отладка кода — один из самых важных этапов при разработке любого проекта. Даже самые крутые разработчики никогда не пишут идеальный код. На любом этапе могут появиться мелкие баги, которые придется устранять. Одни разработчики логируют весь процесс выполнения кода, после чего начинают отладку. В то же время, другие предпочитают отладку во время самого выполнения кода. И то, и другое — отличный способ избавиться от ошибок в вашем интернет-магазине. Я поделюсь различными способами, которые помогут вам продебажить сайт.

Материал будет полезен Magento-разработчикам, которые столкнулись с проблемами при разработке онлайн-магазинов и наткнулись на множество багов.

Прекратите использовать var_dump, print_r и т. д.

Начнем с базового уровня, на котором вы, как правило, пишете PHP-код, используя команды var_dump, print_r для отладки вывода написанного кода. Существуют инструменты отладки PHP, которые подсказывают пользователю, что можно исправить в коде во время его написания. Также есть и функции, которые выводят на экран нужную информацию или ошибки/предупреждения в случае сбоя кода.

Несмотря на то, что этот способ отладки PHP давно устарел, он все еще популярен среди разработчиков. Однако, используя данный метод, невозможно нормально дебажить Magento 2, так как все объекты внутри нее содержат свойства со ссылкой на самого себя. Таким образом, при попытке распечатать объект с помощью вышеупомянутых функций мы получим бесконечный цикл.

Настройте Xdebug

Представьте, что вы уже написали код модуля Magento 2 и собираетесь его скомпилировать. И тут бац! Что-то идет не так, и код ломается. И что еще хуже, вы не можете определить, что это. В таком случае на помощь приходит Xdebug.

Xdebug — расширение PHP, которое помогает разработчикам во время отладки и разработки проектов внимательно следить за ошибками и устранять их. Это идеальный инструмент для замены var_dump() и прочих функций. Он также добавляет трассировку стека для notices, warnings, ошибок и исключений.

Xdebug позволяет добавлять break points и останавливать выполнение кода в каждой из этих точек. Вы сможете видеть выходные данные переменных только в одной итерации кода. Получается, вы экономите свое драгоценное время, которое может быть потеряно при отладке кода другими методами.

Комбинация Xdebug и PhpStorm — один из лучших способов отладки сайта на Magento 2. Основное преимущество этого метода заключается в том, что он добавляет break points в процесс установки и может помочь разработчику просмотреть и изменить переменные в любое время.

Включите developer mode

Этот режим позволяет отображать ошибки прямо на экране. Это удобно при отладке модулей, в логике которых произошли какие-то ошибки (обычно в таких случаях мы видим пустую страницу или Error 500). Перед включением данного режима убедитесь, что сгенерированные классы и сущности object manager’а (proxies) были очищены. В противном случае возможно возникновение непредвиденных ошибок. Чтобы включить developer mode, в консоли необходимо запустить следующую команду:

php bin/magento deploy:mode:set developer

Имейте ввиду, что после включения developer mode, Magento 2 будет работать немного по-другому:

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

Включите и настройте логирование

Система логирования — очень полезный инструмент в Magento. Он необходим разработчикам в процессе отладки кода. Файлы логов помогают определить, как работает сайт, какие проблемы возникают и какие функции работают некорректно.

В Magento 2 есть класс \Magento\Framework\Logger\Monolog (\Psr\Log\LoggerInterface), который позволяет регистрировать события и выходные переменные в файлах журнала Magento. Все логи будут выводиться в файл var/log/system.log, за исключением debug метода, поскольку он сохраняет журналы в файле var/log/debug.log.

Еще одна замечательная функция Magento 2 — это логирование действий с базой данных. По умолчанию логи базы данных сохраняются в var/debug/db.log. Ведение логов базы данных позволяет отслеживать все запросы к базе данных и может помочь нам найти узкие места в производительности. Чтобы включить логирование работы с базой данных, нужно выполнить следующую команду в консоли:

php bin/magento dev:query-log:enable

Чтобы понять, как работает данная команда, взгляните на ее реализацию. По поиску названия команды, мы можем обнаружить, что следующий класс отвечает за выполнение команды \Magento\Developer\Console\Command\QueryLogEnableCommand.

Данная команда имеет такие аргументы:

  • include-all-query — если этот параметр установлен, будут логироваться все запросы в БД;
  • query-time-threshold — определяет пороговое время запроса, которое регистрируется. Таким образом, вы можете ограничить ведение журнала только медленными запросами;
  • include-call-stack — определяет, надо ли включать трассировку стека в логи.

Сама команда сохраняет только конфигурацию среды. Остальное волшебство происходит в \Magento\Framework\DB\Logger\LoggerProxy. Конфигурация передается в качестве аргументов для класса.

<type name="Magento\Framework\DB\Logger\LoggerProxy">
    <arguments>
        <argument name="loggerAlias" xsi:type="init_parameter">Magento\Framework\Config\ConfigOptionsListConstants::CONFIG_PATH_DB_LOGGER_OUTPUT</argument>
        <argument name="logAllQueries" xsi:type="init_parameter">Magento\Framework\Config\ConfigOptionsListConstants::CONFIG_PATH_DB_LOGGER_LOG_EVERYTHING</argument>
        <argument name="logQueryTime" xsi:type="init_parameter">Magento\Framework\Config\ConfigOptionsListConstants::CONFIG_PATH_DB_LOGGER_QUERY_TIME_THRESHOLD</argument>
        <argument name="logCallStack" xsi:type="init_parameter">Magento\Framework\Config\ConfigOptionsListConstants::CONFIG_PATH_DB_LOGGER_INCLUDE_STACKTRACE</argument>
    </arguments>
</type>

Включите отображение ошибок Magento

Magento 2 автоматически сохраняет сообщения об ошибках в папку var/reports и не отображает их на экране. Чтобы такие сообщения отображались, вам необходимо переименовать файл local.xml.sample, который находится в pub/errors, в local.xml. Данный файл содержит настройки отображения ошибок. Также в нем вы можете настроить уведомления об ошибках на вашу почту.

Включите подсказки путей к шаблонам

Этот шаг поможет вам в процессе определения, например, класса блока .php, который соответствует одной из определенных областей страницы вашего сайта. Также вы можете легче находить файлы .phtml.

Чтобы включить такие подсказки, необходимо сделать следующее:

  • Шаг 1. Зайдите в админ-панель.
  • Шаг 2. Выберите Store > Configuration > Advanced > Developer > Debug > Enabled Template Path Hints for Storefront.
  • Шаг 3. Нажмите «Yes», чтобы включить подсказки путей к шаблонам.

Кроме этого, вы также можете включить подсказки путей к шаблонам при помощи консольной команды:

php bin/magento dev:template-hints:enable

В результате увидим что-то похожее:

Да, выглядит устрашающе. Но включение этой настройки поможет вам с легкостью определить темплейт и его блок, чтобы потом модифицировать или исправить функционал сайта.

Дебажим Object Manager

По сравнению с первой версией, Magento 2 предлагает множество изменений. Вы все еще можете видеть отдельные части Magento 1 (EAV, области, блоки и т. д.), но разработчики Magento 2 постарались полностью переписать изначальный вариант на более зрелую, похожую на enterprise-java систему. В результате мы можем видеть больше классов, больше объектов и больше шаблонов проектирования.

В Magento 1 почти все объекты реализованы и вызываются через класс Mage. В Magento 2 Object Manager используется вместо класса Mage. Это помогает решить некоторые проблемы, возникающие при создании экземпляров параметров путем создания тесных взаимосвязей между тремя шаблонами: управление объектами, dependency injection и создание плагинов. Object Manager в основном отвечает за создание и настройку объектов при помощи двух основных методов: get и create.

Одним из архитектурных паттернов, которые используются в Magento 2, является паттерн проектирования Singleton. Он гарантирует, что у класса будет только один экземпляр. Object Manager как раз и выступает «глобальным» хранилищем всех синглтонов Magento 2.

Внутри класса Object Manager есть свойство $_sharedInstances, в котором хранится массив всех синглтонов Magento 2. При помощи XDebug вы можете найти нужный вам синглтон в данном массиве и сделать на него или его свойство вотчер. Так вы сможете отслеживать изменение данных в синглтонах, что может помочь во время дебага кода и поиска ошибки.

Использование профайлера

Magento 2 имеет встроенный профайлер, который позволяет вам отслеживать производительность вашего магазина и оптимизировать код. Более того, профайлер может отображать графики зависимостей, что позволяет отлавливать объекты, созданные Magento, но фактически никогда не используемые.

Используя профайлер, вы можете видеть время выполнения определенных фрагментов кода, включая время каждого запроса и выполненных параметров. Таким образом, мы можем получить время выполнения блоков кода и оптимизировать память и затраченное время.

Дебажим запросы в БД

С коллекциями Magento 2 вы можете создавать очень сложные фильтры. Например, присоединять другие таблицы, выбирать нужные вам данные. В Magento 2 это делается без каких-либо знаний SQL. Звучит неплохо, но на самом деле может возникнуть проблема, если вы захотите изменить существующий фильтр или создать собственный. Большинство разработчиков хорошо знают SQL, но бывают случаи, когда ошибку найти сложно. Тем более, если кажется, что код написан правильно. В таком случае вы можете распечатать SQL запрос вашей коллекции:

echo $collection->getSelect()->__toString(); 

Полученный запрос вы можете вручную запустить в консоли MySQL, или, например, в PhpMyAdmin или DBeaver. В результате выполнения SQL кода вы увидите данные, которые затем будут использованы в коллекции. Если вы получаете не те данные или ошибку, достаточно будет проверить SQL код коллекции, пофиксить его и уже после этого менять PHP код, который генерирует коллекцию.

Как дебажить JS в Magento 2

По умолчанию в Magento 2 используется RequireJS для подключения различного JavaScript кода. Такой подход позволяет использовать JavaScript модульно, а также использовать фоновую и асинхронную загрузку. Так как Magento 2 имеет очень много JavaScript модулей и компонентов, очень часто приходится искать и исправлять ошибки и на фронтенде.

Интерфейс Magento 2 состоит из множества UI компонентов, которые используются для представления отдельных элементов пользовательского интерфейса, таких как таблицы, кнопки, диалоговые окна и другие. UI компоненты используют библиотеку KnockoutJS для привязки данных к определенным элементам DOM на странице, которые затем отображаются для пользователя. Такие компоненты используются в различных местах на сайте. Одним из главных таких мест является страница оформления заказа — чекаут. Здесь подключается огромное количество JavaScript файлов.

Многие фронтендеры отлаживают код при помощи console.log, но для UI компонентов в Magento 2, которые используют Knockout JS, можно взять специальный инструмент — Knockoutjs context debugger. Вы можете найти его в Google Chrome Webstore и установить для своего браузера. Данный инструмент помогает отлаживать UI компоненты, следить за их внутренним состоянием, определять темплейты, соответствующие JS файлы и т.д.

Кроме UI компонентов, в Magento 2 есть uiRegistry — глобальное хранилище на фронтенде, которое позволяет вытаскивать любой UI компонент на странице.

В интерфейсе Magento 2 компоненты построены иерархически. Их имена являются производными от их родительских имен. Если посмотреть в файл checkout_index_index.xml, мы увидим, что компонент checkout содержит ужасающее количество конфигов. Чтобы упростить отладку этого гигантского кода, можно использовать объект uiRegistry в консоли нашего браузера или в своем коде.

Если мы хотим получить конкретный объект и знаем полное имя элемента, можем просто использовать следующий код:

requirejs('uiRegistry').get('componentName');

Таким образом, вы получите абсолютно любой UI компонент на странице и сможете продебажить его.

Как дебажить на production

Мы как разработчики всегда надеемся, что нам никогда не понадобится дебажить production, поскольку код, который находится там, подготовлен и протестирован заранее. К сожалению, это не так. Даже при 100% покрытии кода и усиленном ручном тестировании будут попадаться случаи, которые клиенты упускают из виду. Например, для production могут использоваться другие креды от какого-то API, который может случайно сломаться.

Возможность отладки в производственной среде — бесценный инструмент, поскольку он избавляет от необходимости воспроизводить проблемы локально. Вместо этого вы можете найти и исправить проблему в работающей системе.

Безусловно, наиболее распространенным методом дебага на проде является ведение логов. Поиск в файлах логов точно поможет узнать, что произошло во время ошибки и в каком именно месте. Для более удобного мониторинга ошибок в файлах логов можно также использовать и ботов в мессенджерах, например, в Telegram или Slack. Такие боты будут сразу же уведомлять вас об ошибках на проде.

И запомните: дебажить на production при помощи XDebug и всяких var_dump категорически запрещено! Ни в коем случае нельзя выводить ошибки пользователю. Это может как отпугнуть ваших покупателей, так и стать лазейкой для потенциальных хакеров.

Вывод

Процесс дебага всегда является важным моментом во время написания кода. Без него вы не сможете определить, что не так произошло в коде, особенно если он содержит запутанную логику. Перед написанием кода рекомендуется сначала настроить среду отладки. Если вы разрабатываете сложный сайт на Magento 2, содержащий тысячи строк кода, вам обязательно понадобится отладчик PHP, который быстро найдет ошибки и предупреждающие сообщения.

Правильная отладка кода поможет вам прийти к его логическому и аналитическому пониманию — это самый важный навык, которым может обладать разработчик. Особенно, если код писали не вы, а сторонние разработчики. При помощи дебага вы можете детально пройтись по каждой строке и функции, тем самым изучив, как этот код работает.

👍НравитсяПонравилось2
В избранноеВ избранном2
LinkedIn
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Поменял когда-то magento на sylius.com, и доволен. Ребята из польши сделил просто офигенный инструмент для бесконечного расширения базового ядра будущего магазина. И вам советую попробовать!

Можете поделиться более развернутым мнением? Что особенно понравилось после мадженты? Может что-то наоборот не понарвилось? Проект выглядит очень интересным, давно на него поглядываю.

1) в основе проекта лежит symfony + doctrine, что делает порог входа в Sylius сильно проще чем Magento
2) кастомизация как админ так и фронт части, используя обычные symfony бандлы (желательно следовать неймингу sylius)
3) легковестность ипроизводительность по сравнении с Magento 2
4) есть уже достаточно много бандлов от комьюники как хорошо спроектированых так и не очень.
5) нет проебем с SEO и дублями урлов (привет Magento 2)
6) очень просто деплоить, никакх тебе даунтаймов, maintenance mode при перекомпиляции
7) сборка фронта babel из коробки (привет requirejs)

Я могу продлжать и дальше :) Вообще если говорить про опенсорс решение, мне Sylius нравиться больше.

Типовий показник новачка в Лінуксі:

в файл var/log/system.log

Лідуючий «/» є обов’язковим!

Ви не праві. В даному випадку

var/log/system.log

означає шлях від кореня Magento, а не те, що ви подумали.

Ладно. Но потом сжечь.

не «потом». Сайт на мадженто надо сжечь до, того как появится мысль с ним работать

Після wp/bitrix/opencart/joomla магента за щастя

Подписаться на комментарии