Mini Tutorial: Problem Solving in Magento

We’ve all been there, even if you’re just starting with Magento. I remember a frustrating afternoon just trying to get Magento set up on a local environment. Needless to say, I’ve gotten better at being able to diagnose problems with code / an installation – mainly due to problem solving techniques taught to me by my coworkers! So, here is a big thank you to them. Thanks!

When problem solving in Magento, there’s a multitude of techniques that you can use to push past the issue and frustration:

1. Is the site you’re working on actually the site you’re working on?

I can’t stress how important this is. As we usually work in a local or staging development environment, we have many Magento installations at our fingertips – all looking pretty much exactly the same. Sometimes I’ll be moving between three different versions of a site! (Production, staging, and local.) So – if you use the same URL for your local install as your staging, make sure your host’s file is updated to point to the proper site. If you’re really not sure, download Firefox and subsequently the Firebug extension. Use the ‘Net’ tab to see the IP address that content is being pulled from. Also, if you don’t have Firebug or at least some frontend development tools, it makes life a ton easier.

2. What’s up with the cache and indexes?

There are many common issues that can be resolved with simply flushing the cache or reindexing the entire site. The most common is that you make a change to a template file and it doesn’t show up. Make sure you flush at least the block cache to view the change. If this gets irritating, try disabling all of the caches. But be warned! Is anyone else using / developing the site with you? They may need the cache for what they’re working on. Another common issue is you make a change on a product or attribute on the backend and it doesn’t show. You may need to reindex the appropriate indexes – or if you’re not sure, just reindex the entire site. Flushing the cache can be found at Configuration > Cache Management and indexes can be run at Configuration > Index Management.

3. What’s in the ol’ logs?

This is one that I’m definitely guilty of… I always forget to check my system.log and exception.log. If you try to make a change repeatably and it’s not showing, perhaps there’s evidence why a template’s not displaying, syntax is off, output is not correct, or it may even lead to showing you that your logic is incorrect. I’m always surprised about how much these logs help. Also, now that you have Firebug, something may not be working on the page due to a Javascript error. The Firebug console (or just the console on Google Chrome) can often reveal issues in your JS.

4. If your change was a change on the backend, does it apply to the necessary store views?

Many times I’ll be working on a site that has multiple store views, or less often multiple websites – you need to make sure that the change is applied to these as well. It’s so easy to change the default and think it should work, but if an option is store-view specific, you may have to be more explicit.

5. Mage::log() can be your best friend.

One of my favourite built-in functions to Magento is the log() function as it can be easily placed anywhere to log whatever you like. You can even define your own file names so you can have logs pertaining to what you’re currently trying to debug. To do this, write:

Mage::log($var_to_log, null, ‘My_great_log.log’)

If Magento doesn’t log anything, make sure logs are turned on. To do this, log into the adminstrative backend, go to Configuration > Developer > Log Settings and turn it on. If it still isn’t logging, make sure the /var folder is writeable by the server.

6. Use an IDE with a debugger.

Do you use an IDE? If not, there are a couple free ones out there that are great. I recommend Netbeans first, as it is the development environment used in the Magento U videos, however I’m sure Eclipse will work well as well. Netbeans has a great tutorial on their wiki about installing XDebug for yourself. After it is installed, you may set “breakpoints” where you would like in your code. As PHP code executes, your IDE will “listen” for these breakpoints and stop at these points, letting you inspect all of the current variables and instantiated classes. I won’t go into debugging in full detail in this post, but there are several resources out there pertaining to setting up your own debugging environment. I usually just use debugging on my local environment.

7. Walk away and talk it out.

If you’re really, really stumped, don’t worry about it. We’ve all been there. It happens. I like to take a walk around the office, maybe grumble a bit, and talk it out to a coworker or write down the details of what I’m doing. It’s very strange how this can help, but as soon as you begin talking your brain seems to make new connections it didn’t have before. It’s very easy to get tunnel vision when dealing with a seemingly impossible problem. You can do it!

I hope some of these techniques help you out. If you have any others, please post them in the comments below!