Magento Observer Events - orden de operaciones


9

Estoy intentando inyectar funcionalidad en el catalog_model_product_duplicateevento. Parte de este módulo será garantizar que el estado del stock del producto duplicado también esté duplicado; Actualmente no lo es.

Veo que CatalogInventoryobserva este evento y establece alguna información estándar sobre acciones. ¿Puedo garantizar que los eventos principales se resuelvan antes que mis locales? ¿Hay algún orden de operaciones aquí en el que pueda confiar?

Respuestas:


11

El orden en que se envían los eventos depende del orden en que se cargan los módulos. Como necesita asegurarse de que los CatalogInventoryobservadores del módulo disparen antes que el suyo, lo que debe hacer es simplemente configurar su módulo para que dependa del Mage_CatalogInventorymódulo. Puede hacer esto agregando un nodo dependiente al código en su app/etc/modules/My_Module.xmlarchivo:

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

El dependsnodo en el XML anterior es la pieza crucial de configuración aquí, ya que obliga al módulo central de Magento a cargar antes que el suyo.


7

El orden en que se envían los eventos no se puede garantizar fácilmente. Dependen del orden en que se cargan los módulos. Por lo general, se llamará a todos los observadores de eventos principales antes que a los observadores de grupos de códigos comunitarios y locales.

Hay un método para obligar a los observadores de magento a disparar después de uno personalizado "simulando" una dependencia de un módulo central a uno local o comunitario. Eche un vistazo a la respuesta de Lee aquí: haga que un observador personalizado dispare ante un observador Magento existente .

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

Personalmente no me gusta ese enfoque, ya que no sé qué consecuencias forzaría esa dependencia.

Para su caso de uso, parece que debería hacer algún tipo de detección de datos / estado para saber si se disparó o no. Verificar un estado / datos en un modelo sería preferible a intentar forzar un orden de eventos.


En mi caso, sin embargo, no tengo nada que hacer si el artículo en existencia aún no existe. ¿Alguna idea sobre un evento posterior que pudiera oler para ver si fue resultado del método duplicado?
philwinkle

5

Una respuesta general

Los observadores se ejecutan primero por área , luego por orden de carga del módulo

Eso significa que todos los observadores registrados en <global>se ejecutan antes que 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 XML de configuración combinado, lo que significa técnicamente en el orden en que se han cargado los módulos.

El orden de carga del módulo se determina de la siguiente manera:

  1. Se crea un gráfico de dependencia a partir de <depends>definiciones en app/etc/modules/*.xml. Si X depende de Y, Y se carga antes que X.

  2. Después de ordenar por dependencia, los módulos centrales tienen prioridad sobre los módulos comunitarios y locales

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

Entonces tiene dos opciones para influir en el orden de carga del módulo:

  1. dependa de otro módulo para que sus observadores se ejecuten después de él (o haga que el otro módulo dependa del suyo para que se ejecuten antes)
  2. Cambie el nombre del archivo de definición del módulo. No necesita cambiar el nombre del módulo en sí porque el nombre de archivo no importa para otra cosa que no sea el orden de carga.

("3. agregar su módulo al grupo de código central" no cuenta)

Ver también:


1

Solo una sugerencia, observe ambos catalog_model_product_duplicatey catalog_model_product_save_aftercon el observador singleton. En catalog_model_product_duplicateestablecer datos de inventario como datos de observador, y en catalog_model_product_save_afteruso esos datos para completar el inventario para productos duplicados.


Entonces, sugieres guardar una propiedad en el objeto que me dieron en el evento, y luego probar eso en catalog_model_product_save_after... eso podría funcionar. El único inconveniente sería persistir en la propiedad sin llamar save()... ¿alguna idea allí?
philwinkle

Guardará el modelo de inventario, no el producto, por lo que no debería quedar atrapado en un bucle.
Petar Dzhambazov
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.