Drupal 7: debug() and SimpleTest->verbose()

Recently, I have made two major improvements to debugging in Drupal 7, the addition of a general debug function and a verbose mode for SimpleTest. The two additions make it much easier to debug problems quickly through the use of a consistent method. Take a look at what chx said via twitter:

Writing #drupal code? Check the new function debug(). Writing #drupal tests? Check $this->verbose(). And debug() works too. AWESOME!

General debug function

The general debug function can be used at any point after Drupal is bootstrapped, although the limitation may be removed in the future. The function provides a very simple wrapper to dump data through the use of var_export() and print_r(). When used normally it will display data based on the “Logging and errors” settings provided in Drupal 7 core. If using a dev version the debug information will be displayed using drupal_set_message() as shown in the screenshot below.

The exciting part about the new debug() function is that it also works during testing. The debug() function can be placed inside the test itself or in any other part of Drupal and it will be picked up and displayed in the test results as shown below.

SimpleTest verbose mode

Another exciting new debugging tool that is extremely useful when writing tests is the new verbose mode for Drupal 7 SimpleTest. The verbose mode can be enabled on the SimpleTest settings page.

Once enabled SimpleTest will automatically record the page as it was seen by the SimpleTest browser after each drupalGet() and drupalPost() call. A link is then placed in the test results that will display the page the browser saw and some meta data related to the request.

Page 1

Page 2

Manual verbose

In addition to the automatic message provided by SimpleTest custom verbose data may be dumped using DrupalWebTestCase->verbose() which can be used in a test as shown.

$this->verbose($data);

If the data to be dumped in not available in the test, but in the code being tested a function is provided that may be accessed by including the DrupalWebTestCase as shown below.

require_once drupal_get_path('module', 'simpletest') . '/drupal_web_test_case.php';
simpletest_verbose($data);

Summary

By adding these debugging tools to Drupal 7 the developer experience involved in writing a test has been greatly improved. These methods can still be improved and as such please feel free to file issues in the Drupal 7 SimpleTest issue queue. Also note that this work was sponsored by Acquia as part of my Summer Internship.

openSUSE one-click for LAMP and Drupal

I decided to play around and see if I could create an YaST Meta Package for:

• LAMP stack
• Drupal/SimpleTest required PHP extensions
• phpMyAdmin

After a quick read of the Build Service/Tutorial and a talk with cyberorg in IRC (#suse/#opensuse-buildservice) I was able to upload my pattern to the openSUSE build service.

It was quite simple as I expected since openSUSE’s build service and such seem to be quite nice. I have plans to fix up some of my other Drupal packages, add more, and work on personal projects. If you use openSUSE and give it a try, let me know if it works or you have any feedback.

My repository is available at:

• http://download.opensuse.org/repositories/home:/boombatower/openSUSE_11.1/.
• https://build.opensuse.org/project/show?project=home%3Aboombatower

Help D7 SimpleTest maintainer and usablity expert get to Drupalcon Paris 2009

For posterity: http://widget.chipin.com/widget/id/6238d4a38871fb20

The scholarships provided by the Drupalcon Paris team will not cover all the accommodation expenses. Bojhan and myself (boombatower) have decided to stay together and share the expenses. In order to make it to Paris we need to raise at least $500 USD, otherwise I will not be attending.

Take a look at our user pages to get an idea of the work we have done for Drupal.

I plan to give two sessions: Introduction to testing with Drupal: SimpleTest and Sept 2nd, Drupal 7 release party. How continuous integration testing made this plausible.

Bojhan has two presentation proposals as well: Building blocks for your module’s UI and How Open Design will drive Drupal 8.

We appreciate your donations and hope to accomplish much at Drupalcon Paris.

Update restore pattern

Recently I have been working on confirming that the Project Issue File Review (PIFR) and Project Issue File Testing (PIFT) update paths from 1.x to 2.x work properly. I was attempting to do so with a copy of the live data from testing.drupal.org and drupal.org. Doing so would ensure that the somewhat delicate upgrade path functioned properly.

I ran into the issue of resetting the data after a failed update attempt. Doing so is not a quick and simple task, especially for the PIFR upgrade which requires renaming the old tables (I may move into udpate path itself) so the data can be converted and placed in the new schema. To solve the problem I developed the following script, or pattern, that can be used to reset for another update attempt. The first script is the one used for the PIFT update which is much simpler. The pift_data.sql contains the live data from drupal.org and similar with the PIFR update.

I placed the scripts in index.php, just as I do with all my scripts, after the drupal_bootstrap(DRUPAL_BOOTSTRAP_FULL); line. The scripts can then be ivoked by appending ?restore=true to the URL to your site. Obviously I commented out the one I was not using.

I found that having these scripts helped ensure that I tested the update path extensively and as such they seem like a good thing to share.

PIFT update reset script

if (isset($_GET['restore'])) {
  header('Content-Type: text/plain');
  ini_set('display_errors', 1);
  set_time_limit(0);

  echo "resetting...\n";

  db_query('TRUNCATE TABLE {watchdog}');

  db_query("UPDATE {system}
            SET schema_version = %d
            WHERE name = '%s'", 6000, 'pift');

  $tables = array(
    'pift_data',
    'pift_test',
    'pift_project',
  );
  $ret = array();
  foreach ($tables as $table) {
    if (db_table_exists($table)) {
      db_drop_table($ret, $table);
    }
  }

  echo "importing d.o dataset...\n";

  $parts = parse_url($db_url['default']);
  $command = "mysql -u{$parts['user']} -p{$parts['pass']} " . substr($parts['path'], 1);
  exec($command . ' < /home/boombatower/download/pift_data.sql');

  echo "finished...\n";

  print_r($ret);

  exit;
}

PIFR update reset script

if (isset($_GET['restore'])) {
  header('Content-Type: text/plain');
  ini_set('display_errors', 1);
  set_time_limit(0);

  echo "resetting...\n";

  db_query('TRUNCATE TABLE {watchdog}');

  db_query("UPDATE {system}
            SET schema_version = %d
            WHERE name = '%s'", 6000, 'pifr');

  $tables = array(
    'pifr_branch',
    'pifr_client',
    'pifr_file',
    'pifr_log',
    'pifr_project',
    'pifr_result',
    'pifr_result_detail',
    'pifr_result_detail_assertion',
    'pifr_test',
    'pifr_file_old',
    'pifr_result_old',
    'pifr_server',
    'pifr_log_old',
  );
  $ret = array();
  foreach ($tables as $table) {
    if (db_table_exists($table)) {
      db_drop_table($ret, $table);
    }
  }

  echo "importing t.d.o dataset...\n";

  $parts = parse_url($db_url['default']);
  $command = "mysql -u{$parts['user']} -p{$parts['pass']} " . substr($parts['path'], 1);
  exec($command . ' < /home/boombatower/download/tdo.sql');

  echo "renaming...\n";

  db_rename_table($ret, 'pifr_file', 'pifr_file_old');
  db_rename_table($ret, 'pifr_result', 'pifr_result_old');
  db_rename_table($ret, 'pifr_log', 'pifr_log_old');

  echo "importing pifr_server schema...\n";

  exec($command . ' < /home/boombatower/download/pifr_server.sql');

  echo "finished...\n";

  print_r($ret);

  exit;
}

Drupal Firefox persona

On the same track as my recent customizations I created a Drupal Persona a while back and decided to post it.

Let me know what you think.