Easy way to bypass all caching

Saw the related issue ✨ Make it easier for theme builders to enable Twig debugging and disable render cache Fixed , but it's only for theming. Perhaps a similar solution could be made for core and module development?

One problem on the wanted goal is that caching is an umbrella term here for many different things coming into play when it comes to let a Drupal install behave like "load everything from scratch as new" and it deeply depends on the capabilities of the environment. A complete root load of Drupal needs a potent server and a very increased PHP setup. And it can overload the max execution times etc. And some "rebuilds" are even not without risks. Like menu rebuilds, permission rebuilds, etc.

While I agree on the idea (thanks for the report!) I would like to let you know that many of us run their own "scripts" which bundle many of the common settings each development team prefers. Some tend to flush image caches some not, etc.

Your idea seem to lean on what Drupal console tried to achieve back in the days. But it had it flaws. First of all, people forget what it does. Second, it can cause problems in case some systems are set up different or it was not possible to reverse the setting in some scenarios where it would be better to exactly know what it does before.

All in all +1 for the report. Hope to read more thoughts on this.

Thanks for your thoughtful comment @dqd. I do agree that caching can mean a lot of different things to the individual Drypal user ... So thanks for pointing that out, and I'll update the Issue Summary to make it more precise.

The much easier Twig debugging feature added May 2023 (Thanks Mike Herchel! https://herchel.com/articles/disabling-twig-caching-just-got-helluva-lot...) partially solved this issue, making it a lot easier.

But I do think that a simple Drush command to turn on Twig debugging+disable caching and disabling CSS and JS aggregation would be nice. Essentially:

• Disable Twig Caching: Check all four checkboxes
• Disable CSS and JS aggregation: Disable both

This would cover the needs for most basic theming.

Your own home rolled scripts, bundling many of the common settings each development team prefers sounds quite interesting. If possible, feel free to share it, perhaps on a new page under https://www.drupal.org/docs/develop/development-tools → ?

Your idea seem to lean on what Drupal console tried to achieve back in the days. But it had it flaws. First of all, people forget what it does. Second, it can cause problems in case some systems are set up different or it was not possible to reverse the setting in some scenarios where it would be better to exactly know what it does before.

That could be an issue ... if the "Disable Twig cache, general caching and CSS+JS aggregation"-Drush command is ever made, it would important to make sure that these situations are avoided.

Great comments all around, and lots of food for thought. Thanks!

Thanks for the open minded dicussion @ressa. Very much appreciated. And I hope my injections do not cut nerves.

Your own home rolled scripts, bundling many of the common settings each development team prefers sounds quite interesting. If possible, feel free to share it

Well they are not "home" rolled. Rather project specific individual helper tools guided by each company's dev teams in its own responsibility for in house use. Some of them are online but not on d.org for good reasons (responsibility for docs if things break). I am pretty sure we (the companies, I run as founder and CEO) are not the only ones doing it for frameworks they use. But as it says, it's very individual use cases in the responsibility of the agencies maybe better not promoted too much to the average user.

Some more elaborated inside (long read, skip if you like): I have a very special opinion about how to treat average users. And I care about them a lot from my Open Source community driven motivations view point. I ask many stupid questions around to sensitize developers for the average users struggles. In my eyes, putting anything out on such sources like d.org makes d.org responsible for when average users read and follow and things break. As you may already found out elsewhere, I am not the biggest fan of editing docs without agreement to not confuse users with cluttered information. I advocate for moderated content in a well lay out way when ever I can. To share such scripts on d.org comes with a lot of responsibility which should not be underestimated. And when users mess things up, it falls back to the source. In this case (and in my eyes) it would be d.org then. Not an emotional but a rational and legal view point I have. To save the average user.
# long read end.

Yes you are right. The much easier Twig debugging feature added May 2023 (Thanks Mike Herchel! from here too) is a massive improvement. +1 for all the hard work on it.

( it can cause problems )... if the "Disable Twig cache, general caching and CSS+JS aggregation"-Drush command is ever made, it would important to make sure that these situations are avoided.

Yeah. And this is maybe only possible if this feature has limits and compromises. Which would probably do not satisfy you 100% :-) finally. Since it maybe still needs you to set up things elsewhere too (again). Which leads back to what I sad here ✨ Easy way to bypass all caching with Drush or settings.php Active . Also security concerns could be raised by Drush maintainers. I am not 100% aware of how it is now but I could imagine that changing deeper nested error reporting and caching settings behind that what you can do already now in UI maybe should be avoided via Drush. But not sure yet.

Read above comments, and thought of trying it myself to achieve the listed requirement via single flag on Settings.php file.

