print_r(), var_dump(), and echo

I don’t use print_r() exclusively to inspect variables: two other methods, var_dump() and echo, can work similarly.

echo, the main PHP function that prints things out to the page, can be used to inspect variables. However, it only works on strings and things that can be easily cast to strings, like integers. If you try to echo an array, you get just Array, and if you echo an object, you crash the site with a fatal error—neither very helpful for our “figure out what’s going on” purposes.

I do use var_dump() fairly often. var_dump() is more thorough than print_r(), but this means that it’s less readable, as in the following comparison:

php print_r example

print_r of a WP_Query object

var-dump of the same WP_Query object

var-dump of the same WP_Query object

However, sometimes you need var_dump() to fill in information that print_r() won’t show you, as in this example from Stack Overflow:

// Given $testarr = array( '', false, 42, array( '42' ) ); // Running var_dump( $testarr ); gives this result: array(4) { [0]=> string(0) "" [1]=> bool(false) [2]=> int(42) [3]=> array(1) {[0]=>string(2) "42")} } // Running print_r( $testarr ); gives this result: Array ( [0] => [1] => [2] => 42 [3] => Array ([0] => 42) )

As you can see, print_r() won’t distinguish between integers (42) and numerical strings ("42"), or between empty strings ("") and the boolean false. These distinctions matter, so reach for var_dump() when you need it!

For our purposes, though, print_r() is easier to read quickly, and it’s usually good enough to learn what we need to know about the variables we’re working with.

Example 1: Displaying All of a Post’s Custom Fields and their Values

For our first print_r() demo, we’re going to inspect all of a post’s custom fields, also called its post meta. I had to do this exact inspection recently because I wasn’t sure what custom fields some of my post types were carrying.

In a staging (not live) environment, in a new plugin or in your theme’s functions.php, the code we’ll write looks like this:

add_filter( 'the_content', 'wpshout_print_r_demo' ); function wpshout_print_r_demo( $content ) { $meta = get_post_meta( get_the_ID() ); print_r( $meta ); return $content; }

The code works as follows:

  1. We first hook into the the_content WordPress filter. We’re going to run our custom function wpshout_print_r_demo(), and we’re given the current post’s content, $content, to play with.
  2. get_post_meta() retrieves all custom fields for a given post ID, which we supply for the current post using get_the_ID(). We save all the fetched metadata to a variable, $meta.
  3. Next, we print_r() $meta, putting it onto the page in a human-readable form.
  4. Finally, we return the post’s content, $content, unchanged.

Why are we hooking this onto the the_content filter? For two reasons: first, hooking into the_content lets us use in-the-Loop functions like get_the_ID(). Second, it lets us know exactly where our print_r is going to print out: right above the content itself.

Here’s the result, viewed in-browser on the left and in Chrome Developer Tools on the right:

Click to enlarge

Click to enlarge

As you can see, we get an at-a-glance look at all the post meta attached to the current post—and as we browse the site, we’ll see this information for each post we look at until we disable the code above.

Example 2: Displaying the Posts Fetched by a Custom WP_Query

In this second print_r() demo, we’re going to display the posts fetched by a custom WP_Query. I run code similar to this frequently to quickly verify that my custom WP_Querys are behaving as I expect.

Here’s the code:

add_filter( 'the_content', 'wpshout_print_r_demo' ); function wpshout_print_r_demo( $content ) { $args = array( 'post_type' => 'post', 'tax_query' => array( array( 'taxonomy' => 'category', 'field' => 'slug', 'terms' => 'ideas', ), ), 'orderby' => 'title', 'order' => 'DESC', ); $newquery = new WP_Query( $args ); print_r( $newquery->posts ); return $content; }

As before, we’re hooking into the_content for convenience.

This time, we’re writing a custom query that fetches the following posts:

  1. Posts whose post_type is post,
  2. In the “Ideas” category (whose slug is ideas),
  3. Ordered in reverse alphabetical order.

We do this by creating an $args variable that specifies the three parameters just listed. We then pass $args into our WP_Query constructor, and the resulting WP_Query object gets saved to the variable $newquery. (If you’re not familiar with writing custom queries in WordPress, please check out our guide on the subject.)

Now for our print_r(): we’re going to print $newquery->posts. This means that we want just the posts property of the fetched WP_Query object—not the whole object itself.

So what we get on the page is a list of fetched post objects, with all their properties:

print_r wp_query example

Click to enlarge

As you can see, there’s a ton of data here; but scanning and seeing that each of the fetched posts is indeed from our “Ideas” category, and searching the page for post_title (and seeing that it does indeed work in reverse alphabetical order), provides enough of a commonsense check that I’ve written my query properly.