Problem/Motivation

Is there any reason why development.services.yml does not disable TWIG cache by default? Every core update overrides this file with the default one. Themers routinely set those 3 lines, but this is a repetitive task. And the file loads only when settings.local.php is included, so it will not cause any problems on production sites.

Proposed resolution

Add the twig.config related lines to development.services.yml, under parameters: key:

  twig.config:
    debug: true
    auto_reload: true
    cache: false

So the whole file will look like this:

# 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: Drupal\Core\Cache\NullBackendFactory
Members fund testing for the Drupal project. Drupal Association Learn more

Comments

gpap created an issue. See original summary.

gpap’s picture

Issue summary: View changes
gpap’s picture

Thew’s picture

I agree with you. I need to add it manually every time I get the fresh installation.

Maybe add the twig parameters to development.services.yml and comment it out.
If themers want it, he can remove the comment, like Disable the render cache in example.settings.local.php.

# 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: Drupal\Core\Cache\NullBackendFactory

However, if my thought is right, you can only set debug: true. The auto_reload and cache will automatically follow the debug parameter. See Debugging compiled Twig templates

binoli.addweb’s picture

Status: Active » Needs review
FileSize
492 bytes

Please apply disable_twig_cache_by-2839709-5.patch.

Cottser’s picture

Status: Needs review » Needs work

Thanks for the suggestion. I'm not sure if this was discussed before, there may have been a reason to not include it. Enabling twig debug can have side effects, because of the HTML comments added. For example, #2656728: Twig split in debug mode. Enabling auto_reload for development should be safe though.

Disabling twig cache in my experience has no benefits, only downsides:

  1. Harder to debug compiled templates because they aren't saved to disk.
  2. Templates need to be compiled each time no matter what, slowing things down.

See https://github.com/hechoendrupal/drupal-console/pull/1310 from the Drupal Console project where something similar came up.

Version: 8.3.x-dev » 8.4.x-dev

Drupal 8.3.0-alpha1 will be released the week of January 30, 2017, which means new developments and disruptive changes should now be targeted against the 8.4.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

joelpittet’s picture

I'm on board with the this except cache like @Cottser mentioned in #6. And with debug on, auto_reload is on by default so doesn't need to be added, though that's not too much a concern.

Would you mind removing those from the patch @binoli.addweb?

drupalmonkey’s picture

Updated the patch as per #9.

Version: 8.4.x-dev » 8.5.x-dev

Drupal 8.4.0-alpha1 will be released the week of July 31, 2017, which means new developments and disruptive changes should now be targeted against the 8.5.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.

vaplas’s picture

#9 looks ok, thanks! But #6 also makes sense.

What if we add these lines with comment? This will help not to find the examples of disabling twig cache, just uncomment lines.
And this will help to prevent an incorrect insertion of one more parameters:. Because after #2827047: Add http.response.debug_cacheability_headers: true to development.services.yml it is not works, but still as recommended in many tutorials.

I am also in favor of saving the auto_reload, since it will be easier to set 'false' if desired.

vaplas’s picture

Status: Needs work » Needs review
jwilson3’s picture

Title: Disable TWIG cache by default in development.services.yml » Enable Twig debug by default in development.services.yml
FileSize
426 bytes
1.65 KB
496 bytes
1.7 KB

Updating title to reflect the last point on comment #4.

I'm in favor of putting these values into the development.services.yml file as well as having commented out versions of twig_auto_reload and twig_cache. But I also think that this is sufficiently confusing that we should include some of the documentation from Debugging Complied Twig Templates inline for immediate reference and warning (see patch 13b).

Here are two patches, one with and one without documentation, for your consideration.

Also please be aware that making this change, will make our documentation more complex for front end developers. The reason is that it will be more complex than simply adding a couple lines to services.yml file (per current documentation).

1) Copy example.settings.local.php to settings.local.php
2) Uncomment the line in settings.local.php that enables development.services.yml
3) Confirm that parameters.twig.debug is set to true in development.services.yml and that the line is not commented out.

Furthermore, we'll possibly need a change notice. Any front end developer that has been putting these settings in services.yml as per the current documentation page suggests, but then also has development.services.yml enabled (either unwittingly, or from instructions from a backend developer) will not know that the values in services.yml will now be overridden by those in development.services.yml, creating confusion. (Anecdotally, this just happened to a front-end developer on our team last week after a backend dev hardcoded debug: false in development (!!!) the debug: true in services.yml was being ignored completely, causing some moments of confusion).

Here are three documentation pages that mention this that I know of, there may be more:

https://www.drupal.org/docs/8/theming/twig/debugging-twig-templates
https://www.drupal.org/docs/8/theming/twig/debugging-compiled-twig-templ...
https://www.drupal.org/node/2598914

AdamPS’s picture

Status: Needs review » Needs work

I have created a META issue to list all of the known problems of twig debug: #2914733: [META] twig debug can break parts of site.

  • I propose that we link to this from development.services.yml.
  • Given so many potential problems I wonder if we really ought to turn twig debug on by default. Perhaps we should instead turn auto_reload on by default and have the line for twig_debug present but commented out?

A secondly benefit of the direction this issue is taking us is that we can subsequently use development.services.yml to solve some of these issues. For example to solve #2796453: RSS output not valid when using Twig debug, there could be a new response_filter.rss.twig_debug and class RssResponseTwigDebugFilter implements EventSubscriberInterface that fixes the feed by moving the comments after the xml tag.

AdamPS’s picture

On reflection I feel that we should avoid commented out lines in development.services.yml. That file is shipped in Drupal core and gets overridden every upgrade, so users should not be editing it. Instead I suggest:

  • Add twig auto_reload to development.services.yml
  • New file twig-debug.services.yml sets twig debug and in future could have extra lines to workaround bugs that introduces
  • example.settings.local.php contains a commented out line to include twig-debug.services.yml
  • As already documented, users would copy example.settings.local.php to settings.local.php. They can then uncomment the line - which is safe because they are not editing a delivered file.
willthemoor’s picture

Wondering if a better longer(ish) term move might be to (automagically) allow for development.services.local.yml (or is it local.development.services.yml)? That is, Drupal would use it if available instead of needing to go to a settings file an uncomment.

Then a user can create it and it could be .gitignored. As it is now, using this on teams is a little squirrelly.

Version: 8.5.x-dev » 8.6.x-dev

Drupal 8.5.0-alpha1 will be released the week of January 17, 2018, which means new developments and disruptive changes should now be targeted against the 8.6.x-dev branch. For more information see the Drupal 8 minor version schedule and the Allowed changes during the Drupal 8 release cycle.