Disable all your caching
This blogpost is a living source of tricks for Drupal Front-end developers that find themselves clearing cache manually over and over again.
You know how it goes: you changed something in code, but nothing is showing when you refresh the page. Instead of an existential crisis on whether or not you know what you are doing, you want to disable most of the caching layers as a Drupal frontend developer.
Disable Twig caching #
You can disable your Twig's caching from a
web/sites/default. There is a good chance you will have multiple files, that end on
.services.yml in this folder. For your local environment, you should change the one that says
In one of those files, change the 3 values to
auto_reload to be
cache to be false.
parameters: twig.config: debug: true auto_reload: true cache: false
There is a good chance, the file contains loads of comments, do a search on the word
twig.config, to find where those variables are located.
After having changed this, clear the cache and reload your website. When you inspect the page, the very first line should look like this:
<!-- THEME DEBUG -->
If you don't see this, then you edited the wrong
.services.yml file. Repeat above steps to find the right one :)
.services.yml file, is intended for a different environment, so if you found the right one for your local environment, you can commit it to your project's repository, if that change shows up in Git.
Disable Aggregation #
Through the backend interface
Aggregation is a process of Drupal that aggregates all of the needed CSS and JS files on any given page and aggregates is in to a single CSS and JS file. This makes development super hard, so you want to disable this.
You could go to
www.my-local-site.dev/admin/config/development/performance and uncheck the 2 checkboxes that say:
- Aggregate CSS files
And this would often successfully disable your aggregation! However, you now changed something in configuration, and the next time you export your config, you will also export this change, which is often not needed.
If you want to disable the aggregation, for your local project only, you could again do it inside a
settings.phpfile. Here applies the same principle like the services.yml file we talked about under disable Twig caching.
If you found out which
[name].services.yml file that you needed to change in order to enable Twig debugging, it is going to be the same
[name] but this time it will be a
[name].settings.php file. If you weren't sure which file in the end enabled Twig debugging, go back and find out, you'll thank me later.
Inside of this file, make sure these 2 variables are set to
If you don't see these variables in this file, feel free to copy/paste above snippet to the bottom of your file.
Clear your cache manually once more and reload your page, If you inspect your page, you shouldn't see
.css files that have a really long random unreadable hash as filename, such as: /]
Disable Drupal caching #
We now disabled Twig caching and Drupal aggregation, but let's not stop here. There is also another cache to disable: Drupal's cache!
Having identified your
[name].services.yml file and
[name].settings.php file that have an impact on your local environment, let's use those to disable Drupal's caching.
First we will create a fake cache service that doesn't work, by adding it to the
services: cache.backend.null: class: Drupal\Core\Cache\NullBackendFactory
There is a good chance, your
[name].services.yml file won't have the
services variable. If this is the case, please add it to the bottom of this file.
Next we will instruct Drupal's caching layer to use this newly created (not working) service:
$settings['cache']['bins']['render'] = 'cache.backend.null'; $settings['cache']['bins']['dynamic_page_cache'] = 'cache.backend.null'; // Expiration of cached pages to 0 $config['system.performance']['cache']['page']['max_age'] = 0;
When you now refresh the page, nothing visually will be changed. You can test if you successfully disabled this cache layer, if you open up any currently in use .html.twig file in you theme and change some HTML. If you successfully disabled this cache, you will be able to see the change appear on next pageload, without having to rebuild the cache.
Use a Compony theme #
There are some more edge cases that can still require you to manually rebuild the cache, for example, when you change the contents of a
libraries.yml file or when you rename, add or remove a
Compony is here to help you. If the theme you are working in is a Compony theme, you can configure your local.config.js that Compony provides for you. In particular you can enable the automatic cache rebuilding feature.
In the component based-setup that Compony suggests, it will also clear the cache whenever you drag and drop a new component in to your components folder. or when you are moving components around, as that changes the path for Drupal's
Something missing? #
Something missing from this blogpost? Please do let me know below, and I'll add it!