Make it easier for theme builders to enable Twig debugging and disable render cache

I think this issue is very similar to #1969278: UI for enabling twig debugging

Huge +1 on this:

+1

I actually talked to @lauriii about this, and he seemed really on board with this idea too!

I also like the idea of having a UI to turn on and turn off.

Let me know what I can do to help!

This isn't directly accomplished now by using sites/example.settings.local.php, but there's overlap. Not suggesting we expand scope here, but perhaps that file will need to be adjusted to acknowledge this new feature.

Would it be a bad practice/poor DX to have multiple avenues of activation? While a simple checkbox in performance would be great, as would a one-liner in settings.php, I could also see agencies liking the idea of an environment variable so that dev servers could just have all sites in dev mode all the time.

Also, would having the setting in config have any kind of tangible performance hit versus settings.php/environment variable?

Would it be a bad practice/poor DX to have multiple avenues of activation?

Yeah, if we were starting from scratch. And this is definitely something we need to consider for the DX.

However, keeping the activation of the debugging/cache as it is, is very bad DX. I'm not sure we can or should remove the old method.

A UI switch would be ideal for this, especially if it's tied to an environmental variable or something that would keep it from activating on a production environment. It would make the experience much easier for someone unfamiliar with Drupal who's trying to get started and be much easier for everyone else to do as part of the process.

Another, less friendly option, would be to just have devlopment.services.yml updated so that it has the twig debug settings already in there. This would at least mean that the option would already be there, similar to how example.settings.local.php has everything needed in there already it's just up to the user to uncomment what they want. Doing that would at least mean that the user wouldn't have to go find what the options they need to add in.

Generally, though, this seems like the kind of functionality that should be a single-step option to enable. The current process is definitely not beginner-friendly and if something is missed or incorrectly entered, the user can get pretty frustrated trying to figure out what was missed. I know this from my experience first learning Drupal right when D8 was coming out.

Thank you for raising this @mglaman! This would be a huge improvement in DX. I'd go so far as to say that Drupal should give a warning when it recognizes that Twig debug is enabled but cache (page cache/dynamic page cache/render) is not disabled! I've been burned by that more times than I'd like to admit ;)

+1 that would be nice and we should open a follow up ticket.

@mglaman Based on your suggestion I created that issue: https://www.drupal.org/project/drupal/issues/3278887

Would it be possible to also remove development.services.yml from Drupal's default scaffolding?

The issue #3278887: Update development.services.yml to include twig debug by default would help a lot of people, but the problem remains that any development service customizations will be overwritten with every composer require/update/install. If a site has made a customization to the CORS config, for example, they'll also need to make sure they disable the scaffolding for that file or it'll soon be reset to its default state.

We don't overwrite settings.php or settings.local.php, so why should we be overwriting development.services.yml?

Is this a duplicate of #2839709: Make Debugging Twig easier ?

The approach there lets us get the benefits of turning on twig auto_reload for all developers in development.services.yml, while leaving Twig debug off by default, and enabling it via a separate services file (by uncommenting a line of code in settings.local.php). The reason we took this approach is because twig debug can break some websites, whereas auto_reload has no drawbacks.

Thanks @jwilson3. The problems with twig debug are listed in #2914733: [META] twig debug can break parts of site.

I have created two test patches that if theme_debug is set not on the file system the configuration that is managed by core/modules/system/src/Form/ThemeAdminForm.php is used. The image below gets the twig.debug.debug_setting configuration created by the form through the Drupal UI and then sets the twig.config debug to true or false.

Updated to the two patches so they will pass the automated testing.

Here's a contrib module that seems to add the same functionality https://www.drupal.org/project/twig_debugger

mostly though it works by writing default.services.yml which might actually just destroy your site :-/

@neclimdul Twig debugger module as got a config form where we can enable twig debugging by ticking the checkbox and saving the form, where it will create a new file called services.yml and copy default.services.yml's file into it.

And in services.yml for now we have just manually done debug: true, auto_reload: true, cache: false, but we can also provide users expose these 3 keys by giving users to toggle these 3 keys in form, I have thought about it and will be pushing it in next release. Not sure if this is the right way to play with drupal sites folders and files.

