Category Archives: Magento1.x

Magento: Create or Update CMS Page & Static Block, Core Configuration, Product and Category information via Upgrade Scripts.

Why are upgrade scripts helpful

Running the upgrade scripts will automatically update the database when deploying your site to staging and production servers by hitting the url. This can help you to avoid manual setup changes in admin panel when releasing sites to different servers. It also helps us to keep track of all the changes we trigger in admin panel.

To run upgrade script, you need to create a custom module. Download full module from our github

In your module you create a file data-install-0.1.0.php

Update System Configuration:

CMS Static Blocks create or upgrade:

CMS Page Create or Upgrade:

Product Attributes Create or Upgrade:

Category Upgrade:

Update All Category and Run Indexing:

Product Upgrade:

Email Template Upgrade:

Drop table:

Magento: Wrong count in admin Grid when using GROUP BY clause

In Magento 1.x when you use GROUP BY clause in any Grid.php file in admin, the count always display wrong. Many times it displays 1 even if there are many records. Due to this your pagination also doesn’t work. This is a bug in Magento. Your getSize() always returns wrong count whereas total records in grid are proper.

To fix this, you need to edit one of your core file. As it’s not a good practice to edit core file, we will here override the core file. Overriding LIB module.

Copy Db.php file from magento / lib / Varien / Data / Collection / Db.php

Paste it to your local directory so the resultant folder structure would look like this:

magento / app / code / local / Varien / Data / Collection / Db.php

Now open this file to edit and replace getSelectCountSql function with below one

Difference between getsingleton() , getmodel() and getResourceModel() In Magento.


Mage::getSingleton() will first check if the same class instance exists or not in the memory. If the instance exists then it will return the same object from the memory otherwise it load the model, save into Mage Register and return it. So Mage::getSingleton() is faster than Mage::getModel().


$product1 and $product2 both will share same memory of OS and return only one instance each time.

Now take a look at the getSingleton Method in Mage.php :


Mage::getModel() will create a new instance of an object each time even such object exists in configuration.


$product1 and $product2 both have different instant of same object and also occupy different memory.

Now take a look at the getModel Method in Mage.php:


All collections in Magento are resource models. They are instantiated by Mage::getResourceModel() or Mage::getModel()->getCollection(). It doesn’t really matter which function you use; the latter one simply calls the first one. The Magento team simply chose to make collections part of the resource, probably because collections need to query the database a lot. Usually, you will not have to call Mage::getResourceModel() for anything else than collections.

How To Reset Admin Password in Magento ?

In this blog, I am showing how you can reset magento admin password if you lost it and cannot recover using Forgot Password option. I assume that you have the server access of magento i.e Database and FTP access.

For this you have to create a file named reseradminpass.php and paste the bellow code into this file and upload it in your magento root directory.

Here the variable $_HASH_SALT_LENGTH is for salting the password (set 32 for magento1.8 and magento1.9 and set 2 if your magento var is 1.7 or earlier).
Now browse the file as Hence, you can see the new password. So, copy it and replace the password field in “admin_user” table.

And that’s it, now you are able to login from admin using by this given password.

How do I add a static or dynamic block in Magento?

Magento provides an easy way to add blocks with using Layout-XML file and also call directly from the phtml file and added to any category page with no programming at all.

Adding Magento Static block:

from XML:

From phtml/php :

From the CMS page content/Shortcode way:

Adding Magento dynamic block:

From XML:

From the CMS page content/shortcode way:

From phtml/php:

or if the block is already existing in the layout you can get it by name:

Note that all functions available to you within the layout XML via are also available to call on any block in our code. For example, if we instantiated a new block to be added / appended to the head, we could execute something similar to this:

Call Magento Block method/function:

There are two syntax to call block method/function as below.


Example :

It shows the category menu.

Adding Magento Content Blocks:
Add Handle in your local.xml/custommodule.xml so it looks like the following

We’re adding a new Block nested within our root. This is a Block that’s distributed with Magento, and will display a customer registration form. By nesting this Block within our root Block, we’ve made it available to be pulled into our simple_page.html Template. Next, we’ll use the Block’s getChildHtml method in our simple_page.phtml file.
Edit simple_page.html so it looks like this

Clear your Magento cache and reload the page and you should see the customer registration form.

Creating Custom Module in Magento

The first step is creating custom module in Magento is determining the namespace and module name. The namespace is simply an extra division that you can create you module in. This means that you can have two modules named the same thing if they are in two different namespaces. One way to use namespaces is to use your company name or initials for all of your modules.
Magento Modules follow a common naming scheme, Namespace_Module. This is very important to remember as you need to be careful about how you name your classes. Every custom module will be created in the directory:

Where to put our module?

All Magento modules are located in /app/code/ folder and are split into three groups, called code pools: core, community, local.

core – All original Magento modules are placed here. They provide base functionality of system and prototypes of blocks, models, helpers, controllers for further extending. The standard modules are: Mage_Core, Mage_Adminhtml, Mage_Catalog, Mage_Customer, Mage_Sales, Mage_Payment, Mage_Shipping etc. As you have probably noticed, all of them have prefix “Mage_”, we will talk about this a bit later. Unless you are sure about what you are doing (and even afterwards) never edit the code in the core modules.

community – As you can see from the name, this group dedicated for modules that are provided by 3rd party developers (i.e. not by Magento team). When you install this modules throught built-in installer (Magento Connect Manager) all of them will be put into the folder /app/code/community/.

