Display Errors and Print Variables in Drupal CMS

Don’t forget to subscribe to our YouTube channel to stay up-to-date.

Debugging Drupal involves using tools to display errors, inspect variables, and step through code. Knowing these techniques is crucial for troubleshooting issues like the White Screen of Death (WSOD) and can prevent hours of frustration.

The video above covers basic error display configuration, advanced debugging with Xdebug, and practical tools like Devel, WebProfiler, and Ignition for productive Drupal development.

Display Errors in Drupal

To troubleshoot in Drupal, first learn how to view basic error messages. Drupal often hides errors by default, complicating development.

Display Errors from Backend

Drupal offers integrated settings for error reporting levels. You can choose to display or hide errors, warnings, and notices. Adjust these settings via Configuration > Development > Logging and errors.

Here you can choose between:

• None: Hides all error messages (suitable for production)
• Errors and warnings: Shows important issues
• All messages: Displays everything including notices (recommended for development)
• All messages, with backtrace information: Displays everything and the backtrace

Display Errors from Drush

Drush provides a command-line interface for managing Drupal configuration, including error display settings.

You can check the current error display setting using Drush commands and modify them without accessing the Drupal backend. This is useful when dealing with a WSOD where you cannot access the backend.

Error Display Drush Command

The Drush configuration command allows you to view and set error display levels directly from the command line.

Use the following command to check current error reporting:

drush config:get system.logging error_level

To set error display to verbose mode:

drush config:set system.logging error_level verbose

DDEV Overrides Settings

When working with DDEV as your local development environment, be aware that it includes default settings that may override your Drupal configuration.

DDEV includes a settings file that automatically enables error reporting and other development-friendly configurations.

Check your settings.ddev.php or similar files to understand what’s being overridden.

If you want to remove the override simply open settings.ddev.php and comment out the following:

$config['system.logging']['error_level'] = 'verbose';

View Errors from Recent Log Messages

Drupal’s database logging system (dblog) records all errors, warnings, and notices even when they’re not displayed on screen.

Navigate to Reports, then Recent log messages to view a comprehensive list of all logged events. You can filter by severity level and message type to find specific issues.

Warning About Using Database Logs

While convenient for development, note the module’s limitations. Database logging can impact performance on high-traffic sites due to database write operations.

For production, use syslog or external logging services instead.

Go to Configuration, “Logging and errors” and make sure you select a low number for “Database log messages to keep”. Never leave it set at “All”.

WebProfiler

WebProfiler is a development module that provides detailed insights into your Drupal site’s performance and behavior. It creates a toolbar at the bottom of your page with debugging information.

Install and Configure WebProfiler

To install it, use Composer:

composer require 'drupal/webprofiler:^11.1'

Then navigate to Extend and enable the WebProfiler module.

View Error Page Using WebProfiler

When an error occurs on your site, WebProfiler captures detailed information including the exception message, stack trace, and execution context.

The WebProfiler toolbar appears at the bottom of error pages, allowing you to inspect what went wrong even when standard error display is disabled.

Using WebProfiler

WebProfiler provides multiple panels showing different aspects of your application:

• Timeline: Shows execution time for different operations
• Database: Lists all database queries with timing information
• Forms: Displays submitted form data and validation
• Events: Shows all dispatched Symfony events
• Cache: Information about cache operations

Click on any panel to expand detailed information about that aspect of the request.

Ignition Error Pages

Ignition is an error page package that makes error messages more readable and provides debugging features. While originally designed for Laravel, it works with Drupal via the module.

It provides features such as:

• Syntax-highlighted code snippets
• Interactive stack traces
• Solution suggestions for common errors
• Ability to open files directly in your editor

Start by downloading it using Composer:

composer require 'drupal/ignition:^1.0'

Composer Install Workaround

As of this writing, installing Ignition in Drupal requires a specific Composer configuration approach due to package dependencies.

If you have Drupal AI installed on your site you’ll need to downgrade the version of openai-php/client to v0.10.3 by running the following command:

