Recently I had a task to modify sorting in only one category of Magento shop.
What I had to do is “only” to change which attribute will be used for default sorting and I needed to reverse ordering from ascending to descending.
Task seems simple, right?
When you work with custom (your own) controllers in Magento,
either frontend or backend, you will probably also use existing blocks and models or if needed write your own classes.
But what happens if you want to or have exigency to move/remove common blocks?
Can you really “design” your own page view without touching Cascading Style Sheets?
As we all probably know, there are some events in Magento that are dispatched by default.
We can easily hook on those events, but this is not a subject of this article.
What we are going to try now is to add custom event before and after some action in some of Magento’s controllers.
In its MVC structure, Magento allows you to throw in additional classes that might not fit in strictly under the MVC “letters”. One example of these classes are helper classes. These are usually used to isolate a certain, possibly useful, algorithm. Algorithm whose usage would be overhead to write a model as it is more static and general in nature, meaning there is no point in applying it to given instance of an object.
Hi, today I’ll show you how to edit Magento’s core module without messing with core files themselves, or “the right way of doing things”. 😀
Creating your own Magento module usually goes along with creating your own models within the module. Either you write one or multiple models per module, its a good idea to implement model validation method which you might/should call prior to model save. Good example of Magento’s model that use validation are Mage_Customer_Model_Customer and Mage_Customer_Model_Address_Abstract models. Quick look into the “public function validate()” methods of those two models reveal the simplicity of validation process.
Given the sheer size of Magento system, its quite easy to loose valuable time when trying to achieve even the basic things like “Creating simplest ORM model class”. Substantial amount of serious programming in Magento requires you to write some values to database.
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.