This post outlines some of our thoughts about the state of the Magento module community, and an idea for how Magento can improve the quality of that community.

Here at Classy Llama Studios we create our own Magento modules every day and have high standards for any module that we write.  These standards include having properly commented code, adhering to Zend programming standards, and having both the code and functionality of the module reviewed before it is released.  Magento is great because, instead of having to write every module that we use, there are numerous other quality development companies whose modules we can draw from for sites that we develop.  Unfortunately, there are a lot of modules out there that are not quality.  Issues with modules that we encounter include poorly written code, SQL vulnerabilities, improper code domain separation, and improper utilization of the Magento Application functionalities.  Some of these modules do not even work.

This abundance of modules often leaves us with a challenging question. Do we recommend this module to our client? If we do, we often have to prepare our clients for the possibility of hours of development, in addition to the module cost, that may be required to make the module safe and functional.  The other option is that we have to take a loss to bring the module to the level necessary for use on our customers’ eCommerce platform.  We love our customers and so it is painful for us to have to make either of these choices when the customer is already paying for the module. Because of this, we have been asking ourselves if there is some sort of solution to the problem of poorly coded modules.

The answer we came up with is twofold.  For now, we can buy most of our modules from the great companies who have earned our trust up to this point; these companies include AheadWorks, Unirgy, and WebShopApps. This alleviates the problem but it does not come close to eliminating it.  We know that there are other developers who write quality modules.  We simply don’t know who they are until we have worked with and reviewed their modules.  We think that Magento itself is the solution to this dilemma.

Even though Magento has had explosive growth since the release of Magento 1.0, it has only been three and a half years since its release.  Since then, Magento has gone through dramatic transitions and upgrades turning it into a much more streamlined and powerful system with numerous features and a massive community.  With eBay’s acquisition of Magento, its future looks even brighter.  Since Magento is so young, however, there are certain features and programs that they have not had or taken the time to develop.  We believe that the development of a Magento module certification would be a great step for the company and the community at large.  Magento has over 4800 modules in Magneto Connect, and we realize that reviewing every one of them would be a massive undertaking, so we think that it should be something that Magento would be best able to facilitate on a voluntary basis.  When Magento certifies a module, that module would receive special recognition and be more accessible to developers and store owners. This would take the burden of code review and repair off individual development companies or users purchasing the modules and put it back on the original developers of the module.  While this could take time to implement, we think that it is an endeavor from which the entire Magento community would benefit.

We’ve communicated this idea to Magento.  Here is a snippet of what we’ve told them: … There are many poor quality developers and modules, and the current system doesn’t provide a system of being able to determine which modules are good, and which are not.  The current Magento Connect is much like the Android Marketplace – thousands of apps, with only a portion of them being high quality.  While we would not like to see the same level of curation as the iOS Marketplace, we would like to see more attention being paid to ensuring that quality modules are promoted, and poor-quality modules are being demoted…

We sincerely hope that Magento does this, but regardless of what they do, we love the platform and will continue to support the company and the community to the best of our ability.  We believe that Magento truly is the eCommerce “Platform for Growth” and that it’s many features, programs, modules, developers, store owners, and fans make it a wonderful and enjoyable platform to work with every day.

The latest batch of Wiz updates includes some useful stuff for developers as well as some administrative features. Included in this bundle of Wizzy goodness is the ability to output any table output in csv, pipe, or tab delimited output. This makes it very easy to utilize Wiz with other commands (or potentially feed information from Wiz back into itself!)

Here is a complete list of the changes in 0.9.5:

1. The internal configuration system was rewritten to look more like Magento’s own configuration system — using XML files. This isn’t really used heavily yet, but we’ve got some stuff coming in the next few months that will take full advantage of this.
2. You can now toggle the following “developer” flags from the CLI:
   1. Allow Symlinks (For templates, 1.5.1.0+)
   2. Logging
   3. JS Merging
   4. CSS Merging
   5. Profiler
3. You can view all of the above configuration values as well with the devel-config command.
4. Get a list of all registered event listeners.
5. Get a list of all Models registered in the system and module rewrites.
6. Scriptable output. Output tabular data in csv, pipe-delimieted, or tab-delimited formats.

If you just want to get going:
Browse on Github
Website / Download

Be sure to read over the Readme file on Github for more information about the added commands!

The Good Stuff

Okay, so the configuration system isn’t a huge deal… but it does open up more potential for 3rd party developers to write plugins that need to store things: usernames, passwords, etc. without having to provide their own storage mechanism. Let’s get to the really exciting stuff!

Developer Configuration

$ wiz devel-config
+---------------------------------+-------+
| Path                            | Value |
+---------------------------------+-------+
| dev/debug/profiler              | No    |
| dev/js/merge_files              | No    |
| dev/css/merge_css_files         | No    |
| dev/log/active                  | No    |
| dev/debug/template_hints        | No    |
| dev/debug/template_hints_blocks | No    |
| dev/template/allow_symlink      | No    |
+---------------------------------+-------+

You can now flip off/on or view the status of each of these independently. Each of these work the same way devel-showhints works.

Developer Helpers

One of the things I’m curious about sometimes is to see what modules are listening to what events. Well, now with a new command, you can see that:

wiz devel-listeners give you a list of the events and the modules and their model/method that is responding to that event.

Often times, I want to know what overrides have been performed by other modules. Now I can see a total picture of what modules provide what models:

As you can see, all of the standard models are shown, but you can also see what overrides are performed by all of the modules on the system.

Scriptable Table Output

Finally, of the coolest thing (in my opinion) is the scriptable output. Wiz has a pretty decent table output system that makes it fairly easy for your eyes. However, getting that data out of the table took me far too much time. Enter --batch.

