Community Extension is taking precedence over my local extension

Question

Hi I have a local plugin that extends the following class:

class Splitpixel_OrderGrid_Block_Adminhtml_Sales_Order_Grid extends Mage_Adminhtml_Block_Sales_Order_Grid

I use this to modify the following functions:

protected function _prepareCollection()
protected function _prepareColumns()

There is an extension in my community folder that does the same but changes a different function.

class AuIt_Pdf_Block_Adminhtml_Sales_Order_Grid extends Mage_Adminhtml_Block_Sales_Order_Grid

Which edits:

protected function _prepareMassaction()

The issue I am having is my code is not adding a column to the order grid, when using n98-magerun and running "n98-magerun.phar dev:model:rewrite:conflicts

This says three modules extend the same class, and the one that magento uses is another plugin in my community folder.

Ext4mage_Orders2csv_Block_Sales_Order_Grid,
AuIt_Pdf_Block_Adminhtml_Sales_Order_Grid,
Splitpixel_OrderGrid_Block_Adminhtml_Sales_Order_Grid

The following is used over mine: AuIt_Pdf_Block_Adminhtml_Sales_Order_Grid

How can I make sure my class is being used and not masked by this one? Also why would they be conflicting? Even though I am overwriting the same class I am changing different functions?

Answer 1

Both answers given will solve your technical issue, but neither answers your final question, so here goes, with some additional info which will help you understand this a bit more.

Also why would they be conflicting? Even though I am overwriting the same class I am changing different functions?

When you rewrite, you replace the class with your custom class. The entire class file is replaced. It is not merged with the rewritten (original) class. If your custom class extends the original class (not a requirement, but this usually is what gets done), it naturally becomes the parent class, and you can inherit any functionality.

You can only rewrite a class once. That is a limitation on using rewrites. The last loaded module will then logically be the class that replaces the original class.

Module load order is alphabetical (I think, someone correct me if I am wrong, please), but there is also a dependency load order that precedes alphabetical.

If, for example, you know that the other class that is performing the rewrite is no longer adding any functionality to the system, you can simply make your module depend on it. The module load order will then ensure your module load after it, and thus affect the rewrite. Yes, you will get warnings with some tools that there is a conflict, but it is then a false positive, and can be ignored. It helps to document this for other developers (please)

The normal way to solve conflicts is to chain the class files together, and in only one effect the rewrite. You have to remove the rewrite directive form the other modules config.xml. As mentioned this makes upgrading a pain. Again such actions should be well documented. It WILL cause you lots of pain down the road if forgotten, after you update extensions, thus loosing the changes.

As mentioned in one of the other answers, you should try and use events. Most of rewrites done can actually be done with events. Not all. But most. Usually it does require a lot more effort, and more clever code, but that's the fun part :)

Also, when making changes to the display layer, you don't always even need rewrites, or events. By using layouts, you can change the block of a template, and from you new template block simply extend the original template block. Now you have your custom code in action, and can derive all teh core functionality for that blocks output.

Too many times I have seen rewrites for blocks, that is simply not needed. Unnecessary complication.

Anyways, that's my 2c to this answer :)

Have fun.

Answer 2

Here you have three different extensions overriding the same block, which is definitely a problem.

Here's my suggestion:

First disable two of those rewrites to keep only the one of your own module (beware, this change will be overriden if you update the two modules with the rewrite commented).

To disable the rewrite, open the config.xml of the two modules and comment the Mage_Adminhtml_Block_Sales_Order_Grid rewrite statement like this:

<blocks>
    <adminhtml>
        <rewrite>
             <!--<sales_order_grid>Module_One_Block_Sales_Order_Grid</sales_order_grid>-->
        </rewrite>
    </adminhtml>
</blocks>

Add the functions getting overriden in those two modules into your module rewritten blocks.

If I understood right, you need to add _prepareMassaction from AuIt_Pdf_Block_Adminhtml_Sales_Order_Grid and you've not stated which functions the Ext4mage_Orders2csv_Block_Sales_Order_Grid overrides but do the same for this module.

In case the _prepareCollection or the _prepareColumns is also rewritten, you will have to merge the changes implemented to your own changes in order to make it work properly.

One last recommendation: depending on what you want to achieve, I suggest you use events observers instead of block rewrites to make such modifications as it will avoid issues like the one you're facing.

Answer 3

You can tell Magento that your local extension Splitpixel_OrderGrid depends on the AuIt_Pdf. This will make your extension load after the community one, so your class will be used.

You can do this by adding in app/etc/modules/Splitpixel_OrderGrid.xml this inside the Splitpixel_OrderGrid tag

<depends>
    <AuIt_Pdf />
</depends>

And if you want to keep the functionality that AuIt_Pdf brings to the table for your orders grid you should edit the class Splitpixel_OrderGrid_Block_Adminhtml_Sales_Order_Grid and make it extend AuIt_Pdf_Block_Adminhtml_Sales_Order_Grid.

Clear the cache when you are done.