Author - Robert Popovic

I launched Magebase in April, 2010 and am its editor and contributor. My main topics of interest are Magento development, customization and how to get the most out of Magento with the least amount of headache.

More Info » Follow me on Twitter »

Reader Comments (26)

  1. Dan Shields
    Dan Shields
    March 13, 2012 at 8:09 am /

    Actually I think there are a few cases where you have to or there isn’t a better solution out there as of yet. For one, if you are working with Magento Enterprise and you need to change something like a cache container because it isn’t doing what you think it should be doing or there is a bug in it. You submit your bug to Magento but in the mean time you need to change the container code. The only thing you can do is override it in local/Enterprise.

    That is the biggest one that I can see.

  2. Erik Dannenberg
    March 13, 2012 at 8:23 am /

    The local overlay has it’s place imo. I prefer the overlay over rewrites when i need to change existing core functionality that is tied to this magento instance only. On updates those changes need to be revised either way and it lowers the risk of conflicts with 3rd party modules trying to rewrite the same class.

    I agree with most of your points tho, using the overlay carelessly can get messy really fast. Documentation of your changes is a must.

  3. Vinai Kopp
    March 13, 2012 at 8:56 am /

    Great post, thank you Robert! I agree that in almost all cases using the include path to override core functionality is a bad idea.
    You will only ever *need* to use app/code/local overrides for core functionality that doesn’t use the appropriate factory methods (Mage::getModel() for models, Mage::helper() for helpers and Mage::app()->getLayout()->createBlock() for blocks). I think it only is useful for the (very limited) cases where objects are instantiated using the new operator, or sometimes for fixing rewrite conflicts.

    1. Tsvetan Stoychev
      March 13, 2012 at 10:23 am /

      @Vinai quick question about “… or sometimes for fixing rewrite conflicts.” This sounds new to me … can you give a quick example if you have a chance?

      1. Vinai Kopp
        March 14, 2012 at 3:21 am /

        Hi Tvetan,
        rewrite conflicts are always messy, so depending on the rewritten methods this might or might not work.
        That said, many rewrite conflicts can be resolved by copying the class of the module that is loaded last (that is the the rewrite that “wins”) to the local code pool and changing the inheritance so it extends the other class that rewrites the same core class.
        The autoloader will then load both of the replacement classes. This works only if the changes/updated code in the two rewrites doesn’t conflict. In that case you will manually have to resolve the issue.
        Also, when upgrading the modules you will have to update the changed copy in the local code pool manually.

  4. Vinai Kopp
    March 13, 2012 at 9:13 am /

    One more note that I forgot to add to my previous comment, but which I think might be of interrest here: action controllers can’t be overridden using app/code/local, because the standard router always builds the full file system path including the code pool configured for the module. So to override controllers one of the many other options Magento offers must be used.

  5. Mark Hambley
    Mark Hambley
    March 13, 2012 at 10:13 pm /

    I totally agree that it should be a temporary way to alter core functionality, however I wonder how many people edit core files “just for a second whilst I do this thing”…? It depends on how temporary “temporary” is perhaps.

  6. Tim Oliver
    March 14, 2012 at 11:58 am /

    Don’t forget that under Magento’s license, your core hacks and local overrides on public sites should be made publicly available, too (as they’re clearly derivative works, a public site is distribution, and so you need to distribute your changes)

  7. Matthieu MARY
    March 16, 2012 at 10:43 pm /


    I’m agree with you that temporary fix should be made with local override.
    But there is many others situations where we must use this autoloading override mechanism instead of config.xml one:

    – For all classes used by magento but not loaded with the magento api like abstract classes, lib classes, etc: hotfix for zend_framework is one of the example. one other example is address validation before varien rewrote customers attributes: address validation was made in an abstract class, so how can you update validation process with config.xml rewrite?

    – If you do not allow that your code can be overwritten: one example could be a license manager module.

    – To be able to provide a second rewrite mechanism. I’ll take example of classes frequently overwritten. If you wants to also overload it, you have no others choices.

    If the local problem is only the Magento upgrade and compare updates, the source code documentation must be a solution.
    And as you know Varien is not very efficient with backward compatibility so even if you overload source code in config.xml files, it’s important to check if code still work; I’ll take the example of magento upgrade between 1.3 and 1.4 where many events has been renamed. One other example is the acces methods to attributes which has changed; in this two cases, even if you override classes in config.xml, it won’t reduce the risk of backward compatibility.

    And autoloading override has the advantage to be more performant than rewrite in config.xml file because it make class loading faster.

    1. Vinai Kopp
      March 17, 2012 at 1:31 am /

      Hi Matthieu,

      the only case I agree with your list is for classes that are instantiated with the new operator, for example Zend Framework components. Luckily these classes very rarely need to be rewritten. I don’t agree with most of your other reasoning.

      – I find that, with more experience, there is less need to use rewrites. Instead, often event observers can be used to accomplish the same functionality. For abstract classes, rewriting of the concrete implementations is a better solution (in my opinion) then reverting to using the include path hack.

      – PHP license manager modules are a PITA. In all projects I was involved with closed source modules or modules using a license manager where not used, precisely because they prohibit extensibility and upgradeability.

      – Rewrite conflicts are a rare thing (unless a shop suffers from acute moduleinitis, maybe). If you encounter a rewrite conflict it’s ugly already, and in that case using the local include path is a possible solution, since you will not get around modifying some code anyway.
      If you are a developer creating one of the conflicting rewrites, it is better to use event observers instead, which is quite often possible.

      Backward compatibility is sometimes a problem with rewrites, that is true. Once again a reason to focus hard on event observers instead.

      The argument that the files from the local code pool load faster is pretty awful 🙂 This problem should be tackled using the compiler instead of the include path hack.

      1. Matthieu MARY
        March 17, 2012 at 2:40 am /

        Hello Vinai,

        I understand your point of view.

        Observers are a possible solution, and I use them, but make harder code source update. Article says that local overload make code source update harder because we need to make diff. honestly, I prefer make diff instead of going in config.xml and found which observers are called on an event.

        My performance analysis was not to put core/Mage/Core in local. I know that we must used compilation. but between rewrite with config.xml and autoloading rewrite, autoloading is faster.

        My reflexion about backward compatiblity was not about rewrites, but about Magento code source upgrade. Varien do not really take care about this point and so, if we made some overload, with rewrite or with autoloading, we must check backward compatibility.

        For me, local override is a false problem based only upon work methods. this overloading mechanism can provide many solutions, for temporary fixes or for more longer ones.
        But this is my point of view 🙂

  8. Hervé Guétin
    March 21, 2012 at 9:48 pm /

    I so agree with this “local override module” method. I’ve been using it for several months now and it is the best way I have found to gather all project specific Core rewrites. Using well targeted observers (that aren’t called unnecessarily) in this local override module is a great way to change Magento’s behavior from Blocks to Models, Layout… up to config.

    For French readers of this post, may I link here to a blog post that explains this in French?
    Here you go:

  9. Snowcore
    March 28, 2012 at 3:20 am /

    I’m using this approach only for applying patches from Magento Core Team.

  10. Rupak Banerjee
    Rupak Banerjee
    June 25, 2012 at 4:59 pm /


    I can’t agree with this concept of not overriding app/core/local/mage/ . Recently I did a site where, the breadcrumbs need to be changed based on the catalog pages.

    How to achieve this without overriding the Magento default functionality ?

    Thanks And Regards,
    Rupak Banerjee.

  11. Gijsbert
    July 24, 2012 at 7:25 pm /

    I’m quite new to Magento but trying to learn 🙂 I get an error “Could not determine temp directory, please specify a cache_dir manually”. I read various posts and they all tell me to make changes to the file:


    And change ‘cache_dir’ => null to something like ‘cache_dir’ => ‘var/tmp’.

    However, I can imagine that during a upgrade this setting will be overwritten. Someone told me it’s better to copy “/lib/Zend/Cache/Backend/File.php” to “/app/code/local/Zend/Cache/Backend/File.php” and use the Magento overwrite feature.

    Is this in your opinion the right way to fix this or do you recommend other solutions?

    Kind regards,


  12. Jason
    October 30, 2014 at 11:24 pm /

    Hey guys,

    Its a wonderful community and thanks to Robert and so many others whose comments have helped a lot to ease my approach for the magento requirement I am about to begin configuring/implementing. But however I would like to know your suggestion.

    I want to sell same products in different cities with different prices. Moreover the quantity needs to be maintained differently per city. We have come up with two approaches to achieve this. One approach is to have each city a separate magento store, and the product for that city to have a sku which can be understood as city_sku type. The other store would have same product with a differnt city_sku kind. That way I would create same product practically but different products in the eyes of magento. I can manage quantity and price very easily in this scenario. The other approach we have is we figure out a point in magento where we override the quantity and price information, and then rest should be taken care as is. I am not an expert in Magento or in PHP, however I have good experience in various programming technologies etc… I will be able to understand your response (if any) for sure.


  13. Rules of Magento club | molotov.bliss
    December 13, 2014 at 9:24 am /

    […] if this your first time modifying Magento, you have to forget everything else.Magento the right way.Avoid app/code/local/MageMagento Performance Optimization TipsPossibly Related Posts:SellvanaGetting Started with […]

  14. Custom order and customer numbers in Magento: Part 2 - TecHub

    […] it allows us to quickly adhere the logic to our needs. You can read more about this technique in this Magebase article. These classes are Mage_Sales_Controller_Abstract, Mage_Sales_Block_Order_Info_Buttons, […]

  15. Himanshu
    March 24, 2017 at 12:36 am /

    I want to know where Magento define if there is any file in ‘local/Mage’ than get data from that file.
    Provide me suggestion according to your knowledge. Because i want to create new code pool and in that i want to overwrite all code pool data.

  16. Suthan alley
    Suthan alley
    December 22, 2017 at 5:32 am /

    I have researched that editing the core files can become a big problem so it’s better to create a custom module rather than editing the core file as i follow and i almost every article i have seen that creating a custom module is best practice.


Add a Comment & Join the Discussion

Insert small snippets of code by using [code]{your_code_here}[/code]
For larger code blocks please use and paste your link.

You may also use the following HTML in your comment: <a href="" title=""> <abbr title="">
<acronym title=""> <blockquote cite=""> <cite> <em> <strike> <strong>


This site uses Akismet to reduce spam. Learn how your comment data is processed.