Frustrated by Magento? Then you’ll love Commerce Bug, the must have debugging extension for anyone using Magento. Whether you’re just starting out or you’re a seasoned pro, Commerce Bug will save you and your team hours everyday. Grab a copy and start working with Magento instead of against it.

Updated for Magento 2! No Frills Magento Layout is the only Magento
front end book you'll ever need. Get your copy
today!

Miscellaneous Commands

The dev:console command purports to offer an interactive shell for Magento PHP programming. However, the feature is labeled as experimental, and currently has some blocking issues. That’s enough to put it on the skip list for now.

The dev:ide:phpstorm:meta command is for users of the PHP Storm IDE, (no relation)

$ n98-magerun.phar dev:ide:phpstorm:meta
Generated definitions for blocks group
Generated definitions for helpers group
Generated definitions for models group
Generated definitions for resource models group
Generated definitions for resource helpers group
File .phpstorm.meta.php generated

Ah ha. The Varien_Db_Adapter_Pdo_Mysql class has two protected properties, $_debug and $_logAllQueries. These properties are used to toggle logging to the var/debug/pdo_mysql.log file. However, Magento doesn’t offer a straightforward “public” programming interface to toggle these values. So, the dev:log:db command modifies the core Varien_Db_Adapter_Pdo_Mysql library file to toggle these values to true.

You’ll need to make the decision on whether to use this command yourself. Personally, I wouldn’t use it outside of my development environment. The code that modifies this files is solid, but it’s regular expression based, and may blow up when it encounters an unexpected input file. This is less a comment on the skill of the Netz98 developers (which is legion), and more a comment on the seductive yet destructive powers of the regular expressions elder gods.

Next up is the dev:log:size command. This command can be used to monitor the size of your var/log/system.log, var/log/exception.log, and pdo_mysql.log files.

The dev:report:count command is a similar reporting command. This one will tell you how many “report” logs Magento has generated.

$ n98-magerun.phar dev:report:count

Magento “reports” are PHP exceptions that, for some reason or another, couldn’t be caught in the main application try/catch block that logs to exception.log. Instead, Magento will log these exceptions to var/reports/, one exception per file.

One possible use of the dev:report:count command would be in a cron to monitor this folder. Another would be as a generic diagnostic step to see what’s going on with an unfamiliar system.

Theme Commands

There’s two commands under the dev:theme category, dev:theme:list and dev:theme:duplicates. The dev:theme:list command will show you all the themes currently installed into your Magento system.

In the above example, n98-magerun is telling us the default/default theme has an identical customer.xml file to the base/default theme (if omitted, the second argument defaults to base/default). This command is mainly useful in cleaning up old “pre base design package” themes where the original default theme’s files were used as the starting point.

Module Commands

The last category of commands we’ll cover today are those under the dev:module hierarchy. These are commands to help you with Magento’s strict module system. That’s module as in Magento’s framework modules, and not Magento Connect extensions. Magento Connect extensions are collections of files, Magento modules are code files organized in a special way such that the framework addresses them as a unit.

Next, the dev:module:observer:list command will list any observers configured in the system. Observers are code added to the system that listen for specific Magento events. Observer based programming allows you to add functionality to Magento without the need to change any Magento code.

The dev:module:observer:list command requires that you specify which configuration “area” (global, adminhtml, or frontend) you’d like to search in

The report will list out the event name (adminhtml_controller_action_predispatch_start) as well as the model-name::method-name (adminhtml/observer::bindStore) of each observer.

The dev:module:rewrite:list command will list all configured Magento class rewrites in the system. For those new to the system, Magento has a class rewrite system which allows you to replace core Magento model classes with your own. This implements a primitive duck-typing/monkey-patching system, and can be used to modify system behavior where observers aren’t present.

Running this command will let you know right away if you can safely rewrite a class without impacting another extension in the system. When you’ve inherited a system or just installed a new module, the dev:module:rewrite:conflicts command will give you a quick heads up as to any conflicting rewrites in the system.

For those new to Magento, the rewrite system works by replacing which class is instantiated, via a factory method. This means one rewrite always “wins out” over another. The dev:module:rewrite:conflicts command will identify these conflicts for you.

The last command we’ll mention today is dev:module:create. This command can be used to create the files and directories needed for a skeleton module