Few days ago I had a task of upgrading Magento ver. 1.0.19870.1 to Magento ver. 1.1.1. When you are doing something like that on your own development machine, you probably don’t care much about backing up your database and installation folder. On my development machine I had a clean install of version 1.0.19870.1 where I merely entered few products, categories and other minor things. I had no other theme besides custom one. Before I was ready to do a update to real, shared, remote development machine I decided to test the update on my machine.
Performing local update went smoothly as it gets. On my surprise, everything work as it should be. I was convinced I can go and make upgrade to remote development machine. I had no SVN setup to my remote machine so all my code transfer was done trough FTP. Basically if you’re performing your upgrade trough full archive file all you need to do is copy content from archive to your root Magento installation and overwrite everything you’re asked to overwrite. Sound’s easy, doesn’t it? Well it is easy and your upgrade should go clean and without any glitch, that is if you are using built in theme. If you’re using a custom made theme, chances are you’re rune into trouble like i did.
Magento is a very modular system. If you do a little check on default archive for Magento version 1.1.2 (latest, as of time of this writing) you will see it contains 6 383 files across 2 171 folders. This is huge number of files if you ask me. Magento’s philosophy for building themes is somewhat complex. When i say complex i don’t think in terms on hard to learn but in terms of everything is co cut up into meaningful peaces as they say. However, number of this meaningful peaces is huge. This alone is not the problem, although will take some time getting around. Problem is in the PHP code inside those meaningful little peaces.
Let me be specific. If you want to change something in your checkout page, let’s say make it different then it is in the default template then you go and create your theme according to the manual. Then you realize, that if you want to change checkout page you need to change app/design/frontend/default/your_theme/template/checkout/cart.phtml to suite your needs. You do stuff like calling some Magento helper functions, modifying HTML, adding all sort of styles and so on. Magento works by first looking for files within “your_theme” folder. If corresponding file is there it will pick it up, if not it will use it’s own from the default theme. This is very modular if you ask me. However, there is one problem to it. What if someone deleted some helper or some other function you used inside your theme file? Well you would get errors and your online Magento powered shop would fail to work.
When you do upgrade you overwrite files from default theme folder. However, you preserve all the old files inside your custom theme folder. These are the files that worked with Magento version before the upgrade. In order for them to work after the upgrade all the functions called from this template should be existing. I’ve read a response comment on Magento forum where some said “templates for *** have changed significantly”, probably meaning something like “you’ll have to change your theme significantly because of it”.
I’m not here to judge Magento because of this. It’s a great product, it’s free, it has very bright future and so on. I’m just trying to lay out my conclusions. I was pretty surprised when my Magento shop broke after upgrade, when some things started disappearing and so on. On the other hand, it was quite good experience from which I learned a thing or two about Magento. And one advice before and after the upgrade; try to switch your site to default theme and first do a full check to see if everything is working here. If it is, then you’re ready to bug hunt your theme.