Of course this is straightforward to add in Magento using a custom option with the type set to ‘select’ however I also wanted to set a default custom option for the most commonly ordered option. As standard Magento provides a ‘Please Select’ option at the top of the select box which has the potential to confuse customers. There is no function in Magento to hide this ‘Please Select’ option so it is necessary to override the block which writes out the select box – and this is how you do it:

1. Tell Magento which block you are going to override/rewrite

To do this, you create a config.xml file for your module as shown below and save this to:

/app/code/local/MageTips/Catalog/etc/config.xml

This file tells Magento that we are rewriting the block which is executed when a custom option with the type of ‘select’ is configured – you could easily rewrite another type of custom option using a similar file.

2. Activate the custom module

Once you have create the config file for the module, Magento needs to know that it exists and this is done by creating an XML file as shown below and saving it to:

/app/etc/modules/MageTips_Catalog.xml

This file is read by Magento and activates our custom module.

3. Override the existing Magento block

With the module activated we now just need to provide the alternative version of the function that should be executed. In this case it’s as simple as copying the existing function and commenting out the line that writes out the ‘Please Select’ option value. We extend the existing Magento class at the top of the file (line 27) and then paste in the existing Magento function we are overriding – getValuesHtml() – and make the required change at lines 45-48.

This file is saved to:

/app/code/local/MageTips/Catalog/Block/Product/View/Options/Type/ Select.php

Throughout this example I have used the namespace MageTips for my module but you can use any namespace that makes sense for your project.

4. Setup your custom options

With the changes above in place, you can create custom options for any product and then set their order as normal in the Magento back office. Whichever option is at the top of the list will be the default custom option for that product.

Hopefully in a future version it will be possible to set a default custom option for a product – but in the meantime, this option will work just fine. As always, just remember with future upgrades to check whether the underlying Magento function we are overriding has changed!

I have found it difficult to get a good performance level out of a simple local installation on OS X 10.5.x – not helped by a multitude of issues getting PHP setup and running with the required modules for Magento.

However… I do have a remote Magento server running with a UK hosting company which is lightning fast with very little modification whatsoever. The key to it seems to be three-fold:

1. Server Specification

Magento is a pretty processor-intensive and memory-intensive application so having a server that can handle this is a good start. The specification for my development server is:

• Dell R200, Dual Core Xeon, 2.33GHz, 4MB Cache
• 2GB DDR2 RAM
• 2 x 160GB SATA Hard Drive 7200RPM
• Software RAID1

On the face of it this seems like a fairly meaty server but it’s relatively inexpensive – it costs under £100 per month from Melbourne Hosting in Manchester who I would highly recommend.

2. Server Configuration

I am by no means a Linux expert and don’t pretend to be but found that by following some pretty straightforward advice from Varien I was able to significantly improve the database element of the setup. There is already plenty of detail on this subject – this article is a good place to start – particularly the my.cnf modifications.

In addition, the recommendations in that article to install a PHP opcode cache and use a memory-based file system for /var/cache are recommendations you should seriously consider.

3. Website Configuration

Out of the box, the Magento front-end isn’t particularly quick – even with the Blank interface as a starting point (you are creating your own interface based on the Blank interface, right?). The main culprit here is Prototype & Scriptaculous – they are bulky frameworks and are included uncompressed. Magento funnels these files through a PHP conduit to compress them in to a single file but in my opinion that still isn’t ideal – you are just giving your server more work to do.

Web servers like Apache are brilliant at serving static files – so let them serve static files.

On most sites I build using Magento, I choose not to use the included javascript framework files but instead to roll my own. I have found the best way to do this is to create a packed version of the latest Prototype file and then a minified version of the Scriptaculous files and the various Magento specific javascript files. (For some reason when I packed the Scriptaculous and Magento/Varien-specific files I had some issues).

The result is my typical javascript usage is something like this:


<script type="text/javascript" language="javascript" src="/skin/frontend/[theme]/default/js/framework.pack.js"></script>
<script type="text/javascript" language="javascript" src="/skin/frontend/[theme]/default/js/application.min.js"></script>


Even though I have two javascript calls rather than one in the standard Magento configuration, the improvements in speed are huge – largely because Apache is doing what it does best – serving a packed, gzipped static file.