This is absolutely lovely but have we considered storing this in session instead of config? Would need some thought for anonymous but I wanted to float the idea.

I created a new MR, based on previous work from mglaman, implementing the following approach:

- A checkbox to enable and disable the theme debug mode is added to `/admin/appearance/settings`.
- The checkbox value is stored in Drupal's state, so no changes are generated when configuration is exported.
- In form submit, when the value is changed only, caches are cleared for debug mode to be enabled/disabled immediately.
- The value stored in Drupal's state can be overridden from settings.php file by setting a boolean variable named $settings['theme_debug']. When this variable is set, the checkbox is disabled to avoid confusion about what the expected behavior is.
- Added the test from comment #19 with some minor changes.
- A warning is displayed in `/admin/reports/status` when the theme debug mode is enabled.

Did some in-person review at DrupalCon Prague and there are a couple issues:

1. The form field gets added to the global theme settings as well as all installed themes' settings pages. This is not desirable. I'm of the opinion that this checkbox should live in the same form as the caching & aggregation settings as mglaman pointed out in #6
2. The checkbox doesn't run on my machine - @alexpott helped debug this and points out that we need to move the functionality added in the coreserviceprovider to the alter function to have it run as late as possible.

Following 8a5c49fb this functionality works beautifully

1. Start with a site not in debug mode
   
2. Check the box
   
3. Save the form
4. Wait for page reload
5. profit.
   
   

I don't have the skillset to do an analytical code review, but I can say with certainty that frontend devs around the world are going to LOVE this.

Thank you @andy-blum and @alexpott for your help! I have added a new commit to move the checkbox from the Theme settings form to the Performance form.

.

Great that this issue is active and making progress. I have commented already on #2839709: Make Debugging Twig easier. This issue is seemingly taking over, with the advantage of adding a GUI so I'll make the same comments here.

There are 3 relevant Twig settings:

1. auto_reload: always useful in development
2. debug: often useful, but causes major bugs on some sites, see #2914733: [META] twig debug can break parts of site
3. cache: should always be enabled even in development. This setting is already enabled by default so no changes are needed.

I suggest we could usefully use the same approach adopted in the other issue, and allow twig:debug to be controlled separately. So there would be a checkbox "enable debug", and if this is set, another checkbox "twig debug", which defaults to enabled, but can be disabled if needed. There can be a warning about the possible problems in the field description.

What do people think?

Personally, I don't think a GUI is needed to change one single config. It should be a one-line code change in settings.local.php (hence the other issue), but I'm biased towards low-code solutions and small core.

Even Matt in the OP on this issue mentioned the Proposed Solution:

I think it belongs in settings.php since it's easier to have local overrides there. Drupal doesn't have out-of-the-box local site service definitions.

At the very least the approach on the PR on this issue needs an IS update.

Personally, I don't think a GUI is needed to change one single config.

I hear what you're saying, and I'm assuming this will be changeable via the settings.php, but IMO one of the primary purposes of this is to make it easier for new-to-drupal front-enders to get up and running. Even a making a change to settings.php can sometimes be difficult.

@rabbitlair and @mglaman - thank you so much for working on this! This is really going to smooth the process for front-enders starting out w Drupal.

I'm setting this back to Needs Work because it's consistently failing tests (I re-ran them and they still failed). The failures seem like they should be unrelated, but either way we need to investigate.

I'd also like to spend a bit of time bikeshedding on the verbiage.

1. The checkbox label is currently Theme debug mode - This setting affects more items than just theming, right? Maybe we should call it "Development mode" or something?
2. The description is currently Enable theme debug mode. This option will turn Twig debug mode on, and set Null cache backend for page, dynamic_page, and render cache bins. Cache will be rebuilt after changing this setting.. I personally think we can skip saying exactly what caches are disabled, and maybe something along the line of "You can see changes in your templates without rebuilding cache", and it will show template suggestions within the HTML comments. We also need a big ol' warning that says, "DO NOT USE ON PRODUCTION!" or something :)

Thoughts on all of this? I'm really excited about this. Thank you everyone for working on it!

@adamPS brings up a good point:

There are 3 relevant Twig settings:

1. auto_reload: always useful in development
2. debug: often useful, but causes major bugs on some sites, see #2914733: [META] twig debug can break parts of site
3. cache: should always be enabled even in development. This setting is already enabled by default so no changes are needed.

We're currently setting all three of these values with a single checkbox as well as nullifying a bunch of caches. I wonder if a new fieldset with multiple checkboxes would be good to have more granular control?

Also, to @mglaman and @jwilson3's point:

I think it belongs in settings.php since it's easier to have local overrides there.

@rabbitlairs solution allows settings.php overrides and avoids using config to set the values. So there's virtually no risk of accidentally exporting the values, and a production site can always set the values how they want them in settings.php to prevent accidental usage there.

First, this is a great option that will certainly make my life easier. I'd like to add my voice to having the option exposed in all 3 places: settings.php, in the performance admin ui, and as an environment variable. Each serves the needs of a different user archetype.

I reached out to @lauriii and @mglaman on this to brainstorm. I’m updating the issue summary with a solution that we all believe works really well.

Great thanks it's a good start, but misses some important points.

1) This solution doesn't cover comment #37. I'll post that again to save people searching back:

There are 3 relevant Twig settings:

1. auto_reload: always useful in development
2. debug: often useful, but causes major bugs on some sites, see #2914733: [META] twig debug can break parts of site
3. cache: should always be enabled even in development. This setting is already enabled by default so no changes are needed.

I suggest we create two separate settings:

1. Twig debugging: enables auto loading of changed templates and the dump() function.
2. Template debug comments (only available when the first one is enabled, defaults to enabled). Needs a warning that it can breaks some parts of the site.

2) It doesn't cover comment #42 and various others also to allow control from settings.php.

3) The description in the IS of the checkbox seems wrong, see documentation).

Set this option to false to disable Twig template compilation. However, this is not recommended; not even in the dev environment, because the auto_reload option ensures that cached templates which have changed get compiled again.

The setting should enable auto_load not disable cache. I don't see any need for a relationship to the "Disable all caches" setting.

@AdamPS The thought process that was discussed with @lauriii is that the use-case of enabling only one at a time is an extreme edge-case (in fact, in all my years, I've yet to run into it). In the event that someone does need to enable only one or the other, they can do so using the current means (services.yml + settings.php)

It doesn't cover comment #42 and various others also to allow control from settings.php

The new states would still be configurable via settings.php.

The description in the IS of the checkbox seems wrong, see documentation).

Which checkbox? Caching needs to be disabled for changes in Twig templates to be immediately viewable.

Thanks for the reply.

@AdamPS The thought process that was discussed with @lauriii is that the use-case of enabling only one at a time is an extreme edge-case

Well we could try to measure this quantitatively:

• This issue has 33 followers.
• #2914733: [META] twig debug can break parts of site has 21 followers, and the sub-issues have respectively 35, 21, 4, 7.

I have hit it on several sites. At least one other commenter has made the same point (so that makes 2 out of the 16 people commenting, more than 10%). If we make a GUI setting that makes it easy for people to enable twig.debug then it's likely a lot more people will hit it, and it's pretty hard to debug when it happens. The "current means" to workaround you refer to are not easy, hence this issue.

What is the big problem with splitting this out in the end? The current solution bundles 3 settings that are clearly distinct in the TWIG world, and it makes for a long description to explain because the effects are quite distinct from each other. Would it be such a bad thing to split into 2 separate settings each with a shorter description?

The new states would still be configurable via settings.php.

Great. Please this could be clarified in the IS with an example?

Which checkbox? Caching needs to be disabled for changes in Twig templates to be immediately viewable.

Currently the checkbox is called "Enable Twig Debug Mode".
No that's my point - please read the docs I linked to😃. auto_reload needs to be enabled to have this effect.

What is the big problem with splitting this out in the end? The current solution bundles 3 settings that are clearly distinct in the TWIG world, and it makes for a long description to explain because the effects are quite distinct from each other. Would it be such a bad thing to split into 2 separate settings each with a shorter description?

That's a good point. The thought is to provide a simplified UI.

Great. Please this could be clarified in the IS with an example?

I'll clarify that this needs to be available within settings.php, but we'll leave the actual code to whoever is developing this.

No that's my point - please read the docs I linked to😃. auto_reload needs to be enabled to have this effect.