The –batch argument takes the model list we show above and transforms it into:

"Model Name","PHP Class"
varien/*,Varien_*
core/*,Mage_Core_Model_*
core_resource/*,Mage_Core_Model_Resource_*
eav/*,Mage_Eav_Model_*
eav_resource/*,Mage_Eav_Model_Resource_*
page/*,Mage_Page_Model_*
install/*,Mage_Install_Model_*
install_resource/*,Mage_Install_Model_Resource_*
admin/*,Mage_Admin_Model_*

The –batch argument can take one of three arguments: csv, pipe, or tab. csv is the default (as you can see above). Pipe replaces the commas with “|”s and tabs… well, you get the idea. Now you can take your Wiz output and pipe it through grep, cut, etc. or output straight to CSV and load it up into Excel/Numbers/OpenOffice/etc.

Enjoy!

Get Wiz

Browse on Github
Website / Download

As many of you know, Magento recently announced their Magento Developer Certification program.  As one of the few partners who have been involved with Magento since it’s inception, we’re especially excited to see this long-awaited program finally being launched.

Due to our depth of knowledge and experience with the Magento platform, Magento invited us to be a part of the Magento Certification Advisory Board. We’ve been involved in the process of writing questions for the certification for the past couple of months.  I want to extend congratulations to one of our Lead Developer’s, David Alger, for representing Classy Llama on the Advisory Board.  His contribution to the development of the certification has been substantial – he even won the award for completing the most number of objectives at a one-week onsite question-writing session.

The certification is going to be beta-launched at the Innovate conference at the middle of this month and will be announced to the public later this year.  We have four developers who will be at the event and taking the certification.

If you ever need custom layout handles in your local.xml, it’s fairly simple. In this example the observer method will make a new handle for for categories that have children or not, but you can just modify the method to make whatever handles you desire. (I realized after creating this there’s already a handle for anchored categories with no subcategories, catalog_category_layered_nochildren)

First add this to your config.xml in yourcustommodule:

<config>
<frontend>
        <events>
            <controller_action_layout_load_before>
                <observers>
                    <yourcustomtheme_observer>
                        <class>yourcustomtheme/observer</class>
                        <method>addHandles</method>
                    </yourcustomtheme_observer>
                </observers>
            </controller_action_layout_load_before>
        </events>
</frontend>
</config>

Then add this method to your observer:

 
class YourPackage_YourCustomTheme_Model_Observer extends CLS_Core_Model_Abstract
{
    public function addHandles($observer) {
        $category = Mage::registry('current_category');
        if ($category instanceof Mage_Catalog_Model_Category) {
            $update = Mage::getSingleton('core/layout')->getUpdate();
            $fertilility = (count($category->getChildrenCategories()->getData())) ? 'parent' : 'nochildren';
            $update->addHandle('catalog_category_' . $fertilility);
        }
        return $this;
    }
}

Do you have a site with product images of varying proportions. It can be annoying when Magento gives you that white border to make your product image square. Here’s how customize what color that background is: just add backgroundcolor('000', '000', '000') before the resize() method

<img src="<?php echo $this->helper('catalog/image')->init($this->getProduct(), 'thumbnail',
 $_image->getFile())->backgroundcolor('000', '000', '000')->resize(100); ?>" ... />

Better yet, get rid of the background using keepFrame(false):

<img src="<?php echo $this->helper('catalog/image')->init($this->getProduct(), 'thumbnail',
 $_image->getFile())->keepFrame(false)->resize(100); ?>" width="100"  ... />

Resizing after keepFrame(false) will resize the largest dimension. Don’t forget to delete your image height and width attributes (if need be)!

Here’s (most of) the places you’ll want to change these:

• catalog/product/view/media.phtml
• checkout/cart/item/default.phtml
• catalog/product/list.phtml

There may be a few more but I bet you can find them. Enjoy your no longer square (white background) images!

There is a lot of functionality in Magento that is hard to get to or tedious to work with.  There are so many tasks that developers, designers, and administrators do on a daily basis that require time-consuming trips to the Magento backend.  If you happen to want to do more than one of those operations, you end up having do each of those tasks one after the other… if only there was a better way!

It is my pleasure to announce Wiz: a command-line interface tool for working with Magento installations.  It was built to make your work (and subsequently your life) much easier!

Wiz has a whole bunch of great features, but here are some you’re sure to like:

• Create an admin user (tested in CE & PE)
• Toggle template hints
• Enable/disable module names
• Enable/disable module output
• Run xpath queries over the global config
• Enable/disable/clear caches
• … and more!

Wiz is a work in progress and hasn’t been thoroughly tested with every Magento version out there.  However, we’ve been using it with Professional and Community Edition installations without any major problems.

Things planned for future releases:

• Templates for building modules
• Better support for stores and configuration scopes
• More useful utilities like reindexing, cron runs, etc.

Your feedback and bug reports are welcome!

Update: Some screenshots for the curious…

List all modules, versions, and their statuses without going through the backend.

Create an admin user without having to touch the database.

Effortlessly clear, enable, & disable Magento caches.

Enable and disable template hints. Great for theme/skin development.

Dropping easily into MySQL shell for a Magento install.

I just finished giving a presentation at Magento Imagine conference.  I’m posting the link to the Powerpoint and the video I embedded in my presentation:

• Powerpoint presentation: http://bit.ly/fqwvlD
• Eclipse/PDT Debugging walkthrough video: http://bit.ly/fEQ0Ma

Cheers!

I wanted to do a check on a configurable product to see if it had a specific attribute. But not just any attribute, a global attribute used to create associated products within the configurable product – a “Super Product Attribute”.

So here ya go:

    $_product = $this->getProduct();
    $_attributes = $_product->getTypeInstance(true)->getConfigurableAttributes($_product);
    foreach($_attributes as $_attribute){
        var_dump($_attribute->debug());
    }

A little bonus:

The “->debug()” method returns the set of values you can use the get magic method on. For example:

array
  'product_super_attribute_id' => string '263' (length=3)
  'product_id' => string '27' (length=2)
  'attribute_id' => string '80' (length=2)
  'position' => string '0' (length=1)
  'product_attribute (Mage_Catalog_Model_Resource_Eav_Attribute)' => 
    array
      'attribute_id' => string '80' (length=2)
      'entity_type_id' => string '4' (length=1)
      'attribute_code' => string 'color' (length=5)
...

So var_dump($_attribute->getAttributeId()); will return string ‘80′ (length=2). Just use “get” with the Capitalized Label, getProductAttribute(), getProductId(), getPosition(), etc. Enjoy!

I just arrived back in the US after a long weekend at the Magento Developer’s Paradise. We (David Alger and myself) had a great time at the event (see photos of event below). There were a number of different types of attendees: Magento Professional & Enterprise development companies, extension development companies (like Webshopapps.com and Sweet Tooth), freelance developers, and Magento team members. We had opportunity to meet with a number of the european partners (Netresearch,Icommerce,Inchoo, et al) and other developers to share ideas on how to successfully build Magento projects.

#magedev was the official hash for all Twitter posts from the conference. View tweets with that hash here.

Yoav Kutner kicked off the conference with a keynote Sunday morning. Here are some bullet points from his speech:

• Magento is the faster growing ecommerce platform in the world.
  • “Magento” is searched for more often than “Ecommerce” on Google
  • Has been downloaded over 2.5 million times
  • Over 65K merchants are using Magento
    • This stat has been on the Magento website for a while, but I always wondered how this number was derived: I asked Yoav if Magento pinged any server to notify that it was installed at a certain address and he said that it did not, which is fantastic from a privacy perspective. The only way that Magento Inc. knew the urls of the 65K+ sites is that the admin panel in Magento is setup to check with the Magento servers to see if there are any updates/notifications that should be displayed to the admin user. The list of all urls that have requested updates from the updates RSS feed were culled down to a list of publicly accessible domains and then were tested to ensure that they were an actual Magento site.
  • It’s been estimated that over $25 billion has been transacted through the Magento platform.
  • 2.4 million extension downloads
  • 350+ active developers for Magento Connect
  • 180+ solution partners – 55% of these are in Europe
• Magento is being used on continually larger projects – some Magento sites are nearing the $1B/yr revenue mark.
• Magento Community 1.4.2.0 is planned for release in early November. This will be a maintenance release that will resolve 450 issues.
• Magento Community 1.5 Roadmap – CE 1.5 is currently slated to have the following features (subject to change):
  • Order composite products in admin
  • Edit order without creating a new one
  • Custom order statuses (this is currently possible by adding an xml node in a config.xml file of a custom module, but 1.5 will allow you to manage order statuses via the admin)
  • Multistep checkout with no Javascript
  • Improved import functionality (note: the uRapidflow extension currently enables these features, plus more)
    • Product types supported:
      • Simple
      • Virtual
      • Grouped
      • Configurable
      • Gift Card
    • All types of attributes will be supported
    • Support for different values per scope
    • Support for custom options
    • Support for tiered pricing
• Magento Enterprise 1.9.2 is planned for release in mid October (this will also just be a maintenance release) and 1.10 is planned for release at the end of the year. Magento 1.10 planned roadmap:
  • Gift wrapping
  • CDN/DB as alternative image storage
  • Support for MSSQL and Oracle databases
• There are over 700 Magento Enterprise users

Some notes from the other talks at the conference:

• Magento Connect – Jonathan Beri talked about upcoming features in Magento Connect 2.0. Some of the things that are planned for 2.0:
  • The option for Magento developers to sell modules directly within Magento Connect
  • The ability to sell a module as a subscription, instead of a one-time purchase
  • More advanced sorting/filtering options
• Magento Extensions for the Cloud/Saas – Jonathan Beri also talked a little bit about the OpenSocial extension infrastructure they are planning for the Saas solution they are building. Jonathan previously worked for Myspace where they use OpenSocial for their extension infrastructure.
• Performance - Dima Soroka gave a great presentation on Magento performance optimization. You can review the slides from his presentation here: http://j.mp/98mlR8
• Debugging with PDT+xdebug – I gave a quick presentation on the importance of using a robust IDE (PDT, Zend Studio, Netbeans) with debugging capabilities. You can read a blog post I wrote a while back on how to enable rich error and exception backtraces here: http://bit.ly/co1qc4. Yoav mentioned that some members of the Magento development team have recently started using PhpStorm (http://bit.ly/dbxhkq).

Thanks to Thomas, Annemarie, and others at Netresearch.de for the great job you did at hosting the event.  Here are some pictures from the event:

Props to David Alger for many of the above photos.

When you are developing for Magento, it is often helpful to see the contents of a Model. A model is a pretty complex object, so when you want to inspect the contents of the model, you generally don’t want to see all of it’s properties – all you’re really wanting to see is the contents of the _data property, which is the array that contains all of the attributes/fields that have been retrieved from the database.

Typically, when inspecting a model, I’ve used one of the following methods:

$model = Mage::getModel('catalog/product')->load(1);
 
# Method #1: This dumps all of the model's property's, including the _data property.
# This results in a lot of superfluous code that I don't need to see.
var_dump($model);
 
# Method #2: This only logs the data in the _data property.  The problem is, if the _data property contains
# any other models, all of the properties of those models will be dumped
var_dump($model->getData());

I recently came across the ->dump() method that is implemented in the Varien_Object class. This method recurses into the _data property of a model and returns an array of the values in the _data property, including the _data properties of the child classes. Here’s the example code:

# Method #3
var_dump($model->debug());

Note: The Varien_Object class is a class from which MANY classes in Magento extend. Most notably, all blocks and all data models extend Varien_Object. If you’ve never looked at the Varien_Object class, I’d recommend scanning/reading through the methods in that class. If you’re too lazy to read through the methods, but want to see what the debug() method does, I’ve included it at the bottom of this post.

Here are three screenshots exemplifying the difference between the different methods (note: the beautifully formatted var_dump output is a feature of the xdebug php extension):

Method 1:

Method 1 - var_dump

Method 2:

Method 2 - getData

Method 3:

Method 3 - debug

In case you’re curious to see how the debug() method works, here’s the code from the Varien_Object class:

    /**
     * Present object data as string in debug mode
     *
     * @param mixed $data
     * @param array $objects
     * @return string
     */
    public function debug($data=null, &$objects=array())
    {
        if (is_null($data)) {
            $hash = spl_object_hash($this);
            if (!empty($objects[$hash])) {
                return '*** RECURSION ***';
            }
            $objects[$hash] = true;
            $data = $this->getData();
        }
        $debug = array();
        foreach ($data as $key=>$value) {
            if (is_scalar($value)) {
                $debug[$key] = $value;
            } elseif (is_array($value)) {
                $debug[$key] = $this->debug($value, $objects);
            } elseif ($value instanceof Varien_Object) {
                $debug[$key.' ('.get_class($value).')'] = $value->debug(null, $objects);
            }
        }
        return $debug;
    }

