Hoppa till huvudinnehåll
Menu

Den här sidan använder cookies. Om du fortsätter använda sidan så accepterar du användandet av cookies. Läs mer om cookies

Jag förstår

Cache in Drupal 8: How it worked, and what we wanted to be solved in D8

If you just want your content to be cached before Drupal 8, there were almost no problems, just turn on caching for anonymous users, and you are all set. Muhahhaha! Who am I kidding...

If you just want your content to be cached before Drupal 8, there were almost no problems, just turn on caching for anonymous users, and you are all set. Muhahhaha! Who am I kidding...

If you want to interact with users with different content depending on the user, role etc. You got problems, if you want to invalidate the cache, you got problems. If you want to show a View of nodes, and turn off caching of that view, but had caching for anonymous users, you got problems. And so on. The most caching issues were solved by clearing all the cache, which could bring down the site if your unlucky.

So the real problem we wanted solve were not caching per see, it was cache invalidation. And like Phil Karlton supposedly said in the early nineties “There are only two hard things in Computer Science: cache invalidation and naming things.”

Some sites solved the caching issue before Drupal 8 with just turning of the cache completely, and scaled up the environments instead, and spent a lot of money in doing so. I have seen some high traffic sites with almost no cache logic in place, because it was to hard to get the cache invalidation to work. Those who worked hard on getting the cache and the cache invalidation to work smarter used modules like expire and purge, and integrated with rules solve complex cache invalidation. But is was almost impossible for any Drupal module to know where any content were used on a site. And that is what we want from smart cache invalidation.

Almost the only case that the default caching worked with no issues before D8, was if your site just were only one node, and some static blocks.. And if you updated that node, the cache of that node will be invalidated (hopefully). A normal sized site has hundreds and thousands of pieces of content, relations to other content, has listing of nodes etc. So it was real hard before D8.

So what we needed for cache in Drupal 8 is for Drupal to be aware on what cache and where it is used an in which context. Cache all things (aka. Fast by default), and make cache invalidation easier (aka Cache tags). And we got it. And let’s dive into what we got in the next blog post.

This is our second part of our ongoing series: Caching in Drupal 8, first part you could find here (with links to blog posts published so far).

Photo by Sera Tü. License

Vi hjälper dig nå resultat. Kontakta oss Ring direkt på 08-20 90 04.

Cache in Drupal 8: Introduction

In a series of blog posts we will go through how caching works in Drupal 8, to try to demystify the caching layer in Drupal …
MDN

Updating taxonomy term name in Drupal 8

Here you can read how to use hook update for updating taxonomy terms in Drupal 8.

Handle non-activated services on site install

In our developer workflow we install the site continuously during development, as a health check of the code base. One of th…
MDN

Varnish Purge 8.x-1.4 is out

As for Purge module 8.x-3.0-beta5, creation of cache tags is removed from the Purge module itself, and should now be handled by purges instead – so from Varnish Purge 8.x-1.4 we now have a sub-module, Varnish Purger Tags, that handles the cache tags.