Pregunta

Estoy intentando inyectar funcionalidad en el caso catalog_model_product_duplicate. Parte de este módulo será asegurar que el estado del stock del producto duplicado también se duplica; Actualmente no lo es.

veo que CatalogInventory observa este evento y se pone un poco de información de la norma. Me pueden garantizar que los eventos principales se resuelven antes de mis vecinos? ¿Hay alguna orden de las operaciones aquí que puedo confiar en?

¿Fue útil?

Solución

El orden en que los eventos se envían en depende del orden en el que se cargan los módulos. Puesto que usted está necesitando para asegurarse de que los observadores del módulo CatalogInventory fuego antes de que el suyo lo hace, lo que hay que hacer es simplemente configurar el módulo de depender del módulo Mage_CatalogInventory. Usted puede hacer esto mediante la adición de un nodo depende del código en el archivo de app/etc/modules/My_Module.xml:

<config>
    <modules>
        <My_Module>
            <active>true</active>
            <codePool>local</codePool>
            <depends>
                <Mage_CatalogInventory />
            </depends>
        </My_Module>
    </modules>
</config>

El nodo depends en el XML anterior es la pieza crucial de la configuración aquí, ya que obliga al módulo de núcleo Magento a la carga antes de suyo lo hace.

Otros consejos

El orden en que se envían los eventos no puede ser fácilmente garantizada. Son depende del orden en que se cargan los módulos. Por lo general todos los observadores de eventos principales serán llamados antes de la comunidad y los observadores locales billar código.

Hay un método para observadores fuerza magento a fuego después de una medida por "falsificar" una dependencia de un módulo central a uno local o de la comunidad. Echar un vistazo a la respuesta de Lee aquí: Hacer un observador personalizada fuego antes de una ya existente Magento observador .

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

Yo personalmente no me gusta ese enfoque como no sé qué consecuencias obligando a que la dependencia tendrían.

En su caso de uso, lo que parece que se debe hacer algún tipo de detección de datos / estado para saber si fue despedido o no. Comprobación de datos de un / el estado de un modelo sería preferible que tratar de forzar una orden evento.

una respuesta general

Los observadores son ejecutados por área primero, y luego por módulo de orden de carga

Eso significa que, todos los observadores registrados de <global> se ejecutan antes de todos los observadores registrados en <frontend> o <adminhtml>.

Dentro de un área, los observadores se ejecutan en el orden en que aparecen en el árbol de configuración XML combinado, cuyos medios técnicamente en el orden de los módulos se han cargado.

orden de carga del módulo se determina como sigue:

  1. grafo de dependencias A se construye a partir de las definiciones <depends> en app/etc/modules/*.xml. Si X depende de Y, Y se carga antes de X.

  2. Después de pedido por dependencia, módulos básicos tienen precedencia sobre la comunidad y módulos locales

  3. Todo lo demás se carga en orden alfabético. Tenga en cuenta que el nombre del archivo en app/etc/modules se utiliza para la comparación, no el nombre del módulo actual.

Así que hay dos opciones a fin de carga módulo de influencia:

  1. depender de otro módulo para tener sus observadores ejecutado después de haber (o hacen que el otro módulo dependerá de los suyos para tenerlos ejecutados antes)
  2. Cambie el nombre del archivo de definición de módulo. No es necesario cambiar el nombre del módulo en sí, porque el nombre del archivo no importa para nada más que el orden de carga.

( "3. Añadir su módulo a la piscina de código del núcleo" no cuenta)

Ver también:

Sólo una sugerencia, observe tanto catalog_model_product_duplicate y catalog_model_product_save_after con un observador Singleton. En conjunto los datos de inventario catalog_model_product_duplicate como datos de los observadores, y en uso catalog_model_product_save_after que los datos de inventario a poblar para el producto duplicada.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a magento.stackexchange
scroll top