catalog_model_product_duplicate
イベントに機能を注入しようとしています。このモジュールの一部は、複製された製品の在庫状況も複製されるようにすることです。現在はそうではありません。
CatalogInventory
このイベントを観察し、いくつかの標準的な株式情報を設定しているのがわかります。地元の人より先にコアイベントが解決されることを保証できますか?ここで信頼できる操作の順序はありますか?
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コアモジュールを強制的にロードするため、ここで重要な構成要素です。
イベントがディスパッチされる順序は簡単には保証できません。それらは、モジュールがロードされる順序に依存しています。通常、すべてのコアイベントオブザーバーは、コミュニティおよびローカルコードプールオブザーバーの前に呼び出されます。
コアモジュールの依存関係をローカルまたはコミュニティのものに「偽装」することにより、カスタムエージェントの後に強制的に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>
私は個人的に、その依存関係を強制する結果がどのような結果をもたらすのかわからないので、このアプローチは好きではありません。
あなたのユースケースでは、発火したかどうかを知るためにデータ/状態を検出する必要があるようです。イベントの順序を強制するよりも、モデルのデータ/状態をチェックする方が望ましいでしょう。
オブザーバーは、最初にエリアで実行され、次にモジュールのロード順で実行されます
つまり、またはに登録されているすべてのオブザーバーの前に、に登録されて<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
、シングルトンオブザーバーで観察してください。ではcatalog_model_product_duplicate
オブザーバーデータとしてセット在庫データ、およびでcatalog_model_product_save_after
使用重複製品の移入在庫にデータという。
catalog_model_product_save_after
。唯一の落とし穴は、呼び出さずにプロパティを永続化することsave()
です...そこで何か考えはありますか?