In my testing and conversations, I'm not sure this is correct. If debug is enabled, the other two settings do not have an effect.

I'll reach out to @lauriii to make a decision on the points that you've discussed. I'd like to keep momentum on this issue.

Thanks @mherchel

In my testing and conversations, I'm not sure this is correct. If debug is enabled, the other two settings do not have an effect.

My recollection is that if debug is enabled then auto_reload is automatically enabled. Disabling cache is clearly documented as not recommended, so presumably we shouldn't do that.

However, this is not recommended; not even in the dev environment, because the auto_reload option ensures that cached templates which have changed get compiled again.

I think it makes sense to try to cater to #2914733: [META] twig debug can break parts of site here even though it doesn't seem like something every user would have to run into. It could even be helpful to provide an explanation in the UI that the Twig Debug mode modifies the HTML markup and may lead into different behavior from production.

I like the simplicity of a simple checkbox, but I do believe we could make the UI with two checkboxes apprehensible as well. We could potentially visualize some of this as well by hiding the auto reload checkbox when the full "Twig debug" mode is turned on.

Mark

I implemented some changes to the open MR.

A new form named "Developer settings" has been added, with its own route and menu item. It contains a checkbox, "Enable Twig debug mode", which enables the Twig "debug" flag, and two other conditional checkboxes. These are to handle Twig's "autoload" and cache disabling. The one disabling cache disables both Twig cache flag and the Drupal's page, render and dynamic page caches.

The three options can also be overridden from settings file. Please, let me know if this implementation works better!

Coming here to find a way to disable auto_reload, which seems to be automatic while debug is set to 'true'.
I understand that in most case it is useful, but from a theming side it is NOT ALWAYS the case and I would like to have the option to disable it. (If there is already a way, could someone please let me know). In case if we are using Vite.js to compile the theme, auto_reload is unnecessary and time consuming.

@sahaj you can set debug to true and auto_reload to false if you want debug but not auto_reload.

The behaviour is that if auto_reload is not specified, then it inherits the value of debug.

Great work, this will be a nice improvement. Could the same be done for core and module development, so that all caches can eventually be easily disabled, via the GUI or running a single command such as drush cache:disable? #3342678: Easy way to bypass caching and aggregation with Drush or settings.php.

Re-rolled the MR and created a patch (since MR is against 10.0.x and Zequi is probably sleeping)

Great to see this moving forward thanks everyone. The issue summary seems to be getting increasingly left behind.

1)

Moved settings to Performance from Developer settings.

I can see your point, as previously there was "Admin > Config > Development > Developer Settings" - and what's the difference between development settings and developer settings😃.

On the other hand we now seem to have "Admin > Config > Development > Performance" and then a details box titled "Developer settings", which still doesn't seem quite right. How about reorganising the Performance page something like this:

• Rename "Caching" to "Web Caching"
• New section "Internal Caching" or "Cache Bins" (or whatever the right name is). Module caches could later be added here as per #56
• New section "Twig" containing the 3 checkboxes

2) Two of your four settings are "disable XXX" rather than "enable XXX" - potentially this negation is a confusing UI??

3) It would be great to have warnings in the form UI for the two settings that have potential disadvantages:
twig_debug: This modifies the HTML markup and may lead into different behavior from production, even causing bugs.
cache: This is recommended; even in the dev environment, because the auto_reload option ensures that cached templates which have changed get compiled again.

4) The patch seems to save the new values to state rather than config, which seems unusual and potentially confusing. I understand that the values are likely to be different on dev vs production. However that's also true for many of the other development settings. What is the advantage to this approach?

5) The code seems to invalidate the container if any value is enabled. Shouldn't this be if any value has changed?

Thanks for the responses @mglaman

I think it should link to official docs, because they'll stay up to date

Great - the wording was from the docs anyway

@mherchel informed me about twig debug adding HTML comments which breaks RSS feeds. So there are edge cases and this is best handled in guides.

It's funny how many people who haven't hit this themselves say that it's an edge case😃. It's not only RSS, please see #2914733: [META] twig debug can break parts of site (which when counting together all the child issues has more followers than this one😃).

@lauriii commented in #51

