Magento: How do you disable or change the way the primary observer works

Question

I was wondering about this for a while. What if Magento wrote the main Observer class and performs functions that you do not want to perform, or do you want to rewrite them? Is there a way to say do not use this method in Observer, just use mine. If I set up a method for my own observer, will he not perform the main functionality first, and then, whatever I implement?

For example, Magento wants to store some data in a database in the Observer method, but I do not want it to save this data at all, I want it to save some other data that I added to the columns or attributes of the database for.

Answer 1

The standard class override clause is the last resort to your own functionality.

You can probably play around loading the Magento global configuration to cut out the main Magento Observer, but there is no supported way to do this.

However, consider how the main observers are configured.

<adminhtml> <events> <cms_wysiwyg_config_prepare> <observers> <widget_observer> <class>widget/observer</class> <method>prepareWidgetsPluginConfig</method> </widget_observer> </observers> </cms_wysiwyg_config_prepare> </events> </adminhtml> 

Observers are the classes of the Magento model. If the model was configured with URI / path-based syntax

 <class>widget/observer</class> 

unlike the full class name of PHP

 <class>Mage_Widget_Model_Observer</class> 

you can create an override for the Model Observer class (just like for any other model). If the PHP class name was used, you're out of luck. (You can place the local file in the local /Mage/Widget/Model/Observer.php if you are ready to take charge of the service, but I do not recommend it)

So, to redefine the above observer, you would

• Create a custom module that includes an override for the Mage_Widget_Model_Observer class.

• In your redefinition class, either redeclare prepareWidgetsPluginConfig to do what you want, or override a specific method. This may include an empty method to completely remove functionality.

Answer 2

The best way to do this is to simply re-declare the observer definition in the config.xml file.

For example, I needed to disable the observer enterprise_persistent_cart , which was declared in the controller_action_layout_generate_blocks_after event using the Enterprise_Persistent module.

The declaration in the Enterprise_Persistent config.xml is

 <frontend> <events> <controller_action_layout_generate_blocks_after> <observers> <enterprise_persistent_cart> <class>enterprise_persistent/observer</class> <method>removeCartLink</method> </enterprise_persistent_cart> </observers> </controller_action_layout_generate_blocks_after> 

So, I created a module, and in my config.xml module I did the following:

 <frontend> <events> <controller_action_layout_generate_blocks_after> <observers> <enterprise_persistent_cart> <type>disabled</type> </enterprise_persistent_cart> </observers> </controller_action_layout_generate_blocks_after> 

I also made my module dependent on the Enterprise_Persistent module. This is necessary to ensure that my config.xml module is processed AFTER the USER Enterprise_Persistent module.xml. I did this by doing the following in my module application / etc / modules. Module declaration file My_Module.xml

 <config> <modules> <Atlex_AddCartLinkToHeader> <active>true</active> <codePool>local</codePool> <depends> <Enterprise_Persistent/> </depends> </Atlex_AddCartLinkToHeader> </modules> </config> 

For each event, there can only be one observer action specified for a given observer name. Therefore, while my config.xml module is being processed after the config.xml file Enterprise_Persistent, my observer declaration for enterprise_persistent_cart will be the action of the observer.

Type < disabled < / type node will disconnect the observer from shelling. If you want to override the observer to execute your own method, you simply replace the type < node to your observer < class and < .

This allows you to override / disable observers without overriding the main classes. It is more extensible for future developers.

Answer 3

I wanted to add a comment to @Alan's answer, because I think he nailed it, but my comment is too long and not enough formatting! Here:

Nice one @Alan, a smart way to fix what seems like a hole, while still respecting the architecture. A few thoughts:

• if the user module is associated with the same event, will the user observer be called later in the responsibility chain than the core, and therefore can override the main observer? It depends on what the main observer does, for example, setting the divert value. In the given OP example, this will work. When binding to the Model_save_before event, the Observer kernel will be called, but your Observer will still be able to modify the contents of the model's save data before it is written to the database. You can change or disable the values ​​affected by the Observer kernel.

• to override the main Observer model, inserting <models><widget><rewrite> into config.xml would be the right approach

• This may be one of the few cases where a call to parent:: not required when overriding (!)

NTN, JD

EDIT - additional information added in step 1 to answer the specifics of the OP question

Answer 4

Thanks Jonathan, I override Observer with the syntax of the base model syntax

 <config> <global> <models> <sales> <rewrite> <observer>PPI_Sales_Model_Observer</observer> </rewrite> </sales> </models> </global> </config> 

It worked out well.