The primary way to check your code is to go through a debugging process. Here’s the thing about debugging: there’s no single process that is going to work for every project. You really have to take some time to think through how your code is working and develop a plan to make sure you cover your bases.
That being said, there are some general practices you can put into place, because God knows, if your client sees a funky div overlap, they’re going to let you know fast. So taking some time to debug your themes on your own can save you a lot of heartache.
Knowex the Codex
THE most important part of debugging your theme is having quick access to various parts of the WordPress codex. I have about 10 pages that I reach for on a regular basis because I tend to switch between development projects and need a quick reminder.
HERE’S THE CODEX LINK
In my earlier days of development, I spent a lot of time re-inventing the wheel. WordPress has so many features and functions already built in to handle just about any situation. The more you integrate WP functionality into your code, the less debugging you’ll have to do later. The more you know your WP codex, the more you’re going to be able to tap into the pre-built WP functionality. See what I did there?
Use WP_DEBUG
Once I have my code working at about 90%, I go to my wp-config.php file and turn on the WP_DEBUG. It’s as simple as setting the value to true (default is false).
This will get you a whole host of error messages. Initially this can be frustrating because you know your code is functioning, but you still get these weird messages. In many cases, the messages are about data validation in PHP. Fix these! You’re FAR more likely to create bug-free code when you no longer get error messages in WP_DEBUG mode.
Advanced WP_DEBUG
Even after my code goes into production, I like to log error messages for awhile. The fact is, users are far more likely to generate bugs than I am as the developer. So letting the end user work with the site for awhile is a great way to find problems and work through them.
First of all, keep your WP_DEBUG set to true. Then, set WP_DEBUG_DISLPAY to false. WP_DEBUG_LOG should be set to true, which will dump an error log into your /wp-content folder. Optionally, you can set SAVEQUERIES to true so you can see queries that may be getting errors or unexpected data.
So here’s how you should stage this in your wp-config.php file:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('SAVEQUERIES', true);
There is also a SCRIPT_DEBUG mode that allows you to define development versions of CSS and JavaScript files, as opposed to minified versions. I hate editing minified code. While I’ve never used it, you may find it useful. Note that it only relates to the core WP files.
Use the WordPress Developer Plugins
Most WordPress developers don’t realize that there is a packaged set of developer plugins already staged and ready to be put into use. It’s a great set of tools to have in place.
Developer plugin by Automattic
It gives you the option to install several other options that may give you some more specific tools for your project. The highlights include a debug option in the upper right of the admin toolbar and user switching tools, which can be a HUGE time-saver if you are making certain features available only to users with a particular role.
Another plugin I like is the Kint Debugger. It lets you do var_dumps(), which is a super-power technique while you’re in the development cycle. You know how it is – you get this big, blank screen and wonder what broke or which variable is empty. Kind Debugger lets you find them fast without having to go back to your core PHP file, add the var_dump(), and upload for testing.
Get the Kint Debugger
Before rolling the code into production, deactivate these plugins and check out your error log to be sure that even these plugins are not hiding potential problems.
Use More Than One Browser
I use Chrome for 99% of my web-surfing and development. But for the purpose of debugging, I always click through the more important pages and features on multiple browsers.
My second choice is Firefox, which I’ll explain shortly. I also like to use Safari, Internet Explorer in various development modes, and Opera. If my code looks and acts like I expect it to after using several browsers, I feel much better about my code.
After viewing in several browsers, check your error logs. See if anything funky shows up and work through it.
Firebug for Firefox
Firebug is an extension you can install for Firefox and it’s almost important enough to get me to switch to Firefox as my primary browser – almost.
Get Firebug Here
This extension gives you a robust toolset for debugging with a developer pane at the bottom of your screen. You’re going to find all kinds of problems with your code. Some you may choose to ignore. Some may save your code from eventual combustion. Use Firebug. Seriously. Do it.
HTML Validation
One of the last things I do is run my HTML through the W3C Markup Validation Service. Just paste specific links into your page, set some options, and try not to flip out when you find out that half your page doesn’t meet standards. It happens to the best of us.
W3C Markup Validation Service
The markup services will give you a giant list of Errors and Warnings. Errors are code that are high risk for not working from browser to browser – or simply not working at all and you overlooked it. Many of the errors build upon each other, so by fixing a few you’ll see many others go away.
Add Testing and Debugging to Your Quote/Billable Time
Last, but certainly not least, is to make sure you have time budgeted for testing and debugging. One of the reasons I did such a poor job of debugging in my early days is because I didn’t budget the process into my time.
Bottom line, if you only have an hour of debugging in your budget, you’re probably not going to do a whole lot more than an hour worth of debugging. My budget varies wildly for each project, but the more complex the project, the more debugging and testing time I put into my quote.
Wrap Up
Debugging has to happen. It’s usually the hardest part of the process for me because my little ego is in the background saying, “It works! What could possibly go wrong?! Let’s get some coffee and move on to the next project!”
Don’t listen to that voice. As hard as it can be, muster your focus and take some time to debug your work. For me, the part that makes this the easiest for me is knowing that I’ve budgeted time for testing. So I owe it to my client to do the work and make sure I hand them a quality product.
The post Fast and Efficient WordPress Theme Debugging appeared first on YinPress.