Changing and Customizing Magento Code

Last modified by Mark_Kimsal on Sun, January 6, 2008 14:19
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)

Subversion

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.

Upgrading to a newer version

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.

The vendor branch

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.

Merging the vendor

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.

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:

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

Edit app/etc/local.xml

      <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.




 

Magento 2 GitHub Repository

Magento Job Board - Some sort of tag line goes here

Latest Posts| View all Jobs