Settings.php: [Set caching_aggregation flag to FALSE]

$settings['caching_aggregation'] = FALSE;

Code:

    $caching_aggregation = \Drupal\Core\Site\Settings::get('caching_aggregation', TRUE);

    if(!$caching_aggregation){
      // Enable Twig Debug Mode.
      $keyValueFactory = \Drupal::service('keyvalue');
      $development_settings = $keyValueFactory->get('development_settings');
      $twig_development = [
        'disable_rendered_output_cache_bins' => TRUE,
        'twig_debug' => TRUE,
        'twig_cache_disable' => TRUE,
      ];
      $development_settings->setMultiple($twig_development);

      // Disable CSS and JS Aggregation.
      $performance = \Drupal::configFactory()->getEditable('system.performance');
      $performance->set('css.preprocess',FALSE);
      $performance->set('js.preprocess',FALSE);
      $performance->save();
    }

But the question still remains that, if not drush command then when to invoke it?
For testing purposes I invoked it on form submit event.

Hope it helps someone, Thanks!

Thanks @keshav patel, this looks awesome!

Perhaps you can share the function part of the code as well, so that I can add it into a custom module, and try it out?

@ressa you can use this code snippet on any hook, event or on devel_php executer. It'll work.
Then you can visit "/admin/config/development/performance" and "/admin/config/development/settings" to verify the changes, no extra code needed.

Thanks for the info. It would be great with an example, with the function part included, since it would make it easier for me and everyone else who wanted to try it out quickly.

But if it's not possible, I'll try to figure it out.

So I managed to get it working by adding it in a custom module (caching_aggregation) and wrapping the code in this function:

<?php