local – This folder is created empty on a Magento installation. Or it can be absent in last versions 1.7.x of CMS, in this case you’ll have to create it manually. Folder /app/code/local/ is used for your custom modules. All development, generally, is performed here.
Except logical splitting modules into groups, this architecture allows us to override any module or separate class in “local” folder without editing original files, which is important for further update of Magento. If we look to the file /app/Mage.php, we’ll see this code:

So, if we have two files with the same name but in different code pools (for example, /core/Mage/Core/Model/Config.php and /local/Mage/Core/Model/Config.php), then file from local pool will be loaded.

Declare Your Magento Custom Module

Create app/etc/modules/Namespace_Module.xml and write below code.

Module Configuration:

Before that, we’ll need to setup a directory structure for the module. You won’t need all these directories, but there’s no harm in setting them all up now.

  • app/code/local/ CompanyName / ModuleName
  • app/code/local/ CompanyName / ModuleName/etc
  • app/code/local/ CompanyName / ModuleName/Block
  • app/code/local/ CompanyName / ModuleName/controllers
  • app/code/local/ CompanyName / ModuleName/Model
  • app/code/local/ CompanyName / ModuleName/Helper
  • app/code/local/ CompanyName / ModuleName/sql

Next, we will begin to configure our module. The configuration files belong inside our module in a directory named etc, so let’s create that along with a new XML file: app/code/local/ CompanyName /ModuleName /etc/config.xml. This XML file will inform Magento of the location of the files in our module, as well as many other things, such as version number and events to observe. For now, we will create a simple config.xml file, which contains comments that explain the meaning of each section.

Create Module Controller:

Now we will create controller app/code/local/Sl/Photogallery/controllers/IndexController.php

IndexController is called by default if we don’t call any other controller, as well as indexAction will be called by default if we don’t call any other action. As we can see, indexAction call only two methods ($this->loadLayout(),$this->renderLayout()) , that initialize and render website page.

Create Module Block:

Now we Create a Block class – app/code/local/Sl/Photogallery/Block/Photogallery.php

Frontend Layout configuration:

All templates and layout files are located in /app/design folder. Magento uses two design areas: “frontend” for public section and “adminhtml£ for backend.

Also there can be “install” area, which is used for installation pages. Themes are split into packages. By default there are two theme packages (base and default) in /app/design/frontend. If theme is not set in Magento configuration, default/default theme will be used by default. We are going to work with this theme.
Usually Magento theme consists of two main folders: “layout”, where layout configuration files are stored, and “template”, where all “.phtml” files are located. At first we need to create layout file /app/design/frontend/default/default/layout/photogallery.xml

Creating Model:

These are the initial steps that you need to follow when creating a model:

  • Create Model constructor class
  • Create Resource Model class
  • Create Model Collection class
  • Create Database table for model

To start with, within your node we need to declare the module version so that later we can create install/upgrade scripts.

Next we declare our model name within the node, which in this case be ‘Photogallery. Inside this we put our model class name which is simply the directory path to your model folder. We also specify our resource model name. After this we use our newly defined resource model name inside a self-titled node where we declare its class (again the file path), and database table name (which we’ll look at later).

The final bit of configuration we need to do is again in our node. When working with models, everything is pretty much scoped globally. We just need to make Magento aware if our install/upgrade scripts.

Creating Model/Photogallery.php class

This model initialisation class is as simple as it looks. From this point onwards we have a model type called ‘photogallery/photogallery’. Always extends the – Mage_Core_Model_Abstract class.

Creating Model/Resource/Photogallery.php class

We have now initialised our resource model, allowing our model to interact with the database. We simply pass in the model name and the database table primary key (which we haven’t created yet).

Creating Model/Resource/Photogallery/Collection.php class

We can now use our resource model to create the ability to grab a collection of our models, which we can do by simply initialising our collection class.

Creating Model/Resource/Setup.php Class

We start by creating a setup class so we can create an instance of the install object. We don’t need to change anything in the original core setup class so you can leave it blank.

Create installer file:


Remember it’s good Magento practice to alias $this object to $installer. I’m gonna create a pretty basic table to demonstrate how it works.

Event Observer:

Event observers are extremely powerful and are one of the cleanest ways to extend Magento’s functionality without having to rewrite or override any core methods or classes. We want to observe the event that Magento dispatches just before the order is saved, so the code for the event we are interested in sales_order_place_before.

How do I find what events exist in Magento?

Figuring out how to find these events is relatively simple. We first need to know how Magento fires events and that is done like this:
Mage::dispatchEvent(‘event_name’, array(‘data’ => $data));

With that we can simply do a search in all of our files to return all the events. You can run this command on Linux/Mac:
grep -r “dispatchEvent(” /path/to/magento/install/)

We now need to modify our config.xml to include the event observer definition:

The above code is our basic config for our model. If you stick to similar naming conventions you’ll get on by fine here.
The main code I’d like to highlight here is contained between the tags. The first tag in represents our event we decided to use earlier on sales_order_place_before, so within here we are defining what to do when that event is fired. Within the tag we have the set up for our Observer. The value within represents the class name of our Observer, and then the value in is the method (or function) we will run when that event is fired.

Creating our Observer.php

Now we can create our Observer and place our code inside our method we will create. To do this create a file named Observer.php in app/code/local/Sl/Photogallery/Model and place the following code:

Cron Job:

Magento allows you to schedule custom tasks in an XML configuration, in a similar manner to the UNIX crontab style. Here we now need to modify our config.xml to include the crontab:

This example will run Sl_Photogallery_Model_Observer::notifynewPhotos method every day at 01:00am (0 1 * * *).
You can find detail about cron here

Finally our config.xml file looks like:

That’s it!!