Ever needed to test a new payment module, or shipping rate? Hate going through the checkout multiple times? Well, I’ve put together this simple little bookmarklet:

javascript: (function(){
    document.getElementById("login:guest").checked="checked";
    checkout.setMethod();
    document.getElementById("billing:firstname").value="John";
    document.getElementById("billing:lastname").value="Doe";
    document.getElementById("billing:email").value="demo@example.com";
    document.getElementById("billing:company").value="Acme Corp";
    document.getElementById("billing:street1").value="Doe House";
    document.getElementById("billing:street2").value="Doe Road";
    document.getElementById("billing:city").value="Doe Town";
    document.getElementById("billing:region").value="Doe Region";
    document.getElementById("billing:postcode").value="DO33 3OD";
    document.getElementById("billing:telephone").value="12345678901";
    document.getElementById("billing:fax").value="";
    billing.save();
    function waitForBilling() {
        if(checkout.loadWaiting != false){
            return setTimeout(waitForBilling, 50);
        }
        document.getElementsByName("shipping_method")[0].checked="checked";
        shippingMethod.save();
    }
    waitForBilling();
})();

To use, simply create a new bookmark, and enter the above code into the URL section of the bookmark and keep the bookmark in your bookmarks toolbar. Now, when you hit the first stage of the onepage checkout, click your bookmarklet. It will populate your fields, and progress you to the payment stage. Easy!

Word of warning: This bookmarklet is not perfect, and feel free to tailor the information contained, this has been put together for UK stores which doesn’t require a region (I entered dummy data anyway, but if you are for example a US user, you will need to change this value in relation to the states dropdown menu.)

Other solutions? Yep, you could just create an account, and use that. However sometimes we need to test as a guest user.

Don’t want to skip shipping methods? Simply remove lines 16 – 23.

Time and time again I need to create a custom category attribute for a site I’m working on, and each time I search for a good article covering the topic in depth I fall short, and half written and poorly explained versions of how to do exactly this. I’ve learnt how to do this over time, and now I’ll share exactly how to, and also how it works. First of all, I’ll show you the code for each file, and explain everything afterwards.

Lets get going then..

To create a custom attribute we are going to create it as a module, the reason for this is so when we come to install our Magento site on another server, or if our extension we’re developing needs to be used on other Magento installs our custom category attribute will be installed if it doesn’t yet exist!

First of all let’s set up our basic module file structure we need for this:

app/code/local/Meteorify/Customcatattrb
app/code/local/Meteorify/Customcatattrb/etc
app/code/local/Meteorify/Customcatattrb/sql/customcatattrb_setup

Now let’s create the files, first up is our config.xml, this is the main file within your module which tells Magento which controllers and models to load, plus plenty more.

Save this file to: app/code/local/Meteorify/Customcatattrb/etc/config.xml

<?xml version="1.0"?>
<config>
  <modules>
    <Meteorify_Customcatattrb>
      <version>0.0.1</version>
    </Meteorify_Customcatattrb>
  </modules>
    <global>
      <resources>
          <customcatattrb_setup>
            <setup>
              <module>Meteorify_Customcatattrb</module>
              <class>Mage_Eav_Model_Entity_Setup</class>
            </setup>
            <connection>
              <use>default_setup</use>
            </connection>
          </customcatattrb_setup>
      </resources>
    </global>
</config>

So what we have done here is defined a few requirements for our module. We tell Magento to load in the setup resources, and which database connection to use. If we wanted, we could define our own class for the setup, extending off of the same class specified above so we can do a few more things to install our attributes. However that is out of scope for this article today.

Next up, let’s create yet another XML file, this time it’s our file which lets magento know we have a module to be loaded in, and where the module is located.

Save this file to: app/etc/modules/Meteorify_Customcatattrb.xml

