Skip to main content
add debugging without Xdebug
Source Link
4uk4
  • 101.7k
  • 7
  • 173
  • 217

This is tricky because you get a run-time error from a compiled twig template. All compiled templates are in /sites/default/files/php/twig/. Look for the class (line #2):

class __TwigTemplate_828c353f185da3d0ee07c237d52f8b71 extends Template

The path to this PHP file will tell you the real Twig template name, unless it is an inline template defined in PHP. Then go further down the stack trace to locate the inline template. This describes post-mortem debugging, using only the information provided in your question.

Locate template with Xdebug

However, if you reproduce the error locally use an IDE with Xdebug. This makes this whole process much faster because you can stop on exceptions, click on variables and stack trace. In this case, you find the full file name of the Twig template with the line number in the exception variable $e when the code stops the first time (enable stopping on exceptions in the IDE). This stop is in the class mentioned, now only in memory and not as file. Look at the variable $this.


Locate template without Xdebug

If you don't have Xdebug you can display/log the more helpful Twig runtime error by removing line #47 throw $previous_exception; in web/core/themes/engines/twig/twig.engine:

function twig_render_template($template_file, array $variables) {
  ...
  catch (RuntimeError $e) {
    // In case there is a previous exception, re-throw the previous exception,
    // so that the original exception is shown, rather than
    // \Twig\Template::displayWithErrorHandling()'s exception.
    $previous_exception = $e->getPrevious();
    if ($previous_exception) {
      // throw $previous_exception;
    }
    throw $e;
  }
  ...
}

The error message looks then like this:

Twig\Error\RuntimeError: An exception has been thrown during the rendering of a template
("strip_tags(): Argument #1 ($string) must be of type string, array given").
in Twig\Template->displayWithErrorHandling()
(line 123 of /var/www/myproject/web/themes/custom/mytheme/layout/page.html.twig).

This is tricky because you get a run-time error from a compiled twig template. All compiled templates are in /sites/default/files/php/twig/. Look for the class (line #2):

class __TwigTemplate_828c353f185da3d0ee07c237d52f8b71 extends Template

The path to this PHP file will tell you the real Twig template name, unless it is an inline template defined in PHP. Then go further down the stack trace to locate the inline template. This describes post-mortem debugging, using only the information provided in your question.

However, if you reproduce the error locally use an IDE with Xdebug. This makes this whole process much faster because you can stop on exceptions, click on variables and stack trace. In this case, you find the full file name of the Twig template with the line number in the exception variable $e when the code stops the first time (enable stopping on exceptions in the IDE). This stop is in the class mentioned, now only in memory and not as file. Look at the variable $this.

This is tricky because you get a run-time error from a compiled twig template. All compiled templates are in /sites/default/files/php/twig/. Look for the class (line #2):

class __TwigTemplate_828c353f185da3d0ee07c237d52f8b71 extends Template

The path to this PHP file will tell you the real Twig template name, unless it is an inline template defined in PHP. Then go further down the stack trace to locate the inline template. This describes post-mortem debugging, using only the information provided in your question.

Locate template with Xdebug

However, if you reproduce the error locally use an IDE with Xdebug. This makes this whole process much faster because you can stop on exceptions, click on variables and stack trace. In this case, you find the full file name of the Twig template with the line number in the exception variable $e when the code stops the first time (enable stopping on exceptions in the IDE). This stop is in the class mentioned, now only in memory and not as file. Look at the variable $this.


Locate template without Xdebug

If you don't have Xdebug you can display/log the more helpful Twig runtime error by removing line #47 throw $previous_exception; in web/core/themes/engines/twig/twig.engine:

function twig_render_template($template_file, array $variables) {
  ...
  catch (RuntimeError $e) {
    // In case there is a previous exception, re-throw the previous exception,
    // so that the original exception is shown, rather than
    // \Twig\Template::displayWithErrorHandling()'s exception.
    $previous_exception = $e->getPrevious();
    if ($previous_exception) {
      // throw $previous_exception;
    }
    throw $e;
  }
  ...
}

The error message looks then like this:

Twig\Error\RuntimeError: An exception has been thrown during the rendering of a template
("strip_tags(): Argument #1 ($string) must be of type string, array given").
in Twig\Template->displayWithErrorHandling()
(line 123 of /var/www/myproject/web/themes/custom/mytheme/layout/page.html.twig).
added 387 characters in body
Source Link
4uk4
  • 101.7k
  • 7
  • 173
  • 217

This is tricky because you get a run-time error from a compiled twig template. All compiled templates are in /sites/default/files/php/twig/. Look for the class (line #2):

class __TwigTemplate_828c353f185da3d0ee07c237d52f8b71 extends Template

The path to this PHP file will tell you the real Twig template name, unless it is an inline template defined in PHP. Then go further down the stack trace to locate the inline template. This describes post-mortem debugging, using only the information provided in your question.

However, if you reproduce the error locally use an IDE with Xdebug. This makes this whole process much faster because you can stop on exceptions, click on thevariables and stack trace to locate. In this case, you find the errorfull file name of the Twig template with the line number in the exception variable $e when the code stops the first time (enable stopping on exceptions in the IDE). This stop is in the class mentioned, now only in memory and not as file. Look at the variable $this.

This is tricky because you get a run-time error from a compiled twig template. All compiled templates are in /sites/default/files/php/twig/. Look for the class (line #2):

class __TwigTemplate_828c353f185da3d0ee07c237d52f8b71 extends Template

The path to this PHP file will tell you the real Twig template name, unless it is an inline template defined in PHP. Then go further down the stack trace to locate the inline template.

Xdebug makes this whole process much faster because you can click on the stack trace to locate the error.

This is tricky because you get a run-time error from a compiled twig template. All compiled templates are in /sites/default/files/php/twig/. Look for the class (line #2):

class __TwigTemplate_828c353f185da3d0ee07c237d52f8b71 extends Template

The path to this PHP file will tell you the real Twig template name, unless it is an inline template defined in PHP. Then go further down the stack trace to locate the inline template. This describes post-mortem debugging, using only the information provided in your question.

However, if you reproduce the error locally use an IDE with Xdebug. This makes this whole process much faster because you can stop on exceptions, click on variables and stack trace. In this case, you find the full file name of the Twig template with the line number in the exception variable $e when the code stops the first time (enable stopping on exceptions in the IDE). This stop is in the class mentioned, now only in memory and not as file. Look at the variable $this.

Source Link
4uk4
  • 101.7k
  • 7
  • 173
  • 217

This is tricky because you get a run-time error from a compiled twig template. All compiled templates are in /sites/default/files/php/twig/. Look for the class (line #2):

class __TwigTemplate_828c353f185da3d0ee07c237d52f8b71 extends Template

The path to this PHP file will tell you the real Twig template name, unless it is an inline template defined in PHP. Then go further down the stack trace to locate the inline template.

Xdebug makes this whole process much faster because you can click on the stack trace to locate the error.