I hope this quick tip helps you program with models more effectively! If you have any questions, feel free to post comments below.

Magento’s default error and exception handlers provide more information than the default php handlers, as they print out a basic backtrace (example) as opposed to just printing out the file and line number of the error but there are many times when Magento’s handlers just don’t cut it; times when you need to see the fully expanded variables that get passed to the functions/methods in the backtrace.

In the Initial Magento Setup Development Tips blog post, I wrote about how Xdebug overrides the default php error handler with a detailed, customizable error backtrace. I explained how to modify Magento’s core code so that php errors get handled by Xdebug, not Magento’s default error handler.

In this blog post, I’m going to explain how to modify Magento so that exceptions get handled by Xdebug, not Magento’s default exception handler.

The Mage::run() method is the method that gets the entire Magento request cycle started, so it makes sense that this is where the exceptions get handled:

    /**
     * Front end main entry point
     *
     * @param string $code
     * @param string $type
     * @param string|array $options
     */
    public static function run($code = '', $type = 'store', $options=array())
    {
        try {
            Varien_Profiler::start('mage');
            self::setRoot();
            self::$_app = new Mage_Core_Model_App();
            self::$_events = new Varien_Event_Collection();
            self::$_config = new Mage_Core_Model_Config();
            self::$_app->run(array(
                'scope_code' => $code,
                'scope_type' => $type,
                'options'    => $options,
            ));
            Varien_Profiler::stop('mage');
        } catch (Mage_Core_Model_Session_Exception $e) {
            header('Location: ' . self::getBaseUrl());
            die();
        } catch (Mage_Core_Model_Store_Exception $e) {
            require_once(self::getBaseDir() . DS . 'errors' . DS . '404.php');
            die();
        } catch (Exception $e) {
            if (self::isInstalled() || self::$_isDownloader) {
                self::printException($e);
                exit();
            }
            try {
                self::dispatchEvent('mage_run_exception', array('exception' => $e));
                if (!headers_sent()) {
                    header('Location:' . self::getUrl('install'));
                } else {
                    self::printException($e);
                }
            } catch (Exception $ne) {
                self::printException($ne, $e->getMessage());
            }
        }
    }

