As this is going live I am currently giving a talk at @WPNYC the WordPress New York Meetup group. There are two slides I skimmed over due to lack of time, but they are an essential part of the talk. In order to fulfill my promise to provide the complete story I am publishing this post with the full story. Warning, this blogpost is a bit of a braindump. It is intended as notes to use to explore further. If you need something clarified, don’t heistate to comment.
The first slide is titled:
Tools of the Trade
With the following content:
- Separate development environment
console.log()/error_log()/var_dump($var); die();debug_backtrace()/ Xdebug- Inspect Element / Developer Tools
- A good IDE
- Simulators
- Unit Testing
Let’s dig in…
Separate Development Environment
Never go commando, period. There are always exceptions to the rule – when you cannot reproduce a bug on your development server while it’s glaring at you from production – but you should avoid coding live on production at all costs. Sooner or later you’ll break something and your site will be down, and it was perfectly preventable. This is as important as not ever modifying core WordPress files. There are many ways you can implement a development server. Keep in mind that the closer your development environment is to production in how it functions, the fewer bugs you’ll have due to discrepancies in implementation of your code.
- XAMPP, MAMP and WAMP are all easy to use out of the box server solutions. I started out with them myself.
- Vagrant is a great way you can channel your inner sysadmin. But you don’t need to be one to use Vagrant. The good people at 10up support VVV. Or you can use the vagrant box one I built and use.
- Get another account on the server you are hosting your live site on. It’ll be worth the money, just make sure it’s not accesssible from the “outside.” Member’s only plugins can help with that. Or use the htaccess or nginx.conf files to limit access by ip address.
console.log() / error_log() / var_dump($var); die();
THE key to effective debugging is to know what you’re dealing with. These tools help you peek under the hood, test your assumptions, and understand what’s happening.
- Console is a VERY effective tool; its most used method is .log but it has a lot more. It’ll help you see what’s going on in your JavaScript code. We’ve come far from using alert().
- error_log is similar to console, but server-side. Find out where your error logs are written to on your host. A server isn’t worth it’s salt if it doesn’t provide that. If you enjoy console.log check out console_log().
- While the error_log is cleaner, it limits its output. I find I like to see things in the browser, sometimes. I use this pattern, a lot, when debugging.
echo '<pre>'; var_dump($var); die();It will “dump” the variable in a preformatted html tag, then die().
debug_backtrace() / Xdebug
Xdebug provides a whole suite of extended debugging methods. You don’t need to start here, but if you’re looking to up your game, here’s where to go.
Inspect Element / Developer Tools
Volumes of ink has been used talking about devtools, so I won’t go in depth here. 
Firebug changed our lives. Read up on it, use it. Personally, I enjoy designing in it too. It’s not just for debugging. I used devtoops to build this mockup to nag @Dropbox to request a feature.
A good IDE
I use PHPStorm. A lot of people swear by Sublime. One thing I like about PHPStorm is that it has deep integration with WordPress. The reason why this is essential is that it does a lot in the background to ensure good code.
- It can autoformat, which means you’ll reduce your syntactical bugs.
- Deep link to method sources, so you can more easily see what’s happening under the hood.
- Code completion will help you make sure you’re using the right method, and give you a reason to should “DAMN YOU AUTOCORRECT” every so often.
Simulators
If you’re expected to support a specific device, you better test in it. Unfortunatly we can’t all afford every device under the sun, but there are a lot of tools out there to help us with that.
- Modern.ie provides virtual machines for testing different versions of Internet Exploreer.
- Use a mobile emulator sometimes making your screen narrower won’t cut it.
Unit Testing
This is the single most important thing you can do to prevent bugs. It’s hard to get started. It’s overwhelming. But as the proverb says: the best time to plant a tree is 20 years ago, the second best time is now. Protip: Think about testing BEFORE you write your code… Look up TDD.
The second slide is titled:
WordPress Specific Debugging Tools
With the following content:
- define(‘WP_DEBUG’, true);
- Debug Bar plugin
- All the Debug bar addons!!!
- Style Guides
define(‘WP_DEBUG’, true);
There are a number of constants you can define in your wp-config.php file that can help your debugging in WordPress.
Debug Bar plugin
The Debug Bar is the equivalent to the devtools, but for WordPress. If you enable it you’ll get a window into how WordPress runs that you can’t get easily otherwise.
All the Debug Bar addons!!!
Expanding on the previous tool. There are a ton of plugins that hook into the Debug Bar and extend it.
Style Guides
This isn’t necessarily a WordPress specific tip, but if you’re using PHPStorm it comes with an auto formatting preset of WordPress’ code style. In any case, it doesn’t matter how you style your code (tabs vs. spaces) but only that you are consistent. If you are consistent with your coding style you’ll prevent a whole lot of bugs. You’ll prevent a whole lot more if you’re working with other people and you make sure you’re all styling your code the same way. Our brains evolved to see patterns, if your code styling isn’t consistent, you’ll miss details. You’ll have bugs.
Conclusion
I hope this was helpful. There’s a lot I didn’t cover so as to not overwhelm. What’s really most important, which I covered in my talk is the following: Make it work, then make it work well. If you do this, your code will always be improving.
Jack Reichert 