I will write up point 3 in more detail at some point when I have more time as it’s quite an involved process to determine which files you need and which you don’t and of course it varies depending on the site configuration, multi-language requirements etc. however the key points to take away for the amateur performance tweaker are:

• Don’t use an under-specced machine – it will be painful.
• Do follow Magento’s basic performance advice – it makes a big difference.
• Do maximise the efficiency of your front-end javascript and CSS

There is no silver bullet for perfect performance – but the advice above will certainly point you in the right direction.

One of the key benefits of developing ecommerce sites on the Magento platform is the flexibility of the system. Almost every area of the system can be tweaked and modified to meet exact client requirements. However it’s also worth noting that Magento is a young platform (only just over a year in production) and new versions of the software are released on a regular basis. With this in mind it’s important to try and make sites as upgradeable as possible in order to make life easier in the future. Quite often people see that a change is required and jump straight in to edit the core code – bad idea. Here I will show you how simple it is to extend an existing class to add new functionality to satisfy a specific requirement.

In the example below I will simply be extending the navigation class to create a slightly modified version of the drawItem class which Magento uses to draw out the main menu. This modified version will be free of the javascript calls and spans of the original to enable me to provide a cleaner HTML output.

There are 4 basic steps in the process:

1. Create a PHP file for the extended class in the /local code repository
2. Create an XML file to let Magento know about this extended class
3. Create a PHP template to utilise the output of the extended class
4. Modify the XML layout files to bring in this new template

1. Create a PHP file for the extended class in the /local code repository

In this case I have taken the existing Magento drawItem function and modified it to create a cleaner output and renamed it drawItemClean. This file should be saved to /app/code/local/Magetips/Catalog/Block/Navigation.php – note you should use whatever name you prefer for your modifications. I have placed all of my modifications in a namespace called Magetips for convenience.

2. Create an XML file to let Magento know about this extended class

Once you have extended the base class you need to let Magento know about this when it is loading the framework. To do this you create an XML configuration file which should be saved to /app/etc/modules/Magetips_Layout.xml – remember the name will depend on the namespace you have chosen for your code modifications.

This file basically tells Magento you have a local modification for Catalog Navigation and it will find and execute your Navigation.php file from step 1.

3. Create a PHP template to utilise the output of the extended class

Once the new function is available we can either modify the existing Magento template to output the results of the new function or add a new custom template for maximum flexibility. The location of the file will depend on the interface and theme in use – in our case the location is /design/frontend/blank/default/template/catalog/navigation/custom-home.phtml

This code will output our categories into a pre-prepared unordered list and nest subcategories within further child ul tags. You will still need to apply some CSS to match your site design however this code will provide the perfect clean base – I then customised this further with Son of Suckerfish CSS-only dropdown menus which is outside the scope of this initial article.

4. Modify the XML layout files to bring in this new template

Finally with all of the code in place we need to add a reference to the appropriate layout XML file to ensure it is shown in the front end of the website. In our case we want the new clean menu to be shown on all pages where a left hand menu exists and so we add the code below to /design/frontend/blank/default/layout/page.xml. Again, your file location will vary depending on where you wish to display your new menu but you should add it inside your existing block for the area of the page you wish to edit.

These four steps enable you to generate a modified menu function by extending an existing Magento class whilst avoiding modifying your core installation – therefore keeping your base installation easily upgradeable. The same concepts can be applied to extending any other area of Magento once you have found the correct base class to extend.

If you have any suggestions for changes/improvements to this method please feel free to add these in the comments.

This article was originally published at Netsprite in February 2009.

I’m currently building a new ecommerce stored based on the latest version of Magento. Whilst the navigation options available surpass most other products on the market there are still the occasional problems to deal with. I found that in some scenarios I wanted to display subcategories in the main body of a category page rather than them being restricted solely to the navigation bar.

This is particularly useful if you have a main level category with many subcategories and don’t wish to have a random selection of products or a more standard static block to be displayed if a customer lands on the main category.

The code is simple to implement though it’s not guaranteed to work with future versions of Magento – hence the MIT license designation. The website I’m working on is still under development so there is no example of this modification however the Gist below includes all of the code required to get up and running.