It could even be helpful to provide an explanation in the UI that the Twig Debug mode modifies the HTML markup and may lead into different behavior from production.

It can save people some trouble so I wonder is there any significant disadvantage???

Did some hallway testing at MidCamp with front-end devs @hbrokmeier, @callinmullaney, @mndonx (crediting).

We worked on verbiage and expectations:

• Rename the “Performance” page title (and menu entry) to “Performance and caching”
• Change the new details label to “Theme development settings”
• Directly within the new details element add this text:
  • These settings should only be enabled on development environments and never on production.
• For caching description text:
  • Change label: Do not cache markup
  • Change description: Disables render cache, dynamic page cache, and page cache.
• Use case. If we rebuild the environment, we don’t want to have to re-check this form. Can we override these settings in settings.php or have a drush command?

I looked at this issue with M&M at MC (@mherchel and @mglaman at MidCamp 2023). What is the best way to present the options under "Twig development mode"?

The options "Enable Twig auto reload" and "Disable Twig cache" are not independent, so it does not make sense to have a checkbox for each. If I have it straight, the first option invalidates the cache if it is older than the source, and the second option completely bypasses caching. Instead of two checkboxes, I think there should be three radio buttons:

• Normal caching
• Cache, but recompile changed templates
• No caching

I also reviewed the current labels and descriptions:

- [ ] Enable Twig debug mode
Enables Twig debug mode, which provides Twig's dump() function, outputs template suggestions to HTML comments, and allows to set Twig auto reload and to disable caches.
- [ ] Enable Twig auto reload
When enabled, Twig templates are recompiled when the source code changes.
- [ ] Disable Twig cache
Disables Twig template cache.

It is confusing to use "Enable" and "Disable" for checkboxes. We should avoid repeating the label in the description. We do not need a description at all if it just repeats the label. I came up with some alternative text:

- [ ] Show debug information in HTML comments
Show template suggestions in HTML comments and provide Twig's dump() function.
- [ ] Recompile changed templates
- [ ] Bypass template cache

Maybe remove "in HTML comments" from the first label.

The last option on the page is

- [ ] Disable cache bins for rendered output
Disables render cache, dynamic page cache, and page cache to bypass caching during rendering.

I suggest changing that to

- [ ] Do not cache markup
Disables render cache, dynamic page cache, and page cache.

I talked about this issue at MidCamp with @akalata and Jen Stein (not sure of the d.o username). We agreed that the UI should have three radio buttons, and we recommend this:

• Cache Twig templates normally
• Autoload Twig templates
  • Cache, but recompile changed templates
• Do not cache templates

(That is, the middle option is the only one that needs description/help text.) Probably the middle option should be selected by default when "Twig development mode" is enabled.

I talked about this issue at MidCamp with @akalata and Jen Stein (not sure of the d.o username). We agreed that the UI should have three radio buttons, and we recommend this:

The issue with this option is that it doesn't give the granularity of enabling and disabling the 3 options, as pointed out in #37 by @adamPS and +1'd by @lauriii in #51

Adding credit for @akalata's discussion with @benjifisher.

Pretty sure Jen Stein isn't on Drupal.org. I found her on MidCamp's site, but not here.

Verbiage changes

I am afraid I was not clear in #74.

There are currently three checkboxes:

• Twig debug mode
• Twig auto reload
• Disable Twig cache

I meant to suggest that we keep the first one and replace the other two with three radio buttons.

That reduces 4 options to 3. The one we leave out is disabling the second option and enabling the third. That combination does not make much sense: see #72. Anna, Jen, and I think this is a better UI than the suggestion at the end of #51:

We could potentially visualize some of this as well by hiding the auto reload checkbox when the full "Twig debug" mode is turned on.

Adding a missing comma

Let me see if I can help a little here.

If I read it correctly, PHPStan is complaining that you are telling it to ignore some lines that do not have any problems. So this patch removes the @phpstan-ignore-next-line annotations.

I am a little unsure, since core/scripts/dev/commit-code-check.sh passes locally with or without those annotations.

Worked with @ckrina (UX Maintainer) and @mglaman on a Zoom call to nail down the user interface. For any additional improvements, please open up a followup issue.

On admin/config, this item will go directly under “Performance”

