Update: I've realized that neither my settings nor settings.local files are doing anything. I placed die() and print statements throughout both files, rebuilt cache, and see nothing. I'm stumped.

Update 2: I added the output from ddev drush status at the bottom of the post

Default Drupal 10 site built by Pantheon. The only thing I've done besides setting up these files was update the permission for settings.php and services.yml

chmod 644 sites/default/settings.php
chmod 444 sites/default/services.yml

Banging my head against the wall on this. I can't seem to get twig debugging of any kind working, even going directly into my services.yml file and switching it to true.

I've looked through the drupal and ddev docs and what I can find on google, fiddled with all of the following files, rebuilt cache, restarted DDEV, etc. I can't seem to get it working.

I'm using a Mac, if that matters.

Any help is greatly appreciated. Here is my 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.
  http.response.debug_cacheability_headers: true
    debug: true
    auto_reload: true
    cache: false
    class: Drupal\Core\Cache\NullBackendFactory

in my sites/default folder:



 * Load services definition file.
$settings['container_yamls'][] = __DIR__ . '/services.yml';

 * Include the Pantheon-specific settings file.
 * n.b. The settings.pantheon.php file makes some changes
 *      that affect all environments that this site
 *      exists in.  Always include this file, even in
 *      a local development environment, to ensure that
 *      the site settings remain consistent.
include __DIR__ . "/settings.pantheon.php";

 * Skipping permissions hardening will make scaffolding
 * work better, but will also raise a warning when you
 * install Drupal.
 * https://www.drupal.org/project/drupal/issues/3091285
// $settings['skip_permissions_hardening'] = TRUE;

 * If there is a local settings file, then include it
