Very quick php snippet testing in Drupal

Mon, Feb 22, 2010 - 6:42pm -- Isaac Sukin

I use this trick all the time, practically every day in fact when I'm building a website. When you need to test a PHP snippet or you want to find out how something responds -- you want to see the structure that taxonomy_get_tree() returns, for example, or you forgot what the structure of the data returned from a multi-select form element is -- you can use this shortcut instead of going through the whole tedious process of writing a module or running the risk of blowing up your site by saving the PHP in a node.

If you have the PHP filter module enabled, just go to node/add/page or the equivalent, write or copy-paste your code into the content box, and set the input format to PHP. Copy whatever code you just wrote/pasted and then click Preview. Voila!

If your code doesn't fail, it will show whatever it was designed to show. (Remember that you need to actually call your functions somewhere if you add in functions -- hooks won't respond when you create them this way.) If it does fail, you will usually get an error (you should enable on-screen error reporting for simplicity) and you can then quickly fix your code. If you fail miserably, you will get a WSOD, but your website is not borked -- just click the "Back" button, paste your code back in the box (you copied it before clicking "Preview," right?) and fix it.

Note that if you paste the contents of a function instead of the function itself, you can get away with keeping the return statement -- anything returned will be automatically printed. (But don't forget those <?php ?> tags!)

This method is a great way to remind yourself of how things work or check to make sure a snippet works before putting it in a module. Don't save a node with PHP code in it or upgrading will be a humongous pain later. You also get the added bonus that you can add as many debugging statements as you want and it won't interrupt parts of the site that your users might be visiting (but you're using a staging site, so that shouldn't matter, right?).


This is a template I use so often that I actually have a node specifically saved with it (only on dev sites of course) so that I can just go directly to the edit screen for this node and start using the template right away.


Wrapping your PHP with <pre> tags lets you print structured information in an easy-to-read manner. For example, you can print arrays and objects like this:

$my_complex_object = mymodule_get_complex_object();

Note that if you don't need to print structured information (if you want to test a form, for example) then all you need is the opening <?php tag -- no closing tag necessary. (However, you must close <pre> if you use it.)

Instead of print_r(), you can also use var_dump() or var_export. All three of those functions print immediately by default; print_r() and var_export() have an extra boolean parameter that lets you return the string instead of printing it so that you can print it (or store it) later. Other than that the functions are almost identical except that the format they use is slightly different. I find print_r() the easiest to read. If you have the Devel module installed, you can use dsm() or krumo() instead, which are much better.

Bonus 2

print_r() and var_export() are particularly useful if you are trying to debug a complex function and simply outputting the data in an unstructured way in drupal_set_message() just isn't working for you (again, dsm() and krumo() are better if you have Devel installed). You can use them to store the data you want to check in a variable, and then use the technique explained above to expose that variable in a structured manner. Just remember to delete the variable when you're done with it.

//in the module
$my_complex_object = mymodule_get_complex_object();
variable_set('my_test_variable', print_r($my_complex_object, TRUE));
//in the node preview
echo '<pre>'. variable_get('my_test_variable', '') .'</pre>';

Clearly these tricks are not appropriate in all situations, but they are often incredibly useful for quick-and-dirty memory-refreshing or debugging. Hopefully they help you in your quest for Drupal domination.