Debugging, if not THE top, is close to the top of a web developer’s activities. That being the case I think every developer should have a personalized and custom set of debugging tools at their disposal to make their job easier.
Some of my favorite debugging tools are a pile of Sublime Text 2 (ST) snippets, and I want to share them with you. (note: these are all PHP/WordPress snippets)
-
echoprintr
- A fancy
print_r()
that’s wrapped inhtmlentities()
and<xmp>
tags.
echo '<xmp>$my_var: '. print_r( $my_var, true ) .'</xmp>';
-
adminnotice
- Do your debugging in wp-admin using the
all_admin_notices
hook.
I use this when I’m not working in a file, or need to test some logic unrelated to the file I’m working in. uses the ‘echoprintr’ snippet.
add_action( 'all_admin_notices', 'testing_admin_notice' ); function testing_admin_notice() { echo '<div id="message" class="updated">'; echo '<xmp>$my_var: '. print_r( $my_var, true ) .'</xmp>'; echo '</div>'; }
-
echovarexport
var_export()
is a gem I recently discovered that is similar tovar_dump()
andprint_r()
, “with one exception: the returned representation is valid PHP code.” This is awesome because you can copy the output back into your code and use it as an array. This snippet looks a bit gnarly because the default php implementation forvar_export
has a few shortcomings if you’re not on the latest and greatest version of php.
The output is wrapped in and<xmp>
tags for better readability.
echo '<xmp>$my_var = '. str_replace( array( 'stdClass::__set_state', 'array (', "=> \n ", "=> \r " ), array( '(object) ', 'array(', '=>' ), var_export( $my_var, true ) ) .';</xmp>';
-
emailme
- This snippet will use
wp_mail()
to send me an email with aprint_r()
of my variable. This snippet can be handy if you’re in the deep recesses of some code and outputting to the screen is next to impossible, and you don’t have a great way to access a log. Take it from experience, remember to remove it after running your code the first time.
This snippet’s courtesy of @tw2113.
wp_mail( 'you@youremail.com', '$my_var debug printout', print_r( $my_var, true) );
-
safeprint
- This snippet is the same as
echoprintr
except it’s wrapped in aif ( isset( $_GET['your-query-var-check'] ) )
conditional so that you can print something to the screen, but only if a query variable is met. This is handy if you need to do some debugging on a production site. Not that you would ever debug on a live production site…if ( isset( $_GET['debug'] ) ) { wp_die( '<xmp style="padding: 50px; background: #eee; color: #000;">$my_var: '. print_r( $my_var, true ) .'</xmp>' ); }
-
errlog
- This snippet is useful if you have the code
define( 'WP_DEBUG_LOG', true);
in your WordPress wp-config file.
It will append your debug data to the end of yourdebug.log
file (inside of wp-content). Useful for debugging chunks of data that you don’t want to (or can’t) output to the screen. Also saves your inbox from theemailme
snippet. For ultimate geeky debugging happiness, use the iTerm2 heads-up display (or any terminal app really), and from the command line, run:tail -f ~/YOUR-WORDPRESS-DIRECTORY/wp-content/debug.log
Weeeeeeee!
error_log( '$my_var: '. print_r( $my_var, true ) );
-
todebuglog
- This snippet is similar to the
errlog
listed above, but is able to handle more data. As you can see, you can also specify your own log file to send the output (if you don’t want to clutter the debug.log, or want the data separate).
Again, to tail this file, from the command line, run:tail -f ~/YOUR-WORDPRESS-DIRECTORY/wp-content/custom_debug.log
file_put_contents( WP_CONTENT_DIR . '/custom_debug.log', "\n" . '$my_var: '. print_r( $my_var, true ), FILE_APPEND );
-
wpdie
- This wraps the
echoprintr
snippet in awp_die()
call and stops the output to the screen with your debug data. The closer you place it to the top of the screen, the better your debug data will look. I use this one a TON when dealing with$_POST
form data when I want to stop the form from submitting.
wp_die( '<xmp>$my_var: '. print_r( $my_var, true ) .'</xmp>' );
If you’re not familiar with ST snippets, definitely get familiar.
Snippets can be stored under any package’s folder, but to keep it simple while you’re learning, you can save them to your Packages/User
folder. On a mac that would be located at:
/Users/YOURUSERNAME/Library/Application Support/Sublime Text/Packages/User
So where can you get these super useful debugging snippets?? Clone or Fork on GitHub.
Note: Since writing this article, I’ve replaced the usage of <pre>
tags with <xmp>
tags. Props @ceagon.
Disclaimer: These are my personal debugging snippets and are subject to change. :)
Update 12/3/13: I added snippets inline in case you’re not into the whole Sublime Text Snippets, or even github (gasp!). :)