Magento Observerイベント-操作の順序


9

catalog_model_product_duplicateイベントに機能を注入しようとしています。このモジュールの一部は、複製された製品の在庫状況も複製されるようにすることです。現在はそうではありません。

CatalogInventoryこのイベントを観察し、いくつかの標準的な株式情報を設定しているのがわかります。地元の人より先にコアイベントが解決されることを保証できますか?ここで信頼できる操作の順序はありますか?

回答:


11

イベントがディスパッチされる順序は、モジュールがロードされる順序によって異なります。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コアモジュールを強制的にロードするため、ここで重要な構成要素です。


7

イベントがディスパッチされる順序は簡単には保証できません。それらは、モジュールがロードされる順序に依存しています。通常、すべてのコアイベントオブザーバーは、コミュニティおよびローカルコードプールオブザーバーの前に呼び出されます。

コアモジュールの依存関係をローカルまたはコミュニティのものに「偽装」することにより、カスタムエージェントの後に強制的にmagentoオブザーバーを起動する方法があります。ここでリーの答えを見てください既存のMagentoオブザーバーの前にカスタムオブザーバーを発射させます。

/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>

私は個人的に、その依存関係を強制する結果がどのような結果をもたらすのかわからないので、このアプローチは好きではありません。

あなたのユースケースでは、発火したかどうかを知るためにデータ/状態を検出する必要があるようです。イベントの順序を強制するよりも、モデルのデータ/状態をチェックする方が望ましいでしょう。


ただし、私の場合、まだ在庫がない場合は何もしません。それが複製メソッドの結果であるかどうかを確認するために私が嗅ぐことができる後のイベントについての考えはありますか?
philwinkle 2013年

5

一般的な答え

オブザーバーは、最初にエリアで実行され、次にモジュールのロード順で実行されます

つまり、またはに登録されているすべてのオブザーバーの前に、に登録されて<global>いるすべてのオブザーバーが実行されます。<frontend><adminhtml>

エリア内では、オブザーバーはマージされた構成XMLツリーに表示される順序で実行されます。つまり、技術的にはモジュールが読み込まれた順序で実行されます。

モジュールの読み込み順序は次のように決定されます。

  1. ディペンデンシーグラフは、の<depends>定義から構築されますapp/etc/modules/*.xml。XがYに依存する場合、YはXの前にロードされます。

  2. 依存関係で注文した後、コアモジュールはコミュニティモジュールやローカルモジュールよりも優先されます。

  3. それ以外はすべてアルファベット順に読み込まれます。のファイル名app/etc/modulesは、実際のモジュール名ではなく、比較に使用されることに注意してください。

したがって、モジュールの読み込み順序に影響を与える2つのオプションがあります。

  1. 別のモジュールに依存してオブザーバーを実行した後(または他のモジュールに依存して、オブザーバーを実行した後)
  2. モジュール定義ファイルの名前を変更します。ファイル名はロード順以外には関係ないため、モジュール自体の名前を変更する必要はありません。

(「3.コアコードプールにモジュールを追加する」はカウントされません)

以下も参照してください。


1

単なる提案です。両方catalog_model_product_duplicateを観察しcatalog_model_product_save_after、シングルトンオブザーバーで観察してください。ではcatalog_model_product_duplicateオブザーバーデータとしてセット在庫データ、およびでcatalog_model_product_save_after使用重複製品の移入在庫にデータという。


つまり、イベントで私に与えられたオブジェクトにプロパティを保存し、それをテストすることをお勧めしますcatalog_model_product_save_after。唯一の落とし穴は、呼び出さずにプロパティを永続化することsave()です...そこで何か考えはありますか?
philwinkle 2013年

製品ではなく在庫モデルを保存するので、ループに陥ることはありません。
Petar Dzhambazov 2013年
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.