The short answer is: NEVER!
The longer answer is somewhat less absolute and requires some explanation.
Often you will see Magento tutorials or forum posts that implement a feature or functionality change that is different from what the core does which requires changing something in the core of Magento. Someone may then advise that, instead of hacking core files it is better to copy them into theapp/code/local/Mage location and perform the modifications there, so that, upon upgrade, the modifications are not lost. This process is called overriding Magento core functionality and is based on the fact that Magento sets its PHP include paths to first look in app/code/local/ thenapp/code/community/ and finally in app/code/core/. This has the effect that any files of the same name placed under the local or community name space will take precedence in loading, hence, we can override almost any core file in this way. To learn about how exactly Magento sets up its system, read the excellent series on the Magento Configuration by Alan Storm.
This is one, sometimes recommended, way of overriding core functionality without hacking the core but why is it, as you may conclude from my initial statement, so bad?
First, let’s see what scenarios would be compelling us to override core files:
1. We want to change a piece of functionality in a core method so we copy the php file containing the code and modify one or more methods.
2. We want to add a new method to a core block class, so it’s available for use in the phtml template so we copy the relevant core Block php file and add our method to it.
3. We may have several modifications consisting of core functionality changes and additions over several files.
So, what are we actually doing here, when we override core files?
For one thing, we must override the complete core file because we can’t trim out the stuff that we don’t want changed since we would lose all that functionality and most likely break Magento. Once the overridden file is in place, this will be the file and code Magento will be using from now onwards. Given that most core classes contain several and many times a large number of methods it means that we are effectively overriding all those methods in our file.
Now, remember when we were advised to use this override approach so we can make sure that our customizations are going to be preserved after a Magento version upgrade? Well that, indeed, will be true, but, what if the new Magento version has changes in the very files we have previously overridden? What if they have newly implemented methods or bug fixes in existing methods? Since our override will always take precedence, these new features and fixes will never be operational as our override runs all the old code. If you’re lucky, you may get an error report because a new change falls over due to missing methods but what if you don’t get error reports and instead, somehow, some inexplicable and erratic behavior starts expressing itself on your site?
You can see the problem now, right? After each upgrade, you will have to go and check all yourapp/code/local/Mage/ overrides and compare them to the new core files and port any core changes to your local override in order to maintain your site’s integrity. If you have lots of such overrides, this will be tedious. Also, if you are a developer who gets passed on an existing site with these kinds of overrides, you will not be happy. Often you won’t even know what the purpose of the override was and you’d need to laboriously go from diff to diff and decipher the meaning of any changes. It gets worse if the previous developer already performed some Magento upgrades.
By now, I guess, you have a good idea about the dangers of applying this kind of override, so, let’s get back to our original question, when, if at all, should you use this approach?
There are a few cases when this approach may be justified, in my opinion, these are the cases:
If you want to quickly try a core modification to see if it will solve your task as a proof of concept, but don’t want to create an extension just yet. When you are satisfied, you remove your override and implement a proper Magento extension with rewrites.
If you are implementing a temporary override of some core functionality that you will remove after your task is complete. A prime example of this is overriding the Magento dataflow classes for importing, when you want to change the way the importer handles certain things in an initial customer or product import.
The key concept here is: temporarychanges/experiments. You are not planning on leaving your overrides.
Note: There are some other scenarios where local Mage overrides are the only way to customize parts of Magento’s core functionality. I’d like to encourage a discussion in the comments to see what others think about this.
Conclusion
The take-away from this article is, never use the app/code/local/Mage/ approach to permanently override core functionality! If you must, then only use if for temporary changes that you will remove afterwards.
As for the question that now presents itself: how, then, should you implement core overrides? The answer is by creating a custom Magento module and using the available class rewrite mechanisms, or better yet, using event observers if possible.