<?xml version="1.0"?>
<config>
  <modules>
    <Meteorify_Customcatattrb>
      <active>true</active>
      <codePool>local</codePool>
    </Meteorify_Customcatattrb>
  </modules>
</config>

As mentioned above, all this file does is let Magento know this module exists, and to load it. We also specify which code pool it belong to (either Community, Core, or Local).

Last but not least, is our install script. This is a tiny script which will install our attribute to the database, and we can start using our newly created attribute straight away after!

Save to: app/code/local/Meteorify/Customcatattrb/sql/customcatattrb_setup/mysql4-install-0.0.1.php

<?php
$installer = $this;
$installer->startSetup();
$attribute  = array(
    'type' => 'text',
    'label'=> 'Bottom Description',
    'input' => 'textarea',
    'global' => Mage_Catalog_Model_Resource_Eav_Attribute::SCOPE_GLOBAL,
    'visible' => true,
    'required' => false,
    'user_defined' => true,
    'default' => "",
    'group' => "General Information"
);
$installer->addAttribute('catalog_category', 'bottom_description', $attribute);
$installer->endSetup();

Once you have done all of this, clear the cache, and head over to Catalog > Manage Categories and you will now see your new custom attribute appearing at the bottom of the General Information tab. Perfecto!

Explanation of our module

In this dead simple module the main points I want to make is about our install script we created. Whenever we install this module on another Magento install our attribute will be created along with it. Making it super easy to maintain! So let’s dig into it a bit, and learn what else we can do with this.

Let’s start with our $attribute variable which contains an array of values.

type = The character type, it can be any of the following: text, varchar, or int

label = Label is the visible name of our attribute. This allows us to define a more human friendly title to our attribute.

input = Input is how the data will be inputted by the end-user. In this case we used a textarea, but we can also use text, or other ones such as drop downs, multi-selects and date ranges. We’ll cover these other attributes in more depth another time.

global = Global simply defines the scope of the attribute. By default I use the global scope available on all store views, and website views.

visible = Is a boolean, it simply states whether or not the module is visible to the user or not.

required = Self explanatory, we can set this to true to make the field mandatory for the user to fill in before saving the category.

user_defined = If the user can define the value of this or not.

group = The tab where this attribute will live. If you enter a new tab name, it will create the new tab for you.

Parameters I didn’t include:

sort_order = Here we can define which position this attribute appears when editing a category.

option = If we have defined our input to be a drop down or mutli-select we can use this to define our different options, see the code below for a complete example:

'option'=> array ('value' => array(
    'optionone'=> array( 
        0 =>'My First Option'),
    'optiontwo'=> array( 
        0 =>'My Second Option'))),

And thats how you create a custom category attribute

I hope you learnt something from this article. I have personally learnt more researching for this article than I have trying to find an article to simply follow.

I will be doing a follow up post covering attributes in a more complete way, covering custom product attributes, CMS page attributes and more!

If you have any questions, post them in the comments and I’ll do my best to answer. Although, stack overflow will be the best place.

Whether you’re developing a theme, or a new extension for Magento the whole process can be made a lot easier when you know various in’s and out’s of Magento. Including some of the in-built development tools ready for you to use.

In this post I’ll cover two ways you can speed up your development. These tips have served me well, and I use these on a daily basis, hopefully you will be too.

Enable Template paths hints

Ever tried debuging why your Magento theme isn’t updating? Maybe it’s not actually using your template for some reason. Enabling Template Path Hints will help you find which templates & blocks are being used in your themes!

To enabled this simply head over to System > Configuration > Advanced > Developer and change the configuration scope (top left) to your desired store view. Under the debug menu is two options Template path hints and Add Block Names to Hints, once enabled your theme will now display a breakdown of all the template files, and also the block names so you can see which block modules are loading too.

Another useful feature under Developer Client Restrictions is allowing certain IPs to view your enabled template paths. This helps if you need to quickly debug something on a live site.

Enabling logging & use Mage::log()

Mage::log() is one of my most used lines of code in Magento whilst I’m developing themes and modules. This is because we can use Mage::log() to log anything, and get the contents outputs of objects and arrays without var_dump’ing.

First of all you need to enable logging, head over System > Configuration > Advanced > Developer and under Log Settings simply enable the log, and leave the other default values.

To use Mage::log() in your theme, or module you can simply add this line: Mage::log('Hello World') and when you run your script, over in var/log you will see a system.log file which will now contain your debug message!

Taking this a step further, we can output arrays and objects using Mage::log(), just simply pass it as a variable.

If you want to customise the output a little, for example save to a different log file, then no problem! Here’s all the parameters the log method takes:

Mage::log($message, $level = null, $file = '', $forceLog = false)

With this, we can change a few settings, most importantly where the log saves to.

Mage::log($message, null, 'mylogfile.log');

In var/log you will now see a file named mylogfile.log! Brilliant. We can use this to split up our logging. General PHP errors will get logged to system.log, so by separating our debug logging we can easily scan our log file for what really matters in the early stages of development.

Have your own Magento Development Tips & Tricks?

I would love to hear any tips and tricks you have for magento development. If you are using any particular development extensions, or are the creator of one, please share it and I’ll likely feature it here on the meteorify blog too.

In this series about creating a faster magento store, I will walk you through a number of must-do things that can speed up your Magento stores dramatically. A lot of these tips are easy, and free, a few are technical and require server knowledge and are best carried out by someone who knows their way around a server.
This series will go from optimising your server, and getting your initial magento install set up. I highly recommend these changes are made on a separate server, perhaps a VPS/Cloud Server. I personally use Rackspace Cloud Servers to create new servers quickly.

What are we going to do?

The main thing we are going to do is installed Nginx, Varnish and PHP-FPM, these all improve performance in their own way. So let’s get started.

Why are we using Nginx, Varnish and PHP-FPM?

Nginx is a web-server, like Apache, but boosts much better performance results, and is much more stable when handling lots of requests, which results in high CPU usage and can slow down your entire server. Apache, for example, doesn’t scale quiet so well without a large amount of know-how, and in my experience I have found it easier to use an alternative web server, hence Nginx! Now, Nginx isn’t without it’s flaws, you will need to install PHP-FPM, which is a FastCGI Process Manager for PHP, essentially it allows us to use PHP via FastCGI, I believe their are alternative solutions to this, however this is one I have come across and is simple enough to setup

Varnish Cache is a HTTP proxy or sometimes referred to as a HTTP accelerator. What Varnish does is sit between you and your web-server, when a page is requested Varnish will check if it has a cached version and return it to the user, if not it simply passes the request onto the normal web server (in this case Nginx), it then caches it so in future it can be returned quickly. What’s even better about Varnish is it makes use of the physical memory on your server as opposed to the CPU, which results in high speed without slowing your server down. This leads to some seriously good performance results.

Server Requirements

This article does presume you’re using a CentOS based server, and it’s a fresh install (CentOS 6 or greater), if you are using an existing server, parts of this article you will be able to skip, and equally you will need to either stop Apache from running or change the port it runs on when it comes to the stage of running Varnish/Nginx.

For the best performance results, use a dedicated server. VPS’s are great, but they do share resources and I don’t like relying on them heavily. If you expect your sites to take on a lot of traffic, go for a dedicated server, if not a VPS will be great, and very low cost too.

rpm -Uvh http://download.fedoraproject.org/pub/epel/6/x86_64/epel-release-6-7.noarch.rpm
rpm -Uvh http://rpms.famillecollet.com/enterprise/remi-release-6.rpm
yum install mysql mysql-server
/etc/init.d/mysqld restart
/usr/bin/mysql_secure_installation

As you run through the installation process for mysql note there is no root password by default. Read each step carefully. I highly recommend you set a root password, and all options should be set to yes for the optimal setup.