composer require 'drupal/ignition:^1.0' -W

This could possibly be fixed in a future version of the module.

Setting Change When Using WebProfiler with Ignition

When using both WebProfiler and Ignition together, you will need to adjust configuration settings to prevent conflicts.

Ensure that WebProfiler’s exception handler doesn’t interfere with Ignition’s error display by adding the following settings change in your settings.php.

$settings['webprofiler_error_page_disabled'] = TRUE;

If you don’t do this, then the WebProfiler error page will always be displayed.

Testing Error Page

After installing Ignition, trigger a test error to verify it’s working correctly.

Print Variables in Drupal

Debugging code requires understanding variable values during execution. Drupal offers functions for printing variables during development.

Turn Off Caching

Before debugging with print functions, disable Drupal’s caching to ensure you see changes immediately.

Navigate to Configuration, Development settings, and turn off caching by toggling “Do not cache markup”.

Problem with print_r

While PHP’s native print_r() function works in Drupal, it has limitations:

• Output is not formatted for web display
• Complex objects may not display completely
• No syntax highlighting
• Can break page rendering if used in the wrong context

Using dump() Function

The dump() function from Symfony’s VarDumper component provides formatted, readable output of variables.

It displays variables with syntax highlighting, type information, and expandable nested structures. Simply use:

dump($variable);

The output appears in the page content where the function is called.

Using dd() Function

The dd() function (dump and die) works like dump() but stops script execution immediately after displaying the variable.

This is useful when you want to inspect a variable and prevent further code execution:

dd($variable);

Using Devel

The Devel module is essential for Drupal development, providing debugging and development utilities.

Intro to Devel

Devel includes tools for:

• Inspecting variables and objects
• Generating dummy content
• Analyzing database queries
• Clearing cache
• Rebuilding menus and routes

Install it with:

composer require 'drupal/devel:^5.4'

Using dpm() Function

The dpm() function displays variables as formatted messages at the top of the page.

dpm($variable, 'Variable label');

This function integrates with Drupal’s message system, making output appear in a familiar location without disrupting page layout.

Using ddebug_backtrace() Function

The ddebug_backtrace() function displays a complete call stack showing how code execution reached the current point.

This is invaluable when trying to understand how a particular function or method was invoked:

ddebug_backtrace();

Using Kint

Kint is another variable dumper that integrates with Devel to provide detailed and interactive variable inspection.

Intro to Kint

Kint enhances Devel’s variable display functions with:

• Collapsible, hierarchical display of complex structures
• Search functionality within dumped variables
• Method and property visibility indicators

Configure Kint in Devel

After installing Devel, enable Kint as the default dumper in the Devel settings.

Navigate to Configuration, Development, then Devel settings. Under “Variables Dumper” select Kint.

Configure Kint

Kint provides its own configuration options including:

• Maximum nesting depth for objects
• String length limits
• Theme selection (dark or light)
• Display modes

Access these settings by going to Configuration and clicking on “Kint settings”.

Using Kint with dpm() Function

Once Kint is configured as the default dumper, all Devel dump functions automatically use Kint’s enhanced display:

dpm($complex_object);

The variable will now display with Kint’s interactive interface, allowing you to expand and collapse nested structures.

Log Variables into DB Log

Sometimes you need to preserve variable values for later inspection rather than displaying them immediately.

Save Variable into DB Log

Drupal’s logging system allows you to write custom log entries programmatically:

\Drupal::logger('some_channel_name')->debug('Variable value: <pre><code>%var</code></pre>', [
  '%var' => var_export($variables['elements']['#cache'], TRUE)
]);

These entries appear in Reports > Recent log messages along with timestamp and severity information.

Print Variables in Twig

When debugging theme layer issues, you need to inspect variables within Twig templates.

Need Twig Debugging On

Enable Twig debugging to see available variables in template files.

Go to Configuration, Development Settings, then turn on “Twig development mode” and make sure both options are on: Twig debug mode and Twig disable twig cache.

