drupal 8 enable twig debug not working?

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP



drupal 8 enable twig debug not working?



I'm trying to get my head around this: I don't know why the twig debug isn't working:

Drupal version 8.2.6



Folder structure



File structure .



Folder permissions



Folder permissions



Settings.php


$settings['hash_salt'] = 'DEVELOPMENT_SALT';
$settings['update_free_access'] = FALSE;
$settings['file_public_base_url'] = 'http://localhost/files';
$settings['file_public_path'] = 'sites/default/files';
$settings['file_private_path'] = 'sites/default/private';
$settings['file_scan_ignore_directories'] = [
'node_modules',
'bower_components',
];
if (file_exists(__DIR__ . '/../development/settings.development.php'))
include __DIR__ . '/../development/settings.development.php';



/../development/settings.development.php


assert_options(ASSERT_ACTIVE, TRUE);
DrupalComponentAssertionHandle::register();

/**
* Enable local development services.
*/
$settings['container_yamls'] = __DIR__ . '/development.services.yml';

$databases['default']['default'] = array(
'database' => 'dbname',
'username' => 'dbusername',
'password' => 'pw',
'prefix' => '',
'host' => '127.0.0.1',
'port' => '3306',
'namespace' => 'Drupal\Core\Database\Driver\mysql',
'driver' => 'mysql',
);

$settings['hash_salt'] = 'DEVELOPMENT';

$config['system.logging']['error_level'] = 'verbose';
$config['system.performance']['css']['preprocess'] = FALSE;
$config['system.performance']['js']['preprocess'] = FALSE;
$settings['cache']['bins']['render'] = 'cache.backend.null';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';
$settings['extension_discovery_scan_tests'] = TRUE;
$settings['rebuild_access'] = TRUE;
$settings['skip_permissions_hardening'] = TRUE;



development.services.yml


parameters:
http.response.debug_cacheability_headers: true
twig.config:
debug: true
auto_reload: true
cache: false
services:
cache.backend.null:
class: DrupalCoreCacheNullBackendFactory



Things I have checked/done:



If I change a template, it changes, but no twig debugging.



What is odd:
sites/default/files AND sites/default/private are not used by Drupal.





I suggest that you can ask your question on drupal.stackexchange.com
– malcolm
Mar 14 '17 at 20:49