This form will go under admin/config/development/settings. The title of the page and menu item is “Development settings”

When “Twig development mode” checkbox is checked, both checkboxes within the child fieldset are checked by default.

Note that we removed the Twig auto-reload setting, as when Twig debug mode is enabled, this will automatically get enabled. This is the most common development setting for new developers. For more advanced configuration, changes can still be made in development.services.yml

Note we will open up a followup issue to provide a indication in the UI if settings are overridden.

This is a huge improvement for front-end DX, thanks for working on this!

The form doesn't tell the user that the changes have been saved.

Matt's going for a run. Updating the patch to fix 👆

No clue if this is correct. Let's find out! 🤞

As a sort of test-only patch for #3358048 and to see how much closer we are, here's #95 and the MR from #3358048 applied together. Interdiff is https://git.drupalcode.org/project/drupal/-/merge_requests/3920.diff ;)

core/scripts/dev/commit-code-check.sh --cached now passing. 😅 Sorry for the noise.

I wanted to compare #95 with #98 to prove that we should commit #3358048: Do not use persist tag for keyvalue.memory in KernelTestBase, so I queued the test run. Sadly, that failed for the unused use. So here's just #95 after running phpcbf to make core/scripts/dev/commit-code-check.sh happy. This will definitely still fail. Hopefully more like #90 than #98. 🤞

Updating issue summary.

+++ b/core/lib/Drupal/Core/DependencyInjection/Compiler/DevelopmentSettingsPass.php
@@ -0,0 +1,41 @@
+    /** @var \Drupal\Core\State\StateInterface $state */
+    $state = $container->get('state');

This is the reason that we needed to do #3358048: Do not use persist tag for keyvalue.memory in KernelTestBase. I think this is wrong. We can't use service in compiler passes. That's really really fraught. I think we should have left #3358048: Do not use persist tag for keyvalue.memory in KernelTestBase alone. This change will result in all KernelTests now using the database for state because it results in the instantiation of the state service prior to \Drupal\KernelTests\KernelTestBase::register() running.

We need to do something different here.

