События Magento Observer - порядок выполнения операций
-
16-10-2019 - |
Вопрос
Я пытаюсь внедрить функциональность в catalog_model_product_duplicate
событие.Частью этого модуля будет обеспечение того, чтобы состояние запасов дублируемого продукта также дублировалось;в настоящее время это не так.
Я вижу это CatalogInventory
наблюдает за этим событием и устанавливает некоторую стандартную информацию о запасах.Могу ли я гарантировать, что основные события будут разрешены раньше моих локальных пользователей?Есть ли здесь какой-либо порядок операций, на который я могу положиться?
Решение
Порядок, в котором представлены события, зависит от порядка, в котором загружаются модули. Поскольку вам нужно быть уверенным, что CatalogInventory
Наблюдатели модуля стреляют перед тем, что вам это сделает, вам нужно просто настроить свой модуль, чтобы зависеть от Mage_CatalogInventory
модуль. Вы можете сделать это, добавив узел зависимости кода в вашем app/etc/modules/My_Module.xml
файл:
<config>
<modules>
<My_Module>
<active>true</active>
<codePool>local</codePool>
<depends>
<Mage_CatalogInventory />
</depends>
</My_Module>
</modules>
</config>
А depends
Узел в вышеупомянутом XML является важнейшей частью конфигурации здесь, так как он заставляет модуль Magento Core загружать до вашего.
Другие советы
Порядок, в котором отправляются события, не может быть легко гарантирован.Они зависят от порядка, в котором загружаются модули.Обычно все наблюдатели основных событий вызываются до наблюдателей сообщества и локального пула кода.
Существует метод, позволяющий заставить наблюдателей magento запускаться после пользовательских, "подделывая" зависимость основного модуля от локального или сообщества.Взгляните на ответ Ли здесь: Запустите пользовательский observer перед существующим Magento observer.
/app/etc/modules/Groupname_Page.xml
<config>
<modules>
<Groupname_Page>
<active>true</active>
<codePool>local</codePool>
<depends>
<!-- Your dependencies go here -->
</depends>
</Groupname_Page>
<Enterprise_PageCache>
<depends>
<Groupname_Page />
</depends>
</Enterprise_PageCache>
</modules>
</config>
Лично мне не нравится такой подход, поскольку я не знаю, к каким последствиям приведет навязывание этой зависимости.
Для вашего варианта использования звучит так, что вы должны выполнить какое-то обнаружение данных / состояния, чтобы узнать, было ли оно запущено или нет.Проверка данных / состояния в модели была бы предпочтительнее, чем попытка принудительно установить порядок событий.
Общий ответ
Наблюдатели выполняются область сначала, затем заказ модуля
Это означает, что все наблюдатели зарегистрировались в <global>
выполнены до Все наблюдатели зарегистрировались в <frontend>
или же <adminhtml>
.
В рамках области наблюдатели выполняются в том порядке, который они появляются в объединенном дереве конфигурации XML, что технически означает в том порядке, в котором были загружены модули.
Порядок загрузки модуля определяется следующим образом:
График зависимостей построен из
<depends>
Определения вapp/etc/modules/*.xml
. Анкет Если X зависит от Y, Y загружается до x.После заказа по зависимости основные модули имеют приоритет над сообществом и местными модулями
Все остальное загружено в алфавитном порядке. Обратите внимание, что имя файла в
app/etc/modules
используется для сравнения, а не фактическое имя модуля.
Таким образом, у вас есть два варианта влияния на заказ на загрузку модуля:
- Зависит от другого модуля, чтобы ваши наблюдатели были выполнены после него (или сделайте другой модуль зависеть от вашего, чтобы они выполняли ранее)
- Переименовать файл определения модуля. Вам не нужно переименовать сам модуль, потому что имя файла не имеет значения ни для чего другого, кроме порядка загрузки.
(«3. Добавить свой модуль в пул кодов ядра» не считается)
Смотрите также:
Просто предложение, наблюдайте за catalog_model_product_duplicate
а также catalog_model_product_save_after
С Singleton Observer. В catalog_model_product_duplicate
установить данные инвентаризации как данные наблюдателя и в catalog_model_product_save_after
Используйте эти данные для заполнения инвентаря для дублированного продукта.