The problem with the above code is that any exceptions that get thrown by any Magento code get handled by the Mage::printException() method. What we need to do is run the essential code without wrapping it in any try/catch blocks if the developer mode is enabled from the index.php. This will result in all exceptions being handled by the Xdebug exception handler. Here is the resulting code:

    /**
     * Front end main entry point
     *
     * @param string $code
     * @param string $type
     * @param string|array $options
     */
    public static function run($code = '', $type = 'store', $options=array())
    {
        if(!self::getIsDeveloperMode()){
            try {
                Varien_Profiler::start('mage');
                self::setRoot();
                self::$_app = new Mage_Core_Model_App();
                self::$_events = new Varien_Event_Collection();
                self::$_config = new Mage_Core_Model_Config();
                self::$_app->run(array(
                    'scope_code' => $code,
                    'scope_type' => $type,
                    'options'    => $options,
                ));
                Varien_Profiler::stop('mage');
            } catch (Mage_Core_Model_Session_Exception $e) {
                header('Location: ' . self::getBaseUrl());
                die();
            } catch (Mage_Core_Model_Store_Exception $e) {
                require_once(self::getBaseDir() . DS . 'errors' . DS . '404.php');
                die();
            } catch (Exception $e) {
                if (self::isInstalled() || self::$_isDownloader) {
                    self::printException($e);
                    exit();
                }
                try {
                    self::dispatchEvent('mage_run_exception', array('exception' => $e));
                    if (!headers_sent()) {
                        header('Location:' . self::getUrl('install'));
                    } else {
                        self::printException($e);
                    }
                } catch (Exception $ne) {
                    self::printException($ne, $e->getMessage());
                }
            }
        } else { // If we're running in developer mode, we want all exceptions to be handled by the php|xdebug error handler
            Varien_Profiler::start('mage');
            self::setRoot();
            self::$_app = new Mage_Core_Model_App();
            self::$_events = new Varien_Event_Collection();
            self::$_config = new Mage_Core_Model_Config();
            self::$_app->run(array(
                'scope_code' => $code,
                'scope_type' => $type,
                'options'    => $options,
            ));
            Varien_Profiler::stop('mage');
        }
    }