+++ b/core/modules/system/system.install
@@ -1532,6 +1532,24 @@ function (callable $hook, string $module) use (&$module_list, $update_registry,
+    $twig_debug = \Drupal::state()->get('twig_debug', FALSE);
+    $twig_cache_disable = \Drupal::state()->get('twig_cache_disable', FALSE);
+    if ($twig_debug || $twig_cache_disable) {
+      $requirements['twig_debug_enabled'] = [
+        'title' => t('Twig development mode'),
+        'value' => t('Twig development mode settings are turned on. Go to @link to disable them.', [

Since enabling the "Twig development mode" checkbox adds a Warning message to status report page, and "Do not cache markup" is also being introduced as a separate, top-level checkbox alongside Twig development mode, and both of these can be detrimental to website performance on production/live sites, it seems it would follow that we should also have a separate Warning message when "Do not cache markup" checkbox is enabled, right?

This is something I've wanted for years. The fact that it wasn't in core made me think there was some huge obstacle but this is a really solid way of doing it.

Outside of what has been reported, here's the one whole thing I noticed in my review:

+++ b/core/modules/system/system.install
@@ -1532,6 +1532,24 @@ function (callable $hook, string $module) use (&$module_list, $update_registry,
+  // Add warning when twig debug option is enabled.

Could this get test coverage? TBH not concerned about it working right in this scope, but more to ensure some later addition doesn't break it.

@mglaman so why was the change in #3358048: Do not use persist tag for keyvalue.memory in KernelTestBase necessary - what is the root cause? My guess is that persistence is done at a different time. Ah yep \Drupal\Core\DrupalKernel::attachSynthetic() is called after everything is compiled. Should have read #93 - thanks @mglaman

I wish we'd added a bigger comment in #3358048: Do not use persist tag for keyvalue.memory in KernelTestBase :) but I can open an issue for that. I agree with @mglaman that accessing the db here through state is probably okay. We also probably should use the PassConfig::TYPE_AFTER_REMOVING etc... more in CoreServiceProvider::register() - nearly all of our stuff is being added as an optimisation pass when everything should run after the removing pass. I consider #106 resolved.

Re: #112: Here you go. 😉 #3358328: Improve how KernelTestBase manages its persistent key value storage

Using a fresh install on D10.1 without a settings.local.php file and with a default development.services.yml file.

1.
Unchecked Twig development mode
Checked Do not cache markup

Went to /admin/reports/status
Verified I see "Markup caching disabled
Render cache, dynamic page cache, and page cache are bypassed. Go to development settings page to enable them."

Unchecked Do not cache markup
Verified warning in status page goes away.

2.
Before checking Twig development mode verified that debug info is not appear in markup
Checked Twig development mode
But didn't check any sub items.
Clicking save doesn't save Twig development mode
Seems expected but slightly odd. But don't think a show stopper

3.
Checked Twig development mode
Checked Twig debug mode
Did not check Disable Twig cache
Clicked save
Twig development mode is unchecked BUG
Inspect the markup and debug info is appearing.
Go to status page verify I see "Twig development mode
Twig development mode settings are turned on. Go to development settings page to disable them."

4.
Checked Twig development mode
Checked Twig debug mode
Checked Disable Twig cache
Clicked save
Twig development mode is checked
Inspect the markup and debug info is appearing

Test coverage seems good.
Other then that one small point think this is good to go.

And as posted in slack a change record should be made.

Good catch. Fixed in this patch.

Change record created at https://www.drupal.org/node/3359728

Issue I found in #115 has been addressed.

Tested this using the standard profile, with olivero:

• Visit homepage with caching fully enabled (ie: nothing checked) - warms cache
• Visit /admin/config/development/settings Check the do not cache markup checkbox / save
• Update a twig template used on the homepage (I updated core/themes/olivero/templates/layout/html.html.twig)
• View homepage, confirm new change appears with no cache clear
• Visit /admin/config/development/settings Uncheck the do not cache markup checkbox / save
• View homepage, note old cached version before the change appears

I would expect the new version, is that an issue?

I gave the patch a thorough review and it looks solid. Also the UX is pretty good. I made super minor nitpick changes to the patch. Posting just to make sure custom commands pass.

I think the UI texts in the patch are fine but I'm still planning on creating a follow-up to bikeshed some of the texts.

#120: That's interesting. Maybe worth fixing in a follow-up because you'd have the same behavior right now 🤔

Committed da2eaec and pushed to 10.1.x. Thanks!

Adding release note.

@crasx / #120 - that's a smart comment. I agree with @lauriii that we can address that in a follow-up.

Here’s the follow-up I filed: #3359859: Improve UI texts for Twig development settings

I observed this:

+++ b/core/modules/system/src/Form/DevelopmentSettingsForm.php
@@ -0,0 +1,152 @@
+      '#description' => $this->t('Disables render cache, dynamic page cache, and page cache.'),

Über nit… 🙈

s/dynamic page cache/Dynamic Page Cache/

s/page cache/Page Cache/

… because they're module names? That's also how they're capitalized in example.settings.local.php.

OTOH I like this better … because then it's consistent with "render cache". Maybe we should just lowercase them everywhere instead?

Moved to that follow-up. 👍

Yay for getting this in! I just added #3359931: Latest/real markup should be used when caches are enabled as a followup per #120.

@mherchel,
Tracked down Jen Stein's username: jen.stein

Crediting. Thanks!

Thanks everyone, this is an awesome improvement. I just used it to try the New clean_unique_id Twig filter in Drupal 10.2 (11), and it worked flawlessly.

@mherchel suggested at one point, which I agree with:

Use case. If we rebuild the environment, we don’t want to have to re-check this form. Can we override these settings in settings.php or have a drush command?

So I created #3363676: Enable Twig debugging and disable render cache via Drush and settings.php.

I'm late to the party, but don't you think that having a dedicated checkbox to expose another two checkboxes looks a bit weird from the UX perspective? That also made the logic in the form much more complex.

I created Add Drush command to toggle Twig debugging and CSS/JS aggregation #6267.

@keshav patel created a Drush command (theme:dev) which toggles Twig debugging, caching and aggregation, included in the latest Drush 13.6 release. See also Drupal Documentation page Disabling and debugging caching > Toggle Twig debug, caching and CSS/JS aggregation with Drush.