Printing Variables in Twig Templates

Twig provides the dump() function for displaying variables:

{{ dump(variable) }}

You can dump specific properties:

{{ dump(node.title.value) }}

Xdebug

Xdebug is a debugging tool for stepping through code, examining variables, and understanding application behavior.

Intro to Xdebug

Xdebug provides:

• Step debugging with breakpoints
• Variable inspection at any execution point
• Call stack analysis
• Code coverage analysis
• Profiling capabilities

Unlike print-based debugging, Xdebug allows interactive debugging without modifying code.

Enabling Xdebug in DDEV

DDEV includes Xdebug but it’s disabled by default for performance. Enable it with:

ddev xdebug on

To disable when not needed:

ddev xdebug off

Setup Xdebug in VS Code

Please refer to the DDEV IDE setup documentation for instructions on how to set up Xdebug in VS Code.

Use Xdebug in VS Code

To debug with VS Code:

1. Set breakpoints by clicking in the gutter next to line numbers
2. Start the debugger by pressing F5 or clicking the play button in the debug panel
3. Load your Drupal page in the browser
4. Execution will pause at your breakpoints
5. Use the debug toolbar to step through code, inspect variables, and analyze execution

Use Xdebug in PhpStorm

PhpStorm has built-in Xdebug support with minimal configuration.

1. Switch on “Start Listening for PHP Debug Connections”
2. Set breakpoints and load your page
3. The first time you run PhpStorm, it will ask you to map a folder and it will set up a server for you

Create Custom Module and Controller

To demonstrate debugging in custom code, create a simple custom module.

To create a module and a controller, just run the two following Drush commands:

drush generate module

Make sure you enable the module and then generate the controller:

drush generate controller

Below is a copy of the code from the __invoke() method:

 public function __invoke(): array {
    $build = [];
    // Query and load the latest page nodes.
    $node_storage = \Drupal::entityTypeManager()->getStorage('node');

    $nids = $node_storage->getQuery()
      ->condition('type', 'page')
      ->condition('status', 1)
      ->sort('created', 'DESC')
      ->accessCheck(TRUE)
      ->execute();

    $nodes = $node_storage->loadMultiple($nids);

    // Build the output.
    $items = [];
    foreach ($nodes as $node) {
      $items[] = $node->getTitle();
    }

    $build['content'] = [
      '#theme' => 'item_list',
      '#items' => $items,
      '#title' => $this->t('Latest Page Titles'),
    ];

    return $build;
  }

Print Variables vs Xdebug

While using dump()or print_r() is quick for simple issues, Xdebug provides significant advantages:

• No code modification: Set breakpoints without editing files
• Complete context: See all variables in scope, not just what you print
• Step through execution: Understand code flow interactively
• Conditional breakpoints: Pause only when specific conditions are met
• Call stack navigation: Jump between function calls in the execution chain

Add Watches

Watches allow you to monitor specific variables or expressions continuously during debugging.

In your IDE’s debug panel, add watches for variables you want to track across different execution points. The watch values update automatically as you step through code.

The way you set watches is different in PhpStorm and VS Code, so please refer to the documentation.

Using Xdebug in Twig

Xdebug does integrate with Twig templates to some level, but it’s not the same as stepping through a PHP file.

If you add {{ devel_breakpoint() }} into your Twig template, Xdebug will show you the compiled PHP file and all of its arguments.

But you can’t step through a Twig template as far as I’m aware. If somebody knows how to do that, please leave a comment.

Summary

Effective debugging in Drupal requires understanding multiple tools and techniques:

• Basic error display through configuration settings and Drush commands
• WebProfiler for comprehensive request analysis and performance insights
• Ignition for beautiful, interactive error pages
• Devel and Kint for quick variable inspection during development
• Database logging for persistent error tracking
• Twig debugging for theme layer troubleshooting
• Xdebug for professional step-through debugging

Start with simpler tools like error display configuration and Devel for straightforward debugging tasks. When issues become complex or you need to understand code execution, then use Xdebug.