This code allows Xdebug’s exception handler to do its magic, resulting in fully detailed exception backtraces like this:

Hopefully this little trick allows you to code Magento more effectively!

We recently had a client who needed to be able to manage inventory for configurable products in Magento. Since configurable products are intended to merely group simple products together, the ability to track inventory for configurable products is not something that is possible in a vanilla Magento install.

I dug into the Magento codebase to better understand how inventory is managed for the different product types in Magento. As you could probably guess, the CatalogInventory module handles all of Magento’s inventory management. In side of the /app/code/core/Mage/CatalogInventory/etc/config.xml file, you’ll find the following section of xml contained in the global tag:

<catalog>
<product>
        <type>
            <simple>
                <is_qty>1</is_qty>
            </simple>
            <virtual>
                <is_qty>1</is_qty>
            </virtual>
            <configurable>
                <stock_indexer>cataloginventory/indexer_stock_configurable</stock_indexer>
            </configurable>
            <grouped>
                <stock_indexer>cataloginventory/indexer_stock_grouped</stock_indexer>
            </grouped>
        </type>
    </product>
</catalog>

This section of xml is used by Mage_CatalogInventory_Helper_Data::getIsQtyTypeIds method to determine if a certain product type “qualifies” for inventory tracking. It is also used to indicate if there is a custom resource model that needs to be used to calculate the stock availability for a certain product type.

The beautiful thing about the way Magento handles the configuration xml is that we can create xml nodes that mirror the structure of the above xml in a config.xml file in a custom module – this allows us to change pretty much any configuration value without having to touch any of the config.xml files of core Magento modules. Magento will then merge the xml nodes from both config.xml files. Since custom modules are loaded after core modules, any nodes that override default Magento nodes will take precedence.

I created a small module that enables inventory tracking for configurable products. The following sections in Magento are overridden by this module:

• app/code/core/Mage/CatalogInventory/Model/Observer.php (lines 365 – 405)
• app/code/core/Mage/CatalogInventory/etc/config.xml (line 202)
• app/design/adminhtml/default/default/template/catalog/product/tab/inventory.phtml (line 55)

You can download this module here. All you need to do to install the module is to copy the app folder into your Magento install folder. Note:

• There are two different ways of tracking inventory for configurable products. Read the comments in the app/code/local/CLS/ConfigurableInventory/etc/config.xml file for details.
• This module is built for Magento 1.4.0.1. It’ll likely work on older versions of Magento, but I’ve only tested it on 1.4.0.1

UPDATE (5/12/10): After working with this test module on a dev site, it looks like the $item->getProduct() method call on line 21 in the CLS_ConfigurableInventory_Model_CatalogInventory_Observer class actually isn’t returning a product model for all order items. This is something that I’ll be debugging once we actually implement this test code in a project. I’ll try to post an update here when we do that.

I’d love to hear from any of you that end up implementing this code on your site.

If you have ever written Javascript for Magento, you have probably been frustrated by the fact that Magento merges all of its JS files before outputting them to the frontend. This makes debugging difficult for a few of reasons:

• It makes it more difficult to see if your JS file is even being loaded
• When Firebug (or your JS debugger of choice) logs errors to the console, it’s impossible to match up the line numbers Firebug reports with the line numbers in the file
• If you want to use Firebug’s debugging or profiling tools, you’re greatly impaired by having all the JS in one file.

A few months ago, one of our developers stumbled across the ability to disable the JS merging in Magento: Go to System > Preferences > Developer > Javascript Settings tab > Set “Merge JavaScript Files” to “No”.

I hope this helps in your Magento Javascript debugging!

There are many times when working with the Magento frontend that I get very ambiguous error message. Here is a screenshot of the type of error I’m talking about:

I usually just search the entire codebase for the error message code, locate the place where the exception is getting caught, and then temporarily modify the code to Mage::log() the following data: $e->getMessage(), $e->getTraceAsString(), etc…

I just came across an exception handler in the Mage_Checkout_MultishippingController class that passed the generic exception message as well as the Exception class itself to Mage::getSingleton(’checkout/session’)->addException(). Here’s the code (from line 219 of the containing file):

        catch (Exception $e) {
            Mage::getSingleton('checkout/session')->addException(
                $e,
                Mage::helper('checkout')->__('Data saving problem')
            );
            $this->_redirect('*/*/addresses');
        }

I dug into the Mage::getSingleton(’checkout/session’)->addException() class and realized that it logged the exception code to the var/logs/exception.log file (it only logs the exception if logging is enabled in System > Preferences > Developer). This means that instead of locating and hacking up core files to see exceptions that are thrown, in a lot of cases, you can just monitor the contents of the exception.log file.

If you’re developing on a Mac machine, you can monitor the contents of the exception.log file using the Console app. If you’re on a Linux box, you can use “tail -f var/log/exception.log” to monitor the contents of this file.

Hopefully this helps you in your debugging efforts!

