In one of my previous articles I showed you how to use getModel and getData methods in Magento. Although we should not put those to methods at the same level, since I’d say the getModel is a bit more higher. Higher in sense, you first use the geModel to create the instance of object then you use getData to retrieve the data from that instance. I have said it before, and I’m saying it again; Magento is a great peace of full OOP power of PHP. It’s architecture is something not yet widely seen in CMS solutions.
One of the architectural goodies of Magento is it’s Singleton design pattern. In short, Singleton design pattern ensures a class has only one instance. Therefore one should provide a global point of access to that single instance of a class.
If you are developing Magento template sooner or later you will need to obtain some product information and rearrange it to fit your template. One of the most useful function while working with Magento is Mage::getModel($modelClass).
Here is how you would use it to retrieve Magento product information Mage::getModel(‘catalog/product’);.
This ‘catalog/product’ relates to app/code/core/Mage/Catalog/Model/Product.php file. If you open that file you will see it’s actually a class named Mage_Catalog_Model_Product. That same class is extending the Mage_Catalog_Model_Abstract class meaning it inherits all of it’s methods.
One of the problems working under the hood of the Magento CMS is determining the context of $this. If you are about to do any advanced stuff with your template, besides layout changes, you need to get familiar with Magento’s objects (classes).
Let’s have a look at the /app/design/frontend/default/default/template/catalog/product/view.phtml file. If you open this file and execute var_dump($this) your browser will return empty page after a short period of delay. By page I mean on the product view page; the one you see when you click on Magetno product. Experienced users will open PHP error log and notice the error message caused by var_dump().
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.
One of the drawbacks of Magento is currently its speed if default configuration is used. There are certain ways of making it run faster.
Let’s start speeding up Magento!