WordPress - Debug Techniques

Adding code to WordPress produced one of the slowest and most painful debug cycles I have ever experienced. It takes almost 2 minutes per cycle. My current best guess is that there is a memory leak in JavaScript, jQuery (written in JavaScript), or some other JavaScript library. At any rate, periodically restarting the browser helps a lot.

Much of the data presented below was developed by starting with a working plugin and trying to modify it for my use. Normally, errors produced when using this approach are easy to find ... but not with WordPress ... what a disaster.

echo - Display text and variables

The primary technique is to simply output some text that says "I am here" - it just indicates where the code is executing..

  echo 'some string';                        // I place these throughout the code

  echo "<br>start of subroutine_name ";      // I use these to see which routines are called

It is also useful to see what the values of some variables are. Because these are displayed in the web page, adding spaces or a little html will make the output easier to read.

  echo '<br> $variable1 - '.$variable1;  // single quotes stop the variables from being evaluated
  echo "<br> \$variable2 - $variable2";  // double quotes allow the variable to be evaluated
                                         // the backslash makes the magic character print normally (\$)

  echo "<br> array1['id'] = {$array1['id']}";   // curly braces are required for arrays

  echo '<!-- rlc note - '.$_GET['page'].' -->'; // visible in the html but not displayed
                                                // the dot ( . ) means concatenate

If you uses double quotes, then variables will be converted and linebreaks (\n) will work.

  echo "debug_message - $debug_message \n";   // places a line break in the output
                                              // however <br> displays a line break

In various routines, you would add code similar to the following

  global $debug_message;
  $debug_message .= "<br>$sql"; // concatenate new info to the existing string

and display the results via

  echo "debug_message - $debug_message";

For those messages that flash by too fast to read, try Ctrl-Shift-PrtSc (to capture a screen image) and then paste into Windows Paint (under Accessaries/Paint.)

DEBUG Flag

When starting out, database errors were exceptionally hard to debug. The information in this section should help a lot.

You could add ** define('WP_DEBUG', true); ** to your wp-config.php file - I haven't tried this yet.

In the wpdb constructor

if ( defined('WP_DEBUG') and WP_DEBUG == true )
  $this->show_errors();  // sets the flag to true

These are used in wp-db.php

if ( detect an error )
  $this->bail('any string'); // produces an error even if errors are not enabled
                             // terminates program if error display is not enabled

// Is error output turned on or not..
if ( !$this->show_errors )   // this controls error output
  return false;

The following is from wp-settings.php, it controls the display of php errors

// Add define('WP_DEBUG',true); to wp-config.php to enable display of notices during development.
if (defined('WP_DEBUG') and WP_DEBUG == true) {
  error_reporting(E_ALL);
} else {
  if ( defined('E_RECOVERABLE_ERROR') )
    error_reporting(E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING | E_RECOVERABLE_ERROR);
  else
    error_reporting(E_ERROR | E_WARNING | E_PARSE | E_USER_ERROR | E_USER_WARNING);
}

If you don't want to bother editing wp-settings.php, then placing the following in your code (and calling it) will enable database errors to be displayed

function display_all_errors(){
  global $wpdb;
  $wpdb->show_errors();      // sets the database flag to true

  error_reporting(E_ALL);   // I assume this will also be useful - part of php
}

A database error example (I had to capture this as an image using Ctrl-Shift-PrtSc)

WordPress database error: [unknown column '0' in 'where clause']
UPDATE `wp_tablename` SET `field1` = 'string' ... WHERE `0` = 0

My problem turned out to be using the wrong operator for creating an array.

  $where = array('book_id' >= $book_id); // wrong

  $where = array('book_id' => $book_id); // correct

var_dump

Sometimes, particularly with complex data types, echo won't display anything. In these cases, try var_dump. Using the simplexml example, var_dump displayed

object(SimpleXMLElement)#301 (4) { ["title"]=> string(11) "Forty What?" ["from"]=> string(3) "Joe" ["to"]=> string(4) "Jane" ["body"]=> string(57) " I know that's the answer -- but what's the question? " }

However, since the actual formatting (in the html file) was

object(SimpleXMLElement)#301 (4) {
  ["title"]=>
  string(11) "Forty What?"
  ["from"]=>
  string(3) "Joe"
  ["to"]=>
  string(4) "Jane"
  ["body"]=>
  string(57) "
  I know that's the answer -- but what's the question?
 "
}

the data can be displayed on more than one line by encapsulating var_dump in <pre> tags.

$xml = simplexml_load_string($string); echo '<pre>'; var_dump($xml); echo '</pre>';

As mentioned above, in this case, the echo command did not print anything.

echo $xml; // this shows nothing

Author: Robert Clemenzi