To follow up on our post about editing Magento’s top links, I thought I might as well write an article about editing the footer links while I’m at it.  I’d recommend reading our post about using a local.xml file before getting started on this post.  This post might not make much sense until you read it. [NOTE: This specific example assumes you are using the blank theme. Layout handles may differ from theme to theme.]

In local.xml:

<?xml version="1.0"?>
<layout version="0.1.0">
    <default>
        <reference name="footer_links">
            <!-- Add custom links. Pretty self-explanatory.
            Dig into app/code/core/Mage/Page/Block/Template/Links.php for more info -->
            <action method="addLink" translate="label title">
                <label>About Us</label>
                <url>about</url>  <!-- can use a full url if not using urlParams below -->
                <title>About Us</title>
                <prepare>true</prepare> <!-- set true if adding base url param -->
                <urlParams helper="core/url/getHomeUrl"/> <!-- base url - thanks @Russ! -->
                <!-- there are a few param you can send to do different things in <urlParams> 
                         dig into app/code/core/Mage/Core/Model/Url.php, around line 803 -->                   
 
                <!-- below adds #add-fragment to the end of your url -->
                <!-- <urlParams><_fragment>add-fragment</_fragment></urlParams> -->
 
                <!-- below adds ?add-query to the end of your url -->
                <!-- <urlParams><_query>add-fragment</_query></urlParams> -->
 
                <!-- below gives you a new session id (i think...)-->
                <!-- <urlParams><_nosid>true</_nosid></urlParams> -->
 
                <!-- below replaces double quotes, single quotes, greater than, and less than signs 
                         to their respective url escaped replacements (%22, %27, %3E, %3C) -->
                <!-- <urlParams><_escape>i'm-a-blog-url</_escape></urlParams> -->
 
                <position>1</position>
                <liParams/>
                <aParams>class="top-link-about-us"</aParams>
                <beforeText></beforeText>
                <afterText></afterText>
            </action>
 
            <!-- Remove 'Site Map' Link - Default Position: 10
            Original link adding in catalog.xml -->
            <action method="removeLinkByUrl"><url helper="catalog/map/getCategoryUrl" /></action>
 
            <!-- Remove 'Search Terms' Link - Default Position: 20
            Original link adding in catalogsearch.xml-->
            <action method="removeLinkByUrl"><url helper="catalogsearch/getSearchTermUrl" /></action>
 
            <!-- Remove 'Advanced Search' - Default Position: 30
            Original link adding in catalogsearch.xml-->
            <action method="removeLinkByUrl"><url helper="catalogsearch/getAdvancedSearchUrl" /></action>
 
            <!-- Remove 'Contact Us' link - Original link in contacts.xml
            <!-- Best bet to go to Magento's Admin > System > Configuration > (left sidebar) Contacts
            > Contact Us Enabled = NO -->
            <!-- You can pass the full url, which is a hassle if you have dev and stage sites -->
            <action method="removeLinkByUrl"><url>http://YOUR_SITE.com/contacts/</url></action>
            <!-- see comments below for making a custom helper to remove contacts link
            no matter what your base url is  -->
	</reference>
 
        <!-- By default, Magento sets a static footer block. Find it in the admin under
        CMS > Static Blocks.
	<reference name="footer">
            <!-- Remove Magento's default static block and use the 'addLink' method above
            to add your custom and inline links.  I use the 'unsetChild' method as often as
            possible as opposed using the more final <remove name="cms_footer_links"/>
            just in case I want to add the block somewhere else -->
            <action method="unsetChild"><name>cms_footer_links</name></action>
 
            <!-- Remove all the other Magento links - "Site Map, Search Terms, Advanced Search, and
            Contact Us" -->
            <action method="unsetChild"><name>footer_links</name></action> <!-- Magento 1.4.x -->
	</reference>
</default>
</layout>

If all else fails, you can edit template/page/template/links.phtml. However, if you can make all your changes in local.xml, your life will be so much easier when it comes to upgrading Magento and making future edits.

You might need to read the post about using a local.xml file before this post makes much sense.

We offer all our clients a completely customized design from scratch, which means changing anything – including those annoying defaulted top links.  This post will show you how to edit your top links (without editing core layout files which may change when you update Magento) by utilizing a local.xml file. You can even add your own custom links without touching any template files! [NOTE: This specific example assumes you are using the blank theme. Layout handles may differ from theme to theme.]

ADDITION: Check out the blog post about editing Magento’s footer links

In local.xml:

<?xml version="1.0"?>
<layout version="0.1.0">
    <default>
        <reference name="root">
            <reference name="top.links">
                <!-- Add custom links. Pretty self-explanatory.
                Dig into app/code/core/Mage/Page/Block/Template/Links.php for more info -->
                <action method="addLink" translate="label title">
                    <label>About Us</label>
                    <url>about</url>  <!-- can use full url also -->
                    <title>About Us</title>
                    <prepare>true</prepare> <!-- set true if adding base url param -->
                    <urlParams helper="core/url/getHomeUrl"/> <!-- base url - thanks @Russ! -->
                    <!-- there are a few param you can send to do different things in <urlParams> 
                             dig into app/code/core/Mage/Core/Model/Url.php, around line 803 -->                   
 
                    <!-- below adds #add-fragment to the end of your url -->
                    <!-- <urlParams><_fragment>add-fragment</_fragment></urlParams> -->
 
                    <!-- below adds ?add-query to the end of your url -->
                    <!-- <urlParams><_query>add-fragment</_query></urlParams> -->
 
                    <!-- below gives you a new session id (i think...)-->
                    <!-- <urlParams><_nosid>true</_nosid></urlParams> -->
 
                    <!-- below replaces double quotes, single quotes, greater than, and less than signs 
                             to their respective url escaped replacements (%22, %27, %3E, %3C) -->
                    <!-- <urlParams><_escape>i'm-a-blog-url</_escape></urlParams> -->
 
                    <position>1</position>
                    <liParams/>
                    <aParams>class="top-link-about-us"</aParams>
                    <beforeText></beforeText>
                    <afterText></afterText>
                </action>
 
                <!-- Removes 'My Account' link - Default position: 10 -->
                <action method="removeLinkByUrl"><url helper="customer/getAccountUrl"/></action>
 
                <!-- Removes 'Wishlist' link - Default position: 20 -->
                <!-- for Magento 1.3.x -->
                <action method="removeLinkByUrl"><url helper="wishlist/"/></action>
 
                <!-- for Magento 1.4.x -->
                <remove name="wishlist_link"/>
 
                <!-- Removes 'My Cart' AND 'Checkout' links
                Default position: 40 and 50 respectively -->
                <remove name="checkout_cart_link"/>
 
                <!-- To re-add 'My Cart' or 'Checkout' after removing both -->
                <block type="checkout/links" name="checkout_cart_link_custom">
                    <action method="addCartLink"></action>
                    <action method="addCheckoutLink"></action>
                </block>
            </reference>
        </reference>
    </default>
 
    <customer_logged_out>
        <!-- Removes 'Log In' link - Default position: 60 -->
        <reference name="top.links">
            <action method="removeLinkByUrl"><url helper="customer/getLoginUrl"/></action>
        </reference>
    </customer_logged_out>
 
    <customer_logged_in>
        <!-- Removes 'Log Out' link - Default position: 60 -->
        <reference name="top.links">
            <action method="removeLinkByUrl"><url helper="customer/getLogoutUrl"/></action>
        </reference>
    </customer_logged_in>
 
</layout>

If you absolutely cannot find a way to customize your top links using these methods, you can edit the /template/page/template/links.phtml

In this article, I’m going to be covering what I believe to be a very effective way of modifying the layout of any Magento theme.

For several of the first Magento themes I built, I copied the layout files from the default or blank theme into the custom theme layout folder. I would then modify the layout files directly, editing or commenting out content in files like: catalog.xml, page.xml, checkout.xml, etc… I never liked editing these files directly, as I knew that when it came time to upgrade to a newer version of Magento that had upgraded the layout files, I’d have to merge the changes into the new layout files.

One day, I was digging through the Magento code relating to layout files and discovered a bit of code that made me realize that it was possible to just place a local.xml file in my custom theme’s layout folder and have it loaded automatically by Magento. (this code is on line 283 in /app/code/core/Mage/Core/Model/Layout/Update.php in the fetchFileLayoutUpdates() method).

Due to Magento’s brilliant tags, it’s possible to do just about anything you want without having to edit any of the default layout files.

Before delving into the code, let’s look at the advantages/disadvantages of this method:

Advantages

• Allows you to upgrade themes without having to merge in changes
• All custom layout changes are centralized, allowing developers to more easily make changes to custom theme elements

Disadvantages

• At first, it’s slower to use this method than hacking up the standard layout files directly
• You will have one more place to look where the site might be pulling code (template phtmls, standard layout files, admin layout updates, AND local.xml)

Here is the slimmed down, commented local.xml from one of our recent projects:

<?xml version="1.0"?>
<layout version="0.1.0">
 
<default>
 
	<reference name="head">
		<!-- Magento looks in /skin/frontend/<INTERFACE>/<THEME>/js/buyprinting.js
		for this file -->
		<action method="addItem"><type>skin_js</type><name>js/buyprinting.js</name></action>
 
		<!-- This removes the item that was set in the page.xml file -->
		<action method="removeItem"><type>skin_js</type><name>js/iehover-fix.js</name></action>
 
		<!-- Magento looks in /js/prototype/element.storage.js for this file -->
		<action method="addJs"><name>prototype/element.storage.js</name></action>
 
		<action method="addCss">
<stylesheet>css/buyprinting.css</stylesheet></action>
	</reference>
 
	<reference name="header">
        <!-- This adds a CMS block that can be called from the template file
        associated with the header block. -->
		<block type="cms/block" name="cms_quick_help">
			<action method="setBlockId"><block_id>quick_help</block_id></action>
		</block>
 
        <!-- The remove tag removes the blocks with the specified name from the layout -->
		<remove name="top.menu"/>
		<remove name="store_language"/>
		<remove name="breadcrumbs"/>
	</reference>
 
	<reference name="top.nav">
		<remove name="catalog.topnav"/>
	</reference>
 
	<reference name="left">
		<remove name="left.newsletter"/>
		<remove name="left.permanent.callout"/>
		<remove name="catalogsearch.leftnav"/>
 
        <!-- When you use the remove tag, it removes any blocks with the specified name from
            the entire layout, regardless of the context. So, if I remove right.newsletter in
            the <default> context and that name is used in say the <catalog_product_view> context,
            then both blocks will be removed.  Because remove operates on the global context,
            you can only remove an element once.  Since <remove name="right.newsletter" /> is
            being called in catalogsearch.xml, we have to unset it, or else we'll get an error.
 
            The line below only unsets the block from the parent's context, not the global
            layout context -->
		<action method="unsetChild"><name>right.newsletter</name></action>
	</reference>
 
	<reference name="right">
        <!-- Some blocks have to be removed using remove, others via unsetChild.
            I've not spent the time digging into the code to figure out why -->
		<remove name="right.permanent.callout"/>
		<remove name="catalog.compare.sidebar"/>
		<remove name="left.reports.product.viewed"/>
		<action method="unsetChild"><name>sale.reorder.sidebar</name></action>
		<action method="unsetChild"><name>wishlist_sidebar</name></action>
		<action method="unsetChild"><name>right.reports.product.viewed</name></action>
		<remove name="cart_sidebar"/>
	</reference>
 