$local_settings = __DIR__ . "/settings.local.php";
if (file_exists($local_settings)) {
  include $local_settings;

// Automatically generated include for settings managed by ddev.
$ddev_settings = dirname(__FILE__) . '/settings.ddev.php';
if (getenv('IS_DDEV_PROJECT') == 'true' && is_readable($ddev_settings)) {
  require $ddev_settings;



 * @file
 * #ddev-generated: Automatically generated Drupal settings file.
 * ddev manages this file and may delete or overwrite the file unless this
 * comment is removed.  It is recommended that you leave this file alone.

$host = "db";
$port = 3306;
$driver = "mysql";

// If DDEV_PHP_VERSION is not set but IS_DDEV_PROJECT *is*, it means we're running (drush) on the host,
// so use the host-side bind port on docker IP
if (empty(getenv('DDEV_PHP_VERSION') && getenv('IS_DDEV_PROJECT') == 'true')) {
  $host = "";
  $port = 49474;

$databases['default']['default']['database'] = "db";
$databases['default']['default']['username'] = "db";
$databases['default']['default']['password'] = "db";
$databases['default']['default']['host'] = $host;
$databases['default']['default']['driver'] = $driver;
$databases['default']['default']['port'] = $port;

$settings['hash_salt'] = 'REMOVED FOR SECURITY';

// This will prevent Drupal from setting read-only permissions on sites/default.
$settings['skip_permissions_hardening'] = TRUE;

// This will ensure the site can only be accessed through the intended host
// names. Additional host patterns can be added for custom configurations.
$settings['trusted_host_patterns'] = ['.*'];

// Don't use Symfony's APCLoader. ddev includes APCu; Composer's APCu loader has
// better performance.
$settings['class_loader_auto_detect'] = FALSE;

// Set $settings['config_sync_directory'] if not set in settings.php.
if (empty($settings['config_sync_directory'])) {
  $settings['config_sync_directory'] = 'sites/default/files/sync';

// Override drupal/symfony_mailer default config to use Mailhog
$config['symfony_mailer.mailer_transport.sendmail']['plugin'] = 'smtp';

// Enable verbose logging for errors.
// https://www.drupal.org/forum/support/post-installation/2018-07-18/enable-drupal-8-backend-errorlogdebugging-mode
$config['system.logging']['error_level'] = 'verbose';

finally, settings.local.php:


// phpcs:ignoreFile

 * @file
 * Local development override configuration feature.
 * To activate this feature, copy and rename it such that its path plus
 * filename is 'sites/default/settings.local.php'. Then, go to the bottom of
 * 'sites/default/settings.php' and uncomment the commented lines that mention
 * 'settings.local.php'.
 * If you are using a site name in the path, such as 'sites/example.com', copy
 * this file to 'sites/example.com/settings.local.php', and uncomment the lines
 * at the bottom of 'sites/example.com/settings.php'.

 * Assertions.
 * The Drupal project primarily uses runtime assertions to enforce the
 * expectations of the API by failing when incorrect calls are made by code
 * under development.
 * @see http://php.net/assert
 * @see https://www.drupal.org/node/2492225
 * It is strongly recommended that you set zend.assertions=1 in the PHP.ini file
 * (It cannot be changed from .htaccess or runtime) on development machines and
 * to 0 or -1 in production.
 * @see https://wiki.php.net/rfc/expectations
assert_options(ASSERT_ACTIVE, TRUE);
assert_options(ASSERT_EXCEPTION, TRUE);

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

 * Show all error messages, with backtrace information.
 * In case the error level could not be fetched from the database, as for
 * example the database connection failed, we rely only on this value.
$config['system.logging']['error_level'] = 'verbose';

// Enable Twig debugging.
$settings['twig_debug'] = TRUE;

 * Disable CSS and JS aggregation.
$config['system.performance']['css']['preprocess'] = FALSE;
$config['system.performance']['js']['preprocess'] = FALSE;

 * Disable the render cache.
 * Note: you should test with the render cache enabled, to ensure the correct
 * cacheability metadata is present. However, in the early stages of
 * development, you may want to disable it.
 * This setting disables the render cache by using the Null cache back-end
 * defined by the development.services.yml file above.
 * Only use this setting once the site has been installed.
$settings['cache']['bins']['render'] = 'cache.backend.null';

 * Disable caching for migrations.
 * Uncomment the code below to only store migrations in memory and not in the
 * database. This makes it easier to develop custom migrations.
# $settings['cache']['bins']['discovery_migration'] = 'cache.backend.memory';

 * Disable Internal Page Cache.
 * Note: you should test with Internal Page Cache enabled, to ensure the correct
 * cacheability metadata is present. However, in the early stages of
 * development, you may want to disable it.
 * This setting disables the page cache by using the Null cache back-end
 * defined by the development.services.yml file above.
 * Only use this setting once the site has been installed.
$settings['cache']['bins']['page'] = 'cache.backend.null';

 * Disable Dynamic Page Cache.
 * Note: you should test with Dynamic Page Cache enabled, to ensure the correct
 * cacheability metadata is present (and hence the expected behavior). However,
 * in the early stages of development, you may want to disable it.
$settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null';

 * Allow test modules and themes to be installed.
 * Drupal ignores test modules and themes by default for performance reasons.
 * During development it can be useful to install test extensions for debugging
 * purposes.
# $settings['extension_discovery_scan_tests'] = TRUE;

 * Enable access to rebuild.php.
 * This setting can be enabled to allow Drupal's php and database cached
 * storage to be cleared via the rebuild.php page. Access to this page can also
 * be gained by generating a query string from rebuild_token_calculator.sh and
 * using these parameters in a request to rebuild.php.
$settings['rebuild_access'] = TRUE;

 * Skip file system permissions hardening.
 * The system module will periodically check the permissions of your site's
 * site directory to ensure that it is not writable by the website user. For
 * sites that are managed with a version control system, this can cause problems
 * when files in that directory such as settings.php are updated, because the
 * user pulling in the changes won't have permissions to modify files in the
 * directory.
$settings['skip_permissions_hardening'] = TRUE;

 * Exclude modules from configuration synchronization.
 * On config export sync, no config or dependent config of any excluded module
 * is exported. On config import sync, any config of any installed excluded
 * module is ignored. In the exported configuration, it will be as if the
 * excluded module had never been installed. When syncing configuration, if an
 * excluded module is already installed, it will not be uninstalled by the
 * configuration synchronization, and dependent configuration will remain
 * intact. This affects only configuration synchronization; single import and
 * export of configuration are not affected.
 * Drupal does not validate or sanity check the list of excluded modules. For
 * instance, it is your own responsibility to never exclude required modules,
 * because it would mean that the exported configuration can not be imported
 * anymore.
 * This is an advanced feature and using it means opting out of some of the
 * guarantees the configuration synchronization provides. It is not recommended
 * to use this feature with modules that affect Drupal in a major way such as
 * the language or field module.
$settings['config_exclude_modules'] = ['devel', 'stage_file_proxy'];

ddev drush status:

Drupal version   : 10.1.2                                     
Site URI         : https://evan-poe-drupal-showcase.ddev.site 
DB driver        : mysql                                      
DB hostname      : db                                         
DB port          : 3306                                       
DB username      : db                                         
DB name          : db                                         
Database         : Connected                                  
Drupal bootstrap : Successful                                 
Default theme    : olivero                                    
Admin theme      : claro                                      
PHP binary       : /usr/bin/php8.1                            
PHP config       : /etc/php/8.1/cli/php.ini                   
PHP OS           : Linux                                      
PHP version      : 8.1.21                                     
Drush script     : /var/www/html/vendor/bin/drush             
Drush version    :                                   
Drush temp       : /tmp                                       
Drush configs    : /var/www/html/vendor/drush/drush/drush.yml 
Install profile  : standard                                   
Drupal root      : /var/www/html/web                          
Site path        : sites/default                              
Files, Public    : sites/default/files                        
Files, Private   : sites/default/files/private                
Files, Temp      : /tmp        
  • Did you rebuild caches?
    – mona lisa
    Commented Aug 27, 2023 at 22:53
  • Yes, I've run ddev drush cr, gone into my front end site config > performance > rebuild cache, I've opened in an incog window, ran ddev restart, quit docker and restarted my machine...
    – Evan
    Commented Aug 28, 2023 at 0:18
  • Maybe drupal.org/node/3359728 interfering.
    – leymannx
    Commented Aug 28, 2023 at 18:37
  • Bro... How long has that been there?? I just enabled them and it's working!
    – Evan
    Commented Aug 28, 2023 at 18:39

1 Answer 1


Since Drupal 10.1.0 Twig debugging seems to be actived/deactivated according some settings stored in the state table: Change record.

This prevents that these settings can be accidentally committed. And it also seems that these settings take precedence over the old way of having the settings.local file load a certain services YAML with putting debug: true in twig.config.

Instead you now enable Twig debug mode either in the UI at https://example.com/admin/config/development/settings or enable it directly on the command line with Drush:

# Enable Twig debug mode in Drupal 10
drush twig:debug on && \
drush state:set disable_rendered_output_cache_bins 1 --input-format=integer  && \
drush cache:rebuild

# Disable Twig debug mode in Drupal 10
drush twig:debug off && \
drush state:set disable_rendered_output_cache_bins 0 --input-format=integer && \
drush cache:rebuild
  • So the solution (for Drupal 10.1.x) is to use the new configuration settings under /admin/config/development/settings rather than controlling dev settings in the codebase. Thanks @leymannx for the info! drupal.org/node/3359728
    – Evan
    Commented Aug 28, 2023 at 21:33
  • Drush v12.1 now has an explicit twig:debug command
    – Hudri
    Commented Oct 19, 2023 at 8:57
  • @Hudri – Ah nice!! 👌🏻 Still cache:rebuild necessary?
    – leymannx
    Commented Oct 19, 2023 at 9:24
  • 1
    Not totally sure, TBH. I first thought it is unnecessary, but I still had problem with discovery of new Twig files without drush cr. So I left it just to be safe.
    – Hudri
    Commented Oct 19, 2023 at 9:26

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.