Changing and Customizing Magento Code
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
my_project/ trunk/ scripts/ src/ (magento's code) data/ branches/ vendor/ magento/ app/ lib/ index.php
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.
0.7.14800 was released yesterday. Here is the proper way to upgrade your own SVN repository if you’re using vendor branches as describe above.
Copy files over other files is not going to get you a clean upgrade. Subversion (and CVS) track updates, new files, and deletes. If you simply download and extract a new version, you’re going to miss key file deletes and config file deletes.
Firstly, we need to physically checkout our vendor branch so that we can perform a merge on it. In a clean directory:
svn co http://127.0.0.1/my_project/branches/vendor/magento cd magento
Note: you must checkout with the HTTP protocol with apache and mod_svn, otherwise you will not be able to merge directly from magento’s repository.
You should see some output like:
.... A magento/js/extjs/resources/css/editor.css A magento/js/extjs/resources/css/debug.css A magento/js/extjs/resources/css/dd.css A magento/js/extjs/ext-tree-checkbox.js A magento/index.php A magento/favicon.ico Checked out revision 71.
This means that we’ve done 70 custom changes to our repository (first change being the creation of the repository...).
So, now we will make one more change (revision 72) that includes all the differences between magento 0.6.14100 and 0.7.14800
svn merge --dry-run http://svn.magentocommerce.com/source/branches/beta-0.6-latest@14100 http://svn.magentocommerce.com/source/branches/beta-0.7-latest@14786
If it all goes well (or if it augers well), re-run the command without the –dry-run flag. Commit these changes to your local branch and get ready to merge again.
Now you’re ready to see if all this extra work is worth it. It’s time to merge the vendor branch into your working changes. There is no need to have a physical disk checkout of your branch so you can go ahead and delete it.
cd /path/to/my_project/src/ svn merge --dry-run -r 71:72 http://127.0.0.1/repos/my_project/branches/vendor/magento
Assuming the auger goes well again, remove the –dry-run flag. More than likely, the auger will not go all well and you will see some SVN collisions.
Now you have the option to study any of the collisions and upgrade at your leisure. This is far safer than simply overwriting a package full of files over your hard work.
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:
app/ code/ core/ community/ local/ XyzCorp/
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.
app/ code/ core/ community/ local/ XyzCorp/ Catalog/ Block/ Breadcrumbs.php
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
<modules> <XyzCorp_Catalog> <active>true</active> <codePool>local</codePool> </XyzCorp_Catalog> </modules>
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.
<blocks> <catalog> <rewrite> <breadcrumbs>XyzCorp_Catalog_Block_Breadcrumbs</breadcrumbs> </rewrite> </catalog> </blocks>
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.