</default>
 
<!-- CATALOG PAGES -->
	<catalog_product_view><!-- 2columns-right -->
		<reference name="root">
			<action method="setTemplate"><template>page/2columns-left.phtml</template></action>
		</reference>
		<reference name="content">
			<reference name="product.info">
				<block type="cms/block" name="cms_product_info_tabs">
					<action method="setBlockId"><block_id>product_info_tabs</block_id></action>
				</block>
				<block type="catalog/product_view" name="product.clone_prices" as="prices" template="catalog/product/view/price_clone.phtml"/>
				<action method="unsetChild"><name>tierprices</name></action>
				<action method="unsetChild"><name>addto</name></action>
				<remove name="addto"/>
				<reference name="product.info.options.wrapper.bottom">
					<action method="unsetChild"><name>product.tierprices</name></action>
				</reference>
			</reference>
		</reference>
	</catalog_product_view>
 
</layout>

I hope with article has given you some direction as to how you can improve you Magento theming skills. If you have any additional tips/comments on coding layouts, please suggest them in the comments section.

One fairly unknown feature of Magento collections is that you actually don’t have to call ->load() on a collection before being able to access the items in the collection. So you can do this:

$orders = Mage::getResourceModel('sales/order_collection')->addAttributeToSelect('*');
# The load method is not necessary, as iterating through a collection automatically loads it, if it hasn't already been loaded.
# $orders->load();
foreach($orders as $order){
    echo 'Order Id: ' . $order->getId() . "\n";
}

The base Varien_Data_Collection class implements the IteratorAggregate (http://php.net/manual/en/class.iteratoraggregate.php) interface which extends the Traversable (http://www.php.net/manual/en/class.traversable.php) interface. When a class extends the Traversable interface, it guarantees that that class can be iterated through using foreach(). When foreach is called on a collection, it calls the getIterator() method in the Varien_Data_Collection class and uses the value returned from that method as the value that the foreach iterates through. This is the getIterator() method:

    public function getIterator()
    {
        $this->load();
        return new ArrayIterator($this->_items);
    }

This auto-loading functionality works for both EAV and flat-table collections.

As you can see, a collection ensures that it is loaded before running through a foreach loop. Note: collections can only be loaded once per instantiation. If you want to reload a collection, you have to call the clear() method, and then reset the select and filters before calling the load() method again.

Knowing that collections function in this way allows you to write code without explicit calls to load(). This ultimately should result in more flexible code. You can have a method in a block that loads a collection. That collection can then either be called by a template file and iterated through, or you can have another method that loads the collection from the first method, and then adds additional selects/filters to it. This practice of not explicitly calling the load() results in more flexible and reusable code.

In Magento, it’s very easy to save all the data in a model by running $model->save();. (Note: In this blog post, model refers to an EAV model, not a flat resource model) This saves all the attributes for the model to their respective attribute tables. There are times when saving the value of just one of the model attributes is desirable. A couple cases where you’d want to do this:

• You’ve been passed a model from an event, and you aren’t sure if the data in that model can be safely saved.
• You are saving many models and want to make your save operations as efficient as possible

Here is how you’d save just one attribute of a product model:

$product = Mage::getModel('catalog/product')->load(1);
$product->setName('Some Random Name');
$product->getResource()->saveAttribute($product, 'name');

Note: this script works on Magento CE 1.3.2.4 and 1.4.0.* but does not work in the Magento Enterprise Edition

As a Magento development company, we have a number of designers, developers, and project managers that need admin access to the sites that we build. As opposed to using one global admin account for our entire team, we believe it to be a much better practice to assign individual admin accounts to each team member who is going to be working on a project.

One of our developers, Matt Johnson, has developed a script to allow us to easily add an admin user to a Magento installation. Each member on our team that needs Magento admin access has a sql file that adds their admin account to Magento. When we start a new project, we run the sql script for the members of our team that are going to need access to the server. I hope you’ll find this snippet useful.

/* This is an example SQL script.
You should replace all the UPPERCASED variables.
The <USERNAME> variable can only be alphanumeric characters, and probably underscores (haven't tested)
 
You can either generate a password hash using the PHP code below,
or you can grab a password hash from the admin_user table from an
existing Magento install for which you know the admin password.
*/
 
/* Use the following PHP script to generate a salted password hash. You can also use a straight md5 hash, but it's much more easily brute-forced
<?php $password = 'PASSWORD'; $salt = 'GF'; echo $hash = md5($salt.$password).':'.$salt; ?>
*/
 
insert into admin_user
select
(select max(user_id) + 1 from admin_user) user_id,
'FIRST NAME' first_name,
'LAST NAME' last_name,
'EMAIL' email,
'USERNAME' username,
'HASH EXAMPLE: 178f29c8e4c6c801db90cd171e3b2b53:in' password, /* You can replace this value with an md5 hash */
now() created,
NULL modified,
NULL logdate,
0 lognum,
0 reload_acl_flag,
1 is_active,
(select max(extra) from admin_user where extra is not null) extra;
 
insert into admin_role
select
(select max(role_id) + 1 from admin_role) role_id,
(select role_id from admin_role where role_name = 'Administrators') parent_id,
2 tree_level,
0 sort_order,
'U' role_type,
(select user_id from admin_user where username = 'USERNAME') user_id,
'USERNAME' role_name