Система управления сайтом UMI.CMS изначально включает в себя разделение на основной движок сайта, который не трогается веб-разработчиком (и который перезаписывается при обновлении системы), и дополнительный (настраиваемый) функционал, под который разработчик сайта адаптирует сам: свои шаблоны оформления, макросы (PHP-функции, вызываемые из шаблонов), кастомные модули при необходимости.
Однако при разработке своего сайта бывают ситуации, когда необходимо изменить существующий функционал сайта:
- добавить собственную логику импорта данных из XML;
- выполнить некоторые действия при импорте данных;
- выполнить некоторые действия при создании или изменении заказа;
- выполнить некоторые запланированные действия;
- … и так далее.
В документация или на сторонних ресурсах Этот вопрос обсуждался, однако, на мой взгляд, недостаточно подробно.
Данная статья является попыткой собрать воедино информацию о работе с событиями в UMI.CMS, а также на примере показать, как с помощью обработки событий можно расширить функциональные возможности системы.
Согласно документации в UMI.CMS есть два типа обработчиков событий:
- системный — это предустановленные обработчики, которые пишутся при разработке модуля.
Эти обработчики прописаны в файле event.php, который находится в каталоге модуля.
Для модулей, входящих в дистрибутив UMI.CMS, этот файл изменить нельзя.
- обычай — эти обработчики должны находиться в файле custom_events.php в каталоге модуля.
Кроме того (в документации об этом не написано) выполняются обработчики системных событий после обычай.
Это необходимо учитывать при разработке своего функционала.
События можно вызывать до изменения объекта (так называемый режим до ) и после смены объекта (режим после ).
Не все события могут иметь и «до», и «после», какие из них стоит посмотреть по ссылке ниже.
Список внутренних событий можно найти в документация .
Необходимо помнить, что при выполнении действий над одним и тем же объектом в разных местах будут вызываться разные обработчики событий.
Это вызывает определенные неудобства: Например, предположим, что мы разрабатываем интернет-магазин на базе UMI, и нам необходимо выполнять некоторые действия при изменении статуса заказа (например, отправлять дополнительные письма, задавать какие-то другие поля в заказе и т. д. в зависимости от статуса).
.
Давайте посмотрим, где мы можем «отлавливать» события изменения статуса заказа:
- изменение статуса при создании заказа пользователем сайта - событие статус заказа изменен Модуль электронного рынка;
- изменение статуса из админ-панели на странице подробной информации о заказе - системное событие системаModifyObject ;
- изменение статуса из админки на странице списка всех заказов - системное событие системаModifyPropertyValue ;
- изменение статуса при импорте через XML (например, при выгрузке из 1С) - событие обменонупдатеобъект .
Давайте подробнее рассмотрим системное событие SystemModifyPropertyValue .
В документации я не нашел упоминания о нем, увидел его вызов только при анализе системного кода, но без него в описанной ситуации обойтись довольно сложно, так как администратор сайта (менеджер) может изменить данные заказа в два пути:
- на главной странице модуля «Интернет-магазин» в списке всех заказов – UMI позволяет редактировать статус и другие данные заказа прямо в этом списке;
- в окне подробной информации о заказе, которое открывается по клику на заказ.
Что, конечно, очень неудобно и оставляет большую возможность для ошибок.
Системное событие SystemModifyPropertyValue имеет следующие параметры:
- сущность — ссылка на объект, свойство которого меняется;
- свойство — наименование изменяемого объекта недвижимости;
- старое значение — старая стоимость недвижимости;
- новое значение — новая стоимость недвижимости;
Я хочу показать более сложный пример: как добавить недостающий функционал в UMI, создав обработчик событий импорта данных — научить систему импортировать дополнительные свойства товара.
Допустим, мы разрабатываем интернет-магазин по продаже футболок.
У нас установлена 1С «Управление торговлей», в которой мы собираемся вести учет товаров и заказов.
В 1С внесен весь необходимый ассортимент продукции и желательно, чтобы он с минимальными действиями был загружен на сайт. Специфика продажи таких товаров такова, что мы имеем, например, модель «Футболка Dolce», которой продаются конкретные единицы:
- Футболка Dolce White, размер 40;
- Футболка Dolce White, размер 48;
- Футболка Dolce Red, размер 44;
- … и так далее.
В терминах 1С это «характеристики товара».
А с точки зрения интернет-магазина мы хотим иметь одну страницу модели «Футболка Dolce», где покупатель мог бы выбрать свой цвет и размер и оформить на них заказ.
С точки зрения 1С все кажется просто.
Ставим галочку «характеристики» в настройках товара.
Сначала загружаем товар на диск, смотрим полученный XML-файл (offers.xml), нужные предложения есть, радуемся и загружаем на сайт. И тут мы понимаем, что радовались рано.
Сами товары добавлены, а их характеристики (то, что у конкретной футболки есть с десяток предложений с разными сочетаниями цветов и размеров) нет. В системе UMI необходимый нам функционал реализован с помощью дополнительные свойства .
То есть на первый взгляд все есть.
Однако при дальнейшем копании исходников и документации выясняется, что в текущей версии UMI (2.8.6) модуль «Обмен данными» не поддерживает импорт дополнительных свойств.
Так что необходимый функционал мы добавим сами.
Особенности импорта из 1С в UMI описаны в документация .
Чтобы добавить свой функционал при импорте данных, вам необходимо изменить шаблон импорта /xsl/import/custom/commerceML2.xsl, а также добавить собственный обработчик событий импорта.
Давайте изменим шаблон импорта: Импортировать шаблон Теги: #веб-разработка #Umi.cms #php #обработка событий #разработка веб-сайтов #php
-
Робот-Принтер
19 Oct, 24 -
Новые Реквизиты Ндс Для Покупок За Рубежом
19 Oct, 24 -
Идея Стартапа – Кто Ее Реализует?
19 Oct, 24 -
Кризис И Студия Артемия Лебедева
19 Oct, 24 -
14 Постулатов Воплощения Качества.
19 Oct, 24