Just in case what do you expect of the debugging? In most cases the answer of vijay is enough to show you the template information (if you view source). If you want to show available variables you wil of course need to add dump() to your twig template (be careful when you have much data this can give you a memory error in that case coderate's answer should be helpfull)
– melvin
Mar 23 '17 at 9:19





4 Answers
4



To enable Twig debug, you need to copy("default.services.yml") and rename it to "services.yml". And set "debug: false" to true.



E.g: services.yml


parameters:
session.storage.options:
# Default ini options for sessions.
#
# Some distributions of Linux (most notably Debian) ship their PHP
# installations with garbage collection (gc) disabled. Since Drupal depends
# on PHP's garbage collection for clearing sessions, ensure that garbage
# collection occurs by using the most common settings.
# @default 1
gc_probability: 1
# @default 100
gc_divisor: 100
#
# Set session lifetime (in seconds), i.e. the time from the user's last
# visit to the active session may be deleted by the session garbage
# collector. When a session is deleted, authenticated users are logged out,
# and the contents of the user's $_SESSION variable is discarded.
# @default 200000
gc_maxlifetime: 200000
#
# Set session cookie lifetime (in seconds), i.e. the time from the session
# is created to the cookie expires, i.e. when the browser is expected to
# discard the cookie. The value 0 means "until the browser is closed".
# @default 2000000
cookie_lifetime: 2000000
#
# Drupal automatically generates a unique session cookie name based on the
# full domain name used to access the site. This mechanism is sufficient
# for most use-cases, including multi-site deployments. However, if it is
# desired that a session can be reused across different subdomains, the
# cookie domain needs to be set to the shared base domain. Doing so assures
# that users remain logged in as they cross between various subdomains.
# To maximize compatibility and normalize the behavior across user agents,
# the cookie domain should start with a dot.
#
# @default none
# cookie_domain: '.example.com'
#
twig.config:
# Twig debugging:
#
# When debugging is enabled:
# - The markup of each Twig template is surrounded by HTML comments that
# contain theming information, such as template file name suggestions.
# - Note that this debugging markup will cause automated tests that directly
# check rendered HTML to fail. When running automated tests, 'debug'
# should be set to FALSE.
# - The dump() function can be used in Twig templates to output information
# about template variables.
# - Twig templates are automatically recompiled whenever the source code
# changes (see auto_reload below).
#
# For more information about debugging Twig templates, see
# https://www.drupal.org/node/1906392.
#
# Not recommended in production environments
# @default false
debug: true
# Twig auto-reload:
#
# Automatically recompile Twig templates whenever the source code changes.
# If you don't provide a value for auto_reload, it will be determined
# based on the value of debug.
#
# Not recommended in production environments
# @default null
auto_reload: null
# Twig cache:
#
# By default, Twig templates will be compiled and stored in the filesystem
# to increase performance. Disabling the Twig cache will recompile the
# templates from source each time they are used. In most cases the
# auto_reload setting above should be enabled rather than disabling the
# Twig cache.
#
# Not recommended in production environments
# @default true
cache: true
renderer.config:
# Renderer required cache contexts:
#
# The Renderer will automatically associate these cache contexts with every
# render array, hence varying every render array by these cache contexts.
#
# @default ['languages:language_interface', 'theme', 'user.permissions']
required_cache_contexts: ['languages:language_interface', 'theme', 'user.permissions']
# Renderer automatic placeholdering conditions:
#
# Drupal allows portions of the page to be automatically deferred when
# rendering to improve cache performance. That is especially helpful for
# cache contexts that vary widely, such as the active user. On some sites
# those may be different, however, such as sites with only a handful of
# users. If you know what the high-cardinality cache contexts are for your
# site, specify those here. If you're not sure, the defaults are fairly safe
# in general.
#
# For more information about rendering optimizations see
# https://www.drupal.org/developing/api/8/render/arrays/cacheability#optimizing
auto_placeholder_conditions:
# Max-age at or below which caching is not considered worthwhile.
#
# Disable by setting to -1.
#
# @default 0
max-age: 0
# Cache contexts with a high cardinality.
#
# Disable by setting to .
#
# @default ['session', 'user']
contexts: ['session', 'user']
# Tags with a high invalidation frequency.
#
# Disable by setting to .
#
# @default
tags:
# Cacheability debugging:
#
# Responses with cacheability metadata (CacheableResponseInterface instances)
# get X-Drupal-Cache-Tags and X-Drupal-Cache-Contexts headers.
#
# For more information about debugging cacheable responses, see
# https://www.drupal.org/developing/api/8/response/cacheable-response-interface
#
# Not recommended in production environments
# @default false
http.response.debug_cacheability_headers: false
factory.keyvalue:

# Default key/value storage service to use.
# @default keyvalue.database
# default: keyvalue.database
# Collection-specific overrides.
# state: keyvalue.database
factory.keyvalue.expirable:

# Default key/value expirable storage service to use.
# @default keyvalue.database.expirable
# default: keyvalue.database.expirable
# Allowed protocols for URL generation.
filter_protocols:
- http
- https
- ftp
- news
- nntp
- tel
- telnet
- mailto
- irc
- ssh
- sftp
- webcal
- rtsp

# Configure Cross-Site HTTP requests (CORS).
# Read https://developer.mozilla.org/en-US/docs/Web/HTTP/Access_control_CORS
# for more information about the topic in general.
# Note: By default the configuration is disabled.
cors.config:
enabled: false
# Specify allowed headers, like 'x-allowed-header'.
allowedHeaders:
# Specify allowed request methods, specify ['*'] to allow all possible ones.
allowedMethods:
# Configure requests allowed from specific origins.
allowedOrigins: ['*']
# Sets the Access-Control-Expose-Headers header.
exposedHeaders: false
# Sets the Access-Control-Max-Age header.
maxAge: false
# Sets the Access-Control-Allow-Credentials header.
supportsCredentials: false



I'd recommend against renaming the development.services.yml file to services.yml because that would cause all of your development code/config/settings to apply and run on production environments. Instead, use the development files as designed.



Here's our standard setup:



/sites/default/settings.php (in version control) contains the following at the very bottom so that we only load development stuff on instances that should have it. e.g. NOT production:


/sites/default/settings.php


/**
* Load local development override configuration, if available.
*
* Keep this code block at the end of this file to take full effect.
*/
if (file_exists(__DIR__ . '/settings.local.php'))
include __DIR__ . '/settings.local.php';



Our /sites/default/settings.local.php (not in version control) contains at least the following:


/sites/default/settings.local.php


<?php

/**
* Disable css and js preprocessing.
*/
$config['system.performance']['css']['preprocess'] = FALSE;
$config['system.performance']['js']['preprocess'] = FALSE;

/**
* Disable Render Cache and Dynamic Page Cache.
*/
$settings['cache']['bins']['render'] = 'cache.backend.null';
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';

/**
* Enable local development services.
*/
$settings['container_yamls'] = DRUPAL_ROOT . '/sites/development.services.yml';

/**
* Enable access to rebuild.php.
*/
$settings['rebuild_access'] = TRUE;



And finally, our /sites/development.services.yml (in version control) file contains this:


/sites/development.services.yml


# Local development services.
#
# To activate this feature, follow the instructions at the top of the
# 'example.settings.local.php' file, which sits next to this file.
parameters:
http.response.debug_cacheability_headers: true
twig.config:
debug: true
auto_reload: true
cache: false
services:
cache.backend.null:
class: DrupalCoreCacheNullBackendFactory



This has worked really well for us.



You need to set the cache option to true on your development.services.yml file.
Something like this:


cache


development.services.yml


services:
cache.backend.null:
class: DrupalCoreCacheNullBackendFactory
parameters:
twig.config:
debug: true
auto_reload: true
cache: true



After you clear your cache and open some pages that you want to debug you will see that in files/php/twig some .php files will be created, like the bellow image:


files/php/twig


.php



twig-debug



on these pages will can debug normally as you debug a .php file.


.php



There is a article on the Acquia blog that help you make this configuration and debug using Xdebug and the PhpStorm IDE that you can on the link Debugging TWIG templates in Drupal 8 with PhpStorm and XDebug



Twig Debuggin wasn't working as expected, I did all the thing you did and it didn't work. So I searched for debug:false in all the site and found this file: core/core.services.xml



I changed the values there and it worked!



It's not a good way to do this because we are modifying the core, but It will help someone with this problem!






By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Popular posts from this blog

Firebase Auth - with Email and Password - Check user already registered

Dynamically update html content plain JS

How to determine optimal route across keyboard