Easy way to bypass caching and aggregation with Drush or settings.php

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 a fully content and module loaded 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. ... At least from what I understood have been asked here for (rebuild all).

While I agree that this could be an interesting feature request, I worry that the individual use cases run out of scope for an FR for core. And I assume that many (like 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 the open minded discussion @ressa. Very much appreciated. And I like the way you think. 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 thinks 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 on public doc sources of the respective framework.

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. 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!

@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.

Great to see that there are snippets provided that maybe helps you in 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 framework maintainers, let me set it to "Support request" until a maintainer things, there need to be work to be done. Or maybe there is a upcoming direction visible extending the cache disabling features already provided. 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..

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

@quietone: Since there is no MR or code for any explicit goal in progress for an improvement or extending feature concept yet reviewed from what I see, so I wondered about "Needs work" too. But I didn't want to further discourage any positive discussion about possible improvements by going on about issue tags.

Why I considered SR in #18:

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. The title and the fact that disabling cache is a quite simple task already in newer Drupal versions featured already in many ways, lead me to it. Maybe the issue needs a better phrased scope then? It is still not clear enough in which direction it would go.

@ressa: If there is anything in progress which I do oversee, can you elaborate on this please so that "Needs work" makes sense? Thanks in advance. And sorry if there is any confusion or guidance missing.

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 in progress and issues with provided code or MRs gets a certain priority over issues like this which seems to be rather on a didcussion status what it want to be about. No offense, same happend to me in issues.

And so I left it up to framework maintainers to later choose the proper category if there is anything in progress or of interest to start at. And btw, the "Needs work" status you set later, is maybe rather preferrable for work in progress and code changes reviewed and with work still left to be done or any other scenario more "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 thought creating a Custom Drush command will be more handy.

@ressa,

In context of #20 and #22:

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.

I think we can close this issue now, 'theme:dev' [alias: 'thdev' ] is added to Drush 13.6 version.

Also, after Drush 13.6 the 'twig:debug' is marked as deprecated.