yum install nginx
/etc/init.d/nginx start
yum --enablerepo=remi install php-fpm php-mysql php-pdo php-common php-mcrypt php-gd php-curl php-soap
vi /etc/php.ini

When you open up php.ini, find cgi.fix_pathinfo and set the value to 0

Next up we need to create our virtual host in Nginx so our site can be accessed from the web! to do this simply enter:

vi /etc/nginx/conf.d/magentosite.conf

Then modify the details below to match your needs:

server {
    listen      8080;
    server_name www.magentosite.co.uk;
    root        /var/www/sites/magentosite/;
    index index.html index.php;

    access_log /var/log/nginx/www.magentosite.co.uk-access_log;
    error_log /var/log/nginx/www.magentosite.co.uk-error_log;

    location / {
        try_files $uri $uri/ @handler;
        expires 30d;
    }
    location /app/                       { deny all; }
    location /includes/                  { deny all; }
    location /lib/                       { deny all; }
    location /media/downloadable/        { deny all; }
    location /pkginfo/                   { deny all; }
    location /report/config.xml          { deny all; }
    location /var/                       { deny all; }

    location /var/export/ {
        auth_basic              "Restricted";
        auth_basic_user_file    htpasswd;
        autoindex               on;
    }
    location  /. {
        return 404;
    }

    location @handler {
        rewrite / /index.php;
    }

    location ~ .php/ {
        rewrite ^(.*.php)/ $1 last;
    }

    location ~ \.php$ {
        try_files $uri =404;
        expires off;
        fastcgi_read_timeout 900s;
        fastcgi_index index.php;
        fastcgi_pass 127.0.0.1:9000;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        include /etc/nginx/fastcgi_params;
    }
    rewrite ^/minify/([0-9]+)(/.*.(js|css))$ /lib/minify/m.php?f=$2&d=$1 last;
    rewrite ^/skin/m/([0-9]+)(/.*.(js|css))$ /lib/minify/m.php?f=$2&d=$1 last;

    location /lib/minify/ {
        allow all;
    }
    gzip on;
    #gzip_comp_level 9;
    gzip_min_length  1000;
    gzip_proxied any;
    gzip_types       text/plain application/xml text/html text/css text/js application/x-javascript;
}

In short what the above does is create a virtual host much like how we do in Apache, assign a server name, and root directory for where the store is set. We then also do various other tweaks to pass PHP requests to PHP-FPM, and to allow friendly URLs without index.php.

Most importantly I have set nginx to run on port 8080 rather than the usual port 80. This is so we can run Varnish on port 80, and pass requests onto 8080. We will be installing varnish shortly

Next we want to configure php-fpm to work nicely with Nginx, to do this simply open up /etc/php-fpm.d/www.conf and find the User & Group settings, and set both the user and group to ‘nginx’.

Now restart php-fpm:

service php-fpm restart

If you want to quickly test your changes before adding your magento installation simply create a file in your root directory you defined in your nginx conf and set it to output phpinfo();

Then finally restart nginx by doing service nginx restart. You can then navigate to your site followed by :8080 (e.g. http://example.com:8080/) you should now see details about your php configuration. Perfect! If you receive a 500 error, try changing the ownership of your files and folders for the root site to the nginx user. Like so:

chown -R nginx:nginx /var/www/mysite

Great, so you have your site working on port 8080! Now let’s get varnish installed and configured to run on port 80!

To install varnish simply run:

sudo yum install varnish

Great, now we have that installed let’s get Varnish running on port 80. This is so when we first request a page it will go through to Varnish cache first, check if a cached version exists and return that, if no cache exists it’ll pass the request to nginx, which in turn will then cache that and return it to the user.

vi /etc/sysconfig/varnish

Now find VARNISH_LISTEN_PORT=6081 and change it to port 80, save and close.

Next up we want to update the default configuration for our server. We need to check what version of Varnish we have installed, as this will dictate which configuration file we need to load in. You can run the following command to find out your version:

sudo varnishd -V

My version was 2.1.5, so I can use the first set of code below. I have both of these configurations saved using Gist by GitHub, so you can head to one of the following links to jump directly to the configuration you require: version 2.1 or version 3.0+

We’ll want to place this configuration in the following file:

etc/varnish/default.vcl

Varnish configuration for version 2.1:

Varnish configuration for version 3.0+

Now we can fire up Varnish:

service varnish start

Now if you access your site again but without the port :8080 you should see your entire site working perfectly!

From here you can set up your database, and install magento. Once that is done, install the following plugin:
PageCache powered by Varnish this will allow you to clear the Varnish cache from within the Admin and auto-clear after saving categories/products or CMS pages. Very handy indeed.

Then when logged into the Magento admin head over to System > Configuration > Advanced > System. You’ll notice a new section labeled “PageCache powered by Varnish settings” Enable the module, set the varnish port to 80, and you may also want to set the purge settings to yes, these will enable auto-purging when categories/products or CMS pages are edited. Very handy for getting your changes live before the cache expires on it’s own.

You can also make sure everything is set to run on startup with these simple commands:

chkconfig --levels 235 mysqld on
chkconfig --levels 235 nginx on
chkconfig --levels 235 php-fpm on
chkconfig --levels 235 varnish on

Known Quirks

• If you have design exceptions i.e. a mobile site. Varnish cache will not work. I’m working on a fix. But, if the budget is there purchase the full-version of the free extension.
• Your .htaccess will no longer work, that’s because we’re not using Apache anymore. So any unique changes in there need to be transfered directly to your PHP settings or to your nginx VHOST setup.

Finishing up

And we’re done with this part of the series. From here on we’ll be looking at various other ways we can speed up our stores by optimising our site resources to increase speed further. Plus various other plugins we can use to speed up our stores.

If you have any questions, or even suggestions on how you optimise your servers for the best performance on Magento stores, please use the comments!

When developing for Magento, often most peoples first action is to override a particular class or method from the core. They also usually use the same namespaces and copy into the local folder like: local/Mage/Sales/Model/Orders.php for example. While this is handy for a lot of things, often people don’t know, forget about, or don’t know how to make use of an Observer when that is 9 times out of 10 the better approach.

In this little tutorial I’ll teach you how to create an observer, and you’ll also be able to figure out for yourself when to use them too. Awesome stuff, let’s get started.

What is an Observer anyway?

In a nutshell: An Observer in Magento listens for when specific events fire, and then executes code we have defined to listen to that observer.

What this allows us to do is create more speration of our code. Especially if it’s something we don’t really want coded directly into other modules or having to override core functionality which could make it very difficult for you to upgrade in the future.

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/

Alterntively if you’re using Sublime Text 2 or a similar IDE where you can search file contents across an entire project search for dispatchEvent and you’ll start to see the results pouring in.

This is fantastic, however it’s tricky to digest all this information. Luckily for you there is a fantastic little cheat sheet generated by Nick Jones over on his site. He maintains this and is generally up-to-date and is a fantastic reference. His cheatsheet will show you which file, line and what event is called.

Okay, now how do I create an observer?

By now you will have found the event you’re looking for. Now is the time to create our observer in order to execute our desired code! Let’s get started.

To do this we will be creating our own module. If you’re not familiar with creating your own module don’t worry, I’ll cover the basics but I won’t be going into too much detail.

Before we get started, my example below uses the sales_order_place_before event which is called just before the order is saved. We could do numerous things at this stage such as add additional meta data to the order. In my example, we’ll simply output to our log.

Step 1) Create main module xml file

We need to create a file called Meteorify_Observerexample.xml in app/etc/modules.

<?xml version="1.0"?>
<config>
    <modules>
        <Meteorify_Observerexample>
            <codePool>local</codePool>
            <active>true</active>
        </Meteorify_Observerexample>
    </modules>
