Changing and Customizing Magento Code

Last modified by Mark_Kimsal on Sun, January 6, 2008 13:54
Source|Old Revisions  |  Back To Group

This is an old revision of the document!

If you’re finding that you need to make changes to Magento’s code to fit it into your organization, you’re probably wondering what is the best way to make these changes so that you can keep your code separate from the main code.

Skill level: Beginning to Advanced developer.

Target Audience: Developers who need to customize PHP Code.

Tested with Magento versions:

  • 0.6.14100 (BETA)
  • 0.7.14800 (BETA)


The best way to keep track of all your changes is with a tool like Subversion (SVN) or CVS. You can use branches for the base Magento code. This will keep you customized files from being blatantly overwritten whenever you update Magento.

Here is an example code layout

                   src/  (magento's code)

Under the “magento” directory, we have an export of Magento’s latest SVN (0.6 beta). Now, we can use SVN’s merge to copy the changes that happen to that one directory (branches/vendor/magento) into our main directory (trunk/src/). The first time, the changes will only be between revisions 1 and 2 (if don’t make any mistakes setting up the repository). But, every magento release, you will only have 1 revision change, for example: after making 100 changes to your store you are at revision 101. You update the Magento vendor branch with version 0.8 beta. Now you are at revision 102. And the difference between 101 and 102 contain all the Magento changes between 0.6.14400 and 0.8.2620 (imaginary magento numbers). So, when you merge 101:102 into your main/src directory, Subversion will do its best to only apply the changes, and not simply overwrite all your hard work with new files from 0.8.2620.

Custom Modules

Most likely you will want to make a module that represent’s your company to hold all your specific changes. Start off by making a new directory like so:


Now, if you need to make changes to the Magento file, Mage/Catalog/Block/Breadcrumbs.php, you can add a new directory for the “Catalog” module under your XyzCorp directory, then a blocks directory and copy the file into this new directory.


Change the class name inside the file by starting off with “XyzCorp” instead of “Mage”.

Strip out all the code you don’t need, and make it subclass the original class name (”Mage_Catalog_Block_Breadcrumbs”).

Now, you must activate your module so Magento understands that there is new code in the “local” directory.

In app/etc/local.xml, add the following lines


It is crucial that the same prefix XyzCorp is used throughout files, class names, directories, and XML tag names.

Now, your own catalog module is activated, but when will it actually be called by the system? Ahh, we need a special rewrite tag to instruct Magento to use this one file (Breadcrumbs.php) instead of its default.

We need to edit the same XML file again, but this step is highly dependent on what you are editing. So we will detail only how to do customized blocks.


Edit app/etc/local.xml


Can you see what is changed? We need to add a “blocks” tag, or edit inside an existing blocks tag, depending on your XML file. Then we add a rewrite tag after our module name, which is “catalog” in this case. Then, we throw in the word “breadcrumbs”. This “breadcrumbs” name must match a block type in the app/design/frontend/default/default/layout/main.xml file. The data inside the breadcrumbs tag is the name of your classfile, and Magento knows how to find it because the class name is the same as it’s directory path and filename.


Magento 2 GitHub Repository

Magento Job Board - Some sort of tag line goes here

Latest Posts| View all Jobs