function caching_aggregation_preprocess(&$variables, $hook) {

    $caching_aggregation = \Drupal\Core\Site\Settings::get('caching_aggregation', TRUE);

    if(!$caching_aggregation){
      // Enable Twig Debug Mode.
[...]

It works well, though only the two first Twig options (Do not cache markup and Twig development mode) are disabled at first, and I need to press F5 a few times for the last two (Twig debug mode and Disable Twig cache) to also get enabled. It looks like I also need to clear the caches.

An option would be to not use Drush or settings.php, but instead update the settings on install, and revert to standard settings on uninstall?

Great to see that there are snippets provided that maybe help you on what you need @ressa. +1

Following the last comments and re-reading from beginning it rather "feels" to me like a "support request" here now. I hope it helps, but to prevent too much noise for core maintainers I will set it to "Support request" until a maintainer things, this should be discussed for core, if you don't mind. Greetings and a wonderful Sunday evening.

@ressa as per #17 I guess you're referring to hook_install() and hook_uninstall().
yes we can do that, but standard settings will vary user to user, like for live site "aggregation can be kept ON and debug mode disabled".

Can you please share what settings you want to default it to upon module uninstall ? will share that part as well..

@dqd: I see it as a feature request, which might end up in Drush or Drupal core, or as a custom module, if that's what's feasible. But I would prefer Drush or Drupal core, since that would mean it's more easily available for the end user, out of the box.

I see the process here in this issue as iterative, where we can experiment and try out different methods, until something that works is found. I am curious: How would changing the status help core maintainers? I would think that having it as a support request would add more noise ... but I am of course willing to learn :)

Also, just to clarify: It's not about what I need, but making a feature which can aid the most Drupal users, who have the simple but reasonable need of disabling aggregation and caching easily, to be productive faster.

Or do you think it's a very niche feature request, which very few Drupal users would find useful?

@keshav patel: I think the state of caching and aggregation should be reverted to the standard settings (i.e. a fresh install) if flipped, and set to TRUE in settings.php. As it is now, the function only works in "one direction", disabling caching and aggregation.

Ideally, with just one action, the user should be able to disable or enable the standard caching/aggregation settings. This could be by:

• Set $settings['caching_aggregation'] = FALSE; or $settings['caching_aggregation'] = TRUE; in setting.php
• Run drush caching_aggregation:disable or drush caching_aggregation:enable
• Install or uninstall a custom module (not ideal, since it requires a lot of steps)

And I very much agree that individual users have different needs. So this feature should disable the most basic caching and aggregation, to allow new users (and experienced users as well!) to get quickly set up for theme and module development in Drupal. But being able to revert during local development, and flip the situation is also quite useful, since you often go back and forth.

Covering the needs for advanced and experienced users would make this feature balloon, and should not be in scope for this issue. Advanced users also have the expertise to write complex scripts, covering their specific needs.

The function you supplied covers exactly what I think are the basics of aggregation and caching (and it's awesome, thanks!) so that part is covered. Though, as I wrote I need to refresh a few times, for them all to be enabled. So ideally, all check-boxes are checked in one go, after updating settings.php or running a Drush command.

Update Issue Summary, adding reversion of settings.

@keshav patel: It just dawned on me, that we could more easily try the new feature in a fork for Drupal core, so I created one.

This is a support request and there is no MR to work on. Is the category and status correct?

Thanks for looking at this @quietone. There is a discussion whether it's a feature request or support request in #18 and #20. Feel free to update Status and Category as you see fit.

@quietone: Same here, wondered about "Needs works" too. Still no MR in progress or any explicit goal or extending feature concept yet reviewed already, from what I see. But I didn't want to discourage any discussion.

Why I considered SR in #18 ✨ Easy way to bypass all caching with Drush or settings.php Active :

to prevent too much noise for core maintainers I will set it to "Support request" until ...

In this state it wasn't clear for me if it was rather a support request of users needing assistance in easely disabling cache since the title and the fact that disabling cache is a quite simple task featured already in many ways, lead me to it. Maybe the issue needs a better phrased scope then?

@ressa: If there is anything in progress extending the framework functionality which not exist yet and which I do oversee, can you elaborate on this please? Thanks in advance.

To your question in #20: A support request prevents noise for framework managers, since they have a lot of work to do. And to review code and issues with provided code or MRs get a certain priority. And so I left it up to framework maintainers to choose the proper category if there is anything in progress or of interest to start at. And btw, "Needs work" is rather preferrable for work in progress and code changes reviewed and with work still left to be done or any other scenario in progress. Otherwise "Active" would maybe be more accurate here at this state.

Hope it helps.

Thanks for the explanations.

The definition for 'support request' → currently discourages use in Drupal core and directs people elsewhere. Using that as I guide, and after reading this issue closer that I did before, let's go back to 'Feature Request', which is what this is. BTW, I am not a framework manager but I doubt the category makes a difference to their time. The priority for committers is usually the RTBC queue and issues tagged for manager review. So, as a 'Feature request' this will not make noise for them.

Setting to 'active' since their isn't an MR.

I was also thinking that this work may fit into the ' Local server setup → ' into a new guide or page for things to do after a development site is initially setup.

@quietone: That makes absolute sense to me. Thanks for taking care of it and coming back on this so quick.

The definition for 'support request' currently discourages use in Drupal core

Oh ... that is not good. You are right. Then it should not be used here. +1

The priority for committers is usually the RTBC queue and issues tagged for manager review. So, as a 'Feature request' this will not make noise for them.

Ah, good to know! +1 this will help me to not do "over-care" on such points.

Setting to 'active' since their isn't an MR.

That's what I thought, yes, but I wanted to leave it up to you (or others) to decide.

I was also thinking that this work may fit into the 'Local server setup' into a new guide or page for things to do after a development site is initially setup.

Ah, yes, that could be a real good possible roadmap and clear goal for this issue then. Let's wait and see what the creator and contributors to this issue think of it. I am all in! +1

Again, thanks for helping out!

Hello @ressa → , @quietone → and @dqd →

I've added a page under Local server setup → => Custom Drush command for managing Twig debugging and CSS/JS aggregation →

Please have a look.

Instead of adding a flag on Settings.php, I though creating a Custom Drush command will be more handy.

@ressa → ,

In context of #20 ✨ Easy way to bypass all caching with Drush or settings.php Active and #22 ✨ Easy way to bypass all caching with Drush or settings.php Active :

Yes we surely can try adding it in the core or module, it'll help almost everyone. then their won't be any extra steps to setup this.

Awesome work @keshav patel, this was exactly what I was hoping for, and it works perfectly, thanks!

I updated a few details, such as adding drupal_flush_all_caches(); as a final step, to allow template suggestions to work right away. Otherwise you have to run drush cache:rebuild for template suggestions to be shown, like these:

<!-- THEME DEBUG -->
<!-- THEME HOOK: 'html' -->
<!-- FILE NAME SUGGESTIONS:
   ▪️ html--node--1.html.twig
   ▪️ html--node--%.html.twig
   ▪️ html--node.html.twig
   ✅ html.html.twig
-->
<!-- 💡 BEGIN CUSTOM TEMPLATE OUTPUT from 'core/themes/olivero/templates/layout/html.html.twig' -->

I don't know if it would be easiest to get the code included in Drush itself, or Drupal core? I have created a Drush issue, let's see what the maintainers say: Add Drush command to toogle Twig debugging and CSS/JS aggregation #6267.

Thanks again, I am very grateful.