</config>

This file allows Magento to recongise the modules existence and is where we can deactivate it (by changing true to false)

Step 2) Create folder structure for our module

We need to create the folders where our modules code will live. To do this create the following directories:

mkdir app/code/local/Meteorify/
mkdir app/code/local/Meteorify/Observerexample/
mkdir app/code/local/Meteorify/Observerexample/etc
mkdir app/code/local/Meteorify/Observerexample/Model

Quick explaination of the module folder structure. Meteorify represents the company or group, then Observerexample is our actual module. etc will contain various configuration files which instructs Magento how to read/use our module. Model contains our various Model classes which our module might use (in this case we will have a Observer.php file in the Model folder).

Step 2) Create our module’s configuration file

Each module requires a file called config.xml this file lives in app/code/local/Meteorify/Observerexample/etc

<?xml version="1.0"?>
<config>
    <modules>
        <Meteorify_Observerexample>
            <version>0.0.1</version>
        </Meteorify_Observerexample>
    </modules>
    <global>
        <models>
            <meteorifyobserverexample>
                <class>Observerexample_Model</class>
            </meteorifyobserverexample>
        </models>
        <events>
            <sales_order_place_before>
                <observers>
                    <meteorify_observerexample_model_observer>
                        <type>singleton</type>
                        <class>Meteorify_Observerexample_Model_Observer</class>
                        <method>logobs</method>
                    </meteorify_observerexample_model_observer>
                </observers>
            </sales_order_place_before> 
        </events>
    </global>
</config>

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.

Step 4) 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/Meteorify/Observerexample/Model and place the following code:

<?php
class Meteorify_Observerexample_Model_Observer {

    public function send_email($observer) {
        //$observer contains data passed from when the event was triggered.
        //You can use this data to manipulate the order data before it's saved.
        //Uncomment the line below to log what is contained here:
        //Mage::log($observer);

        Mage::log('We just made an Observer!');
    }

}

Easy as that.

Now all you need to do is clear the cache, make sure log’s are enabled in System > Configuration > Advanced > Developer > Logging and then go through the checkout and then check the logs in var/log.

I’ve put the completed module onto my github profile, so go ahead and check it out: Observer Example Magento

If you have any questions, or any tips and tricks please feel free to post a comment below!

Sometimes you will be required to change the default increment ID’s of orders, invoices, credit memos & shipments. To do this is surprisingly simple, yet cannot be done via the backend Admin area without an extension. Today I’ll show you how simple it is to change these numbers with some simple SQL queries to run on your database.

The table in question is eav_entity_store. Which has the last used increment id for each of the records we want to change. Knowing which is which is relatively easy to find out when you know where to look. In order to find out which is which you only need to take the entity_type_id and look at the records contained within eav_entity_type. From there you can spot which record corresponds  to the records within eav_entity_store.

To help you out, here are the records from a Magento 1.7.0.2 install I have. I can also verify that the same ID’s are in Magento 1.6.0.2 and 1.5.0.1 installs.

• 5 = Order
• 6 = Invoice
• 7 = Credit Memo
• 8 = Shipment

Creating our SQL queries

With this knowledge we can apply this to creating our simple SQL update query to update our order numbers!

Okay, so that’s all great. But have you noticed your order numbers still begin with the number one? That’s because there is a prefix added to your order numbers. To change this, simply change the increment_prefix column in the same table. So let’s update our SQL

So, what if we don’t currently have any records in the eav_entity_store table, like in a clean fresh install with no orders then the above commands won’t work because we can’t update records that don’t yet exist. That means we need to insert them. So simply replace the UPDATE directive with INSERT.

There you have it, it’s as easy as that! You can now easily update order numbers, invoice numbers etc with these simple SQL queries.

Let me know in the comments if this has helped you, or if you have any other tips like these that help you.