 Let's start let's start then Everyone can you guys hear me in the back? Awesome So this is a session called practical caching in Drupal 8. Everyone asks me why this word Practical is in there. I'll tell you later I'm really excited to give that talk And I'd like to tell you a little bit about myself first so I am Alexei Gorobet in my native language It's pronounced Gorobets, which it's kind of hard to write that doesn't really matter So technical director at FFW Moldova Moldova is like a very small country in Europe for those of you from us I'm like five plus in the Drupal community I'm being like active member forever since because I I'm in love with this community and I'm a Drupal Moldova association co-founder So we we grow Drupal talents and we promote Drupal in our country and This session is about so Probably you've read the like kind of agenda I put it on the side, but if not I'm gonna tell you what this session is not about so I'm not gonna talk about how you would configure varnish to make your site Static cache faster. I'm not gonna talk about a memcache as your key store I'm not gonna talk about any of those kind of infrastructure things that everyone is trying to talk about and well, that's kind of great things to to know but at some point a developer approaches you and he's like, you know, I have a website and My content is not really up to date and I bet it's caching But I don't know how to debug this and I don't know how to handle that Could you please help me and you can say have you tried like clearly varnish cash? He's like, yeah, I did have you tried to clear Drupal cash. Yeah, it worked So you still don't know what the where's the issue? He's like, no so It's kind of great when you have this hosting provider that like throws all the things on you You have memcache ready is varnish But it's really it's really bad when your developer Like cannot handle the caching in Drupal 8 in terms of like developer perspective, right? So this session would be for developers and we'll discuss caching techniques for developers mainly So if you're an infrastructure guy, I'm sorry, but This is not for you. Anyway So they're kind of three things I want to talk about There are three types of like caching that I would say that should matter for developers in Drupal 8 and those are not new no just like My way of Categorizing them This is the anonymous page cash, which we all know from Drupal 7 and 6 This is a reverse proxy caching. I'll touch you very little on that This is our like lovely varnish or whatever you put in front and authenticated cash is one of the biggest deals in Drupal 8 That we're gonna talk about I'm just gonna start with the Anonymous one So an anonymous page cash is implemented in a module called internal page cash It's enabled by default if you install just a regular Drupal website Drupal 8 standard profile You have this module enabled it does everything for you You even don't know what it does, but it already caches your pages so the reason like I've put that here is I've seen so many people trying to debug an issue on the reverse proxy layer or The dynamic page cache, but they were actually Facing an issue that anonymous page cash was serving the cash and they were like oh I just like turn off all the caches and it's still serving No, so this module internal page cash is what takes care of your anonymous page cash In order to debug this and make it work for you You need to understand how this module works So if I compile the small like graph here that would show you that So basically page cash in in Drupal 8 is implemented as a middleware So when your request goes in there are a bunch of middlewares that Symphony framework like kind of style coding Does with your request and one of those middlewares is page cash middleware. So this is the component that Answers like to your It tries to see if you can get the page from cash And if you can it will definitely serve it and if you cannot it will not And the first thing you you'll get you'll face them What's called? Request and response policies those are pluggable There was a pluggable policies that you could implement your own but Drupal provides its own Default ones. So the first thing that page cash middleware does it checks for the request policies If any one of them denies this cash to be retrieved this page To be retrieved from cash, you're not gonna get the page from cash So if like everyone allows that the page would be looked up in your anonymous page cash Would be served from the cash and if it denies that of course it would go to Drupal and Like regenerate the page for you From grounds up. So the same happens when the cash key is not found in your page cash It would go to Drupal to the regenerated the second thing after the cash was regenerated or Like you basically got Drupal to generate that page cash there is a response policy which Kind of decides if the page should be set or it should be skipped Is it a good cash? Is it a good page cash? Should we set that cash for other users? We shouldn't be skipped and if it's skipped, of course, it's not set and the next request with this similar Parameters would just skip it again because it will not be cashed But if it's okay to cash that if it's an allow allow then it will set the cash There are two default request policies that you need to track This is the not CLI. So if a request comes from a command line interface It will not retrieve the cage from the page from cash So again request policies respond about should I look up the cash or no? And if it's an open session if you are logged in it will not retrieve those from the cash So two basic ones at the moment of writing that presentation that are default in Drupal their response policies as well and The response policies are where like the tricky part comes in like developer comes in and says Dude, I don't want to cash that page. Why is this cashing? I'm like, okay, let's see So there is there are free ways to manipulate the page not to go into the anonymous page cash First this is a page Kill switch it's like a service that you can trigger that kill switch and the next page request will not be cashed There is a route Option that you can specify in your route if you specify the route option. No cash the route will not be cashed And there is no server errors Policy, which means if there is at least one server error This page will not be cashed. It doesn't need to be cashed if there are server errors Those are by default again, but if you want you can implement your own Let's see how those kill switches work if you want to bypass the anonymous cash Not actually bypass but not save that page to the cash is What you're doing is in your code you do something like this you call the service page cash kill switch and you just trigger so trigger will trigger the Flip and this page will not be cashed or you can specify no cash through in your options for your route and That is also going to work So if you want like your custom way to skip the anonymous page cashing not just anonymous But I'll get to that you can see we're taking this service with two tags here which one One is the page cash response policy and another one is dynamic page cash response policy You can use the same response policy for both anonymous and authenticated Cash, but we'll get to that later So if you want a cash policy of your own you just define a service you tag it with the Proper tag you take it with the page cash for the anonymous cash with dynamic page cash for the dynamic page cash And you can take for both and you can then check for some like custom condition For example, you can check for your URL containing the intranet Like what I do here and if it contains the intranet string then you're denying basically your Response policy says deny and this would not be cashed. You don't want to cash your intranet probably for anonymous at least So this is anonymous page cash It's really important to take a look at this so I'll put the slides on the web Just go through it. You can go through a debugger, but make sure it's there. Make sure you know how it works The next thing I wanted to cover is the reverse proxy cache So there's not much really to cover here. Everything is what we had in Drupal 7 but one thing to note is Like to enable your reverse proxy caching the one like one and only switch for that would be you just set your page cash expiration age Which would set your cash control headers and you should be done So Another thing to note is of course if you want to track your IP address correctly From the reverse proxy then you should set the reverse proxy IP address header and other headers that you want to get from your reverse proxy because your reverse proxy would terminate the request and Your web server will get a new request that might not have the correct server the correct headers You'll get the IP address of the reverse proxy, for example You also need to put all your reverse proxy IP addresses in the trusted List of IP addresses, so nobody tries to spoof on you That's basically it So the biggest biggest biggest thing in Drupal 8 is Authenticated cash if everything else before we already had and We like knew how to handle that this one is new and the like in Drupal 8 Drupal cons lately everyone is discussing that There is every session about cash ability metadata and this is one of them But I kind of mixed it with some practice, so we'll see So Caching for it to be good has to have a high-heat ratio, so you don't like waste your Connections you don't like waste your server time you want every time user comes For the cash to be a hit You want the cash to be up to date. Of course, you don't want your content to be Stale and you want the caching like to be easy to invalidate you want to lower like cash complexity Caching validation complexity, so and the problem with those caching Like features that we want is you can usually choose only two of those You know that project management triangle that says like you can do budget scope or timeline and Only two of those this is very similar So if you want a high cash Heat radio and you want it up to date then you probably need a very complex in validation system And if you you want to like a very low in validation system in a high-heat radio Your cash is probably not up to date. So this is kind of problem what Drupal 8? is trying to solve and Drupal 8 is trying to make a like invalidation mechanism that is still very lightweight and easy to understand but It works for us so of course there are two known hard things in the computer science and one is caching validation and the other one is naming things and the caching validation is not really an easy task to do and Drupal 8 does that well, so I'm pretty surprised but Using cash metadata so cash metadata is The thing that you've probably heard of but I'll just cover more in that presentation. So we have theory start for the practice Basically Like let's see how we can solve those problems So we have a personalized content that needs a more granular cash So you can't cash this content for everybody, but you need to rather cash it for example by username because that's the username block So you want to cash your admin links block? By permissions because the links Will be different if the user has different permission and of course like the help block in Drupal is Like generated by URL each URL is different help block. So that's a very old module, but that's how it works You don't want to cash that permanently you want that regenerated per URL so The solution for that in the cash ability metadata comes as cash contacts So you can specify the thing that you vary on In your cash ability metadata is cash contacts and you can say that my cash should vary by User so every specific user will get a different cash my cash should vary by user permission So like a hash of permissions would be calculated and if a user has different permission They will get a different cash and I want to cash my contacts My cash by URL so every URL will get a different cash so that's a solution to like personalized and Different cash for the same object, but different circumstances different context So there also are dependencies that you want to track and one of those Things in Drupal 7 that was so hard to do is you have like a node and you've updated the node and You you had that expire module cash expiration and purge module that the node page would invalidate on your varnish server and You're just fine now But then there is a different problem that this node was included on like ten other pages that you don't track So the problem of tracking dependencies is very hard If you don't track dependencies is very hard to invalidate that node cash on a different page than the node URL You would basically have to like compute all the dependencies and like gather all the URLs of the pages that this node has and It's really hard to do from the node level that node was just saved It's hard to track that so the solution for that in Drupal 8 is the cash tags so when you set the cash in Your back end you can In your code you can set what this cache depends on and you can set either an entity type entity ID like user column one where you can set some generic tags that are already invalidated by Drupal for example each View that list is nodes So if it lists nodes it has the node list cash tag So you can say that every time a node is updated then please please clean all the Caches for for the views at least nodes. So it's easier when you set the cache to Set the dependency as well with it. So it's very easy to track what should be invalidated and that's the cash tags So then you want to decide should I cash this for how long like is it worth caching? Maybe it's too granular too personalized Too dependent Maybe I don't want to cash that so you control that with the cash max age parameter And you can basically say permanent cash by setting minus one or you can say No cash by setting zero or you can say a number of seconds that you'd like that to be cashed and That's really like depends on your use case But I guess the like you would vary with minus one and zero most of the times because With all those other tools that you have you basically want a cash heat radio and you have that Invalidation mechanism that can invalidate and you don't need to set a Cache lifetime most of the times At least for the dynamic page cache, but it really depends on your use case So let's take a look at some example. This is a render array of the Bartik branding Like header in your Drupal website, which has the logo the site name and not much so we want to catch that branding block and This is a block Which is blocks are entities. So this is cashed in the database or whatever storage you're using memcash This is cash this entity view block Bartik branding key the Computed key would be that long, right? So it doesn't depend. Let's say on anything It doesn't vary on anything because you're really like every page has the same branding block, but it really depends on something like external dependencies and it depends on if a block Representation or a block. Let's say preprocess or something was changed you have a template for the block and This was changed somehow so the block render array was cached and the full render was cached And you actually want to invalidate all the blocks on the site So when you want to do that, you just invalidate the block view tag so this branding Block also depends on what's configured in your site name. So if your site name changes You actually want to invalidate that header block. So this is why it says config dot Sys system dot site. This is the config it depends on and also Bartik has this fancy feature that you can use the color module and like Play with the color of your But that's not it. No, that's something else. Anyway And you can see that this block is actually worth caching Permanently because there is not much change. There's not much change occurring. So we want a high cash hit rate So we cash it minus one the next thing I'd like to cover is The cash metadata Bubbleability so what is bubble ability? It would be hard to explain, but I'll take an example So you have this username custom block That has the following cash metadata. So username just shows the username, right? So the username is cached in the key like username user ID The key doesn't really matter for now. It doesn't vary by any circumstances like The contexts are empty, but it depends really on the user block cash because the user block might have different settings and you want to invalidate that and It depends on the user. So if a user changes his username, you want to invalidate that block Then you have like the username block is rendered inside a region like Had a region for example So that had a region renders that block and that block has some dependencies has some Cash metadata that it depends on something External or it varies by something so that header may not be cached by itself Without considering his child dependencies because if the header is cached That child will forever be cached even if the header like Even if you invalidate The child the header will still be cached. So you have to bubble up. You have to provide more context to your external Region external block that shows that the guy So this is why the header region will inherit the cash metadata from its child from the username block so essentially bubble ability would be The header region by itself depends only on the config system site Because if you change the site name, it has to be invalidated But because it has the username block in it the username configs will bubble up to the region to the region Render array and they will be merged and the region itself the header region will get both cashability metadata of the user username block and his own and The same happens for other children. So if your region if a region has multiple blocks All of them will bubble up the cash ability metadata to the parent so that makes us that allow us to track dependencies on a way way like better scale and level that we can invalidate things and Not just the children, but the parents that will Will also be invalidated So and the page rendering this region now is rendering the header region and rendering other regions But had a region depends on the username Itself and on the site name So both of those would bubble up also to the page level cache and your page level cache would get this Cashability metadata so when you invalidate like you save your user or you change your site name the page level cache will also be invalidated so let's take a look at this very simple website as an example and See what cash ability metadata? We can we can find so we'll take the first site install the header and You tell me what cash ability metadata this block has so context tags and Whatever, let's let's cover those two What do you think? So let's let's take the first question So site name is for tags because if you change the site name this block has to be invalidated user user User is not there. No, no, no my account is different. I'm just highlighting this one You can see the like yellow yellow thing. So just the site install and the logo. Does it depend on anything else? Just the site name the logo. Okay. I can configure a different logo for example. Maybe Okay, let's take another example. Let's take this menu bookmarks query Yeah, so there's the menu the main menu What do you think it depends on so what it varies on and what it depends on as external dependencies that have to be invalidated? Let's start with what it varies on User access all right because like links will be different depending on user Is it like user permissions or user role? What do you think? user role user permission Basically, it's user permissions that it's just taking all the roles and all the permissions compiling a hash of permissions because you you can have like multiple roles and it's gonna be hard to do like all the permutations and Identify that this is the same set of permissions. So basically all permissions are hashed and It caches by the hash of permissions So, okay, what else? Menu items. Oh if you change the menu itself, it has to be invalidated. So is that context or tags? That's tags All right, let's take another one. That's the search block. So what do you think it varies on? Configuration obviously because I could configure to go to a different search page for example. What else? Permissions user role same with permissions Me up for example What else? URL that's very that's awesome. So because can you tell why? Correct Yeah, so if you put something in there in that user block and you search for something that has to carry the Current keywords from the URL in that block, right? So it will vary by URL Every time so let's take another example Let tools menu for example what it varies on permissions, correct correct a Little bit different things maybe so in Drupal 7 we had the way to configure the main menu and the secondary menu and you could switch that in just a setting and Here you can configure also the tools menu You can say which menu to use for the tools and this varies this doesn't vary, but this depends on this configuration, right? So that's a tag All right, let's take this one bookmark this. I know it's hard to see bookmark this Link what it what it varies on let's say user user URL why Think more a little bit Entity ID or something it could be what we don't know If you just look here what it would depend on it would depend what that's a flag module, you know flag module Anyone use like module. I Think everyone should Yes, so I would say can we say it depends on the flag state. It's flagged now or unflagged So you cannot show the same URL for people who flagged or unflagged it, right? It's different. It would be bookmarked this and unbookmarked this or something right a User because the flag could be per user or the fact could be global so this is kind of like how context can arrive dynamically and What else? Let's take another one in the corner the username menu the user menu It's called the user menu, right? What it depends on Like what it varies on let's see user I Don't see any user specific thing there. What if it goes to such user only? Oh, yeah totally So what would the logout link depend on? No Status like what kind of status? Role That's the user role. So the logout link varies on the user role so If we take all of those that we just described all of those various Context and all of those tags like external dependencies and we look at that page all of those would bubble up Right to the top of the page cache so your page cache would vary on all of your context that we just described and Would depend on the external dependencies to be invalidated for all the tags that we just described, right? So that's how bubbling works All right awesome one other thing about Bubbleability and context metadata is they are hierarchical. So if you if you take like In one sentence, that's like more general ones consume the more like specific ones so for for that example for that specific example if one of your Blocks depends on just the query arguments in your URL But another one depends on the full URL including query arguments and path The URL already has the path and the query arguments in it So you don't want to depend on two things and one thing does the second so they are consumed and Only the most like general one is used so any of those variations of those Cache Tags would be consumed by the URL so URL would consume those and only the URL would be registered The same thing happens for the user if you depend on the user role But some other block that shows the username depends on the user itself That user itself is already more granular than the user role So you don't want to have both of them because you'll have too many variations, right? But you want to have just the most like general one that consumes the others So this is how hierarchy works. So if the prefix of the cache tags Includes like or starts with is the same so the the tail is just dropped and The context and the tags are consumed All right, so that's a really powerful tool to make your cache not to variable and not to Too many dependencies on it So, yeah So let's see how we can actually step cache our stuff from developer perspective So if your operation is consuming too much Cycles you probably want to cache it you have to decide if it's worth caching So if you want to cache it separately and specify a cache key So for it to be cached in a separate storage You just specify a cache key and you can invalidate that cache key later You specify the cache keys So if your content is specific to several conditions you use the cache context, right if Your cache depends on some other like external dependencies to be invalidated when someone else is invalidated you use the cache tags and If you want to change something like if you want the cache lifetime to control it You use the cache max age those for a cache ability metadata that you can provide in your Render arrays and other stuff that I'll show you So let's take a render array like a basic render array that renders some stuff That's expensive to calculate and it has the username and URL in it So what cache metadata do we want for that? Who can tell? So let's start with the keys How do we make that cache like in the cache storage? What keys do we specify? user ID Okay, it's just the user ID. So this block is somewhere printed, right? We want to catch that block somewhere We want to specify what it varies on and want to specify external dependencies But somewhere to catch that block we need to specify a key for this to be set in the database or Whatever storage that key should be Stuff great key So Cache context what it varies on user name and URL. That's very obvious, right? All right, and what it depends on external dependencies the user Correct and which user? Yeah, so that would be the user user ID right All right, let's see the results Expensive stuff actually and not stuff But you were close so the keys and the context you don't have to put the dependency on the username and URL in the key itself because what essentially context do they compile a Longer tail and append to the key so you can put your key whatever you want like my module name Expensive stuff and then the context are going to compute to a string and this string is going to be appended to your key when it goes to storage and the same thing would be to retrieve that so The keys are very lightweight. You don't put everything in the keys You depend on the user and URL you were correct and the text is a user column User ID, so if a user one whatever user is updated this the cache will be invalidated Awesome, so what happens if my content is like too dynamic? Yep. Oh Oh, you look at the code You look what Drupal uses you you can look for who implements the cache ability I don't remember the name cash context interface or something like that. So if there is a cash, right? Thank you. So you just look look up who implements that Yeah, so if you have two dynamic content, it's too expensive to Calculate every time and it's it's really not worth to cash for example because it's really the dynamic Like here contextual links that appear on every block if you're an admin user, right? so Like your page content is not updated But you're just have a flag in it that has to be different Every time a user clicks on it and it depends on the user for example, that's a user flag And it also depends on the flag state and another option and another thing is you have many links and You will not believe me right, but many links have the active states, right? So basically you would have to vary that many links block Like the menu block based on the URL every time because you have the active state that you have to track So it's kind of a problem. We have all those kind of tools But we have so many dependencies that would make it too dynamic and not worth caching So there are solutions for that that Drupal 8 is already doing The first solution is JavaScript, of course So there are custom things that you can do for your own module if you can't really benefit from cashability metadata and that's what we're doing with Contextual links with many links for example, so many links will actually put some Data attributes when the menu link is rendered and there will be some JavaScript reading the data attributes and setting the active class for you On the client side, so there is no need to cash that active class for you That's really nice and the contextual links use a technique called It's not all Uses it's only placeholder instead of printing the contextual links. So the placeholder would say Where to get contextual links and what is the cash key? So let's say for the contextual links, but it will not actually render those contextual links on the first run It will render on the second in JavaScript and another technique is called placeholders and lazy builder and Fabian France Mentioned that a little bit on his yesterday presentation That's a really cool technique when you that you can use with like alternative Page rendering mechanism like big pipe and I'm sure there will come a lot more of that So if you want something to be like big big pipe enabled and to be served as the second Ajax request or like you just streamed to your page when it's ready or Anything that can use placeholders you can you can use instead of rendering your Content in your render array. You can use a technique called lazy builder So what you're basically doing is you're specifying a callback When this content wants to be served this callback will generate the content including all the And you just specify the Parameters to that function. So basically that's a function that everything it needs to render the content is passed Inside so there is no like external dependency in that function or method, right? So this is an example of how flag module does it's flagging an unflagging link It forces creating a placeholder a little bit on that. So when you specify lazy builder You have two ways to make it a placeholder You can force it you can say create placeholder true and every time some rendering like big pipe a cures it will just take this lazy builder and It will like first put a placeholder and then big pipe will serve the remaining content and replace the placeholder and If you don't put the create placeholder there is a way like Autodescovered placeholders. So some context some tags maybe too Like too dynamic and you can specify in your settings PHP file Which one of those are really important for you? Which one of those are really dynamic for your website and this kind of Placeholders this kind of cache context will be auto placeholder By a website. So as a module developer you can leave that option for Website maintainer and user or you can hard code the create placeholder Contextual links use its own technique that's not using placeholder ink But uses a very like similar approach Basically, it uses it uses JavaScript and has a data attribute for contextual links So this one is rendered but contextual links will appear for you only if you have Permission to access those contextual links and this is calculated by your user permissions and stored in JavaScript It's cached and it will replace your contextual links afterwards So let's do a little bit of practice so I know we've talked about render arrays and Stuff like that, but like what I've seen people are doing is still they can like return a regular response in the controller and Have a like question to you. Will this response be cached? Who knows? Yes, that's a perfect answer Another answer No, oh You're asking too much no No, no, no It has to be right. I'll show later. Okay. So will this one cash? Who knows? So the only difference is this one has admin route true as an option. It won't that's correct and The previous one also won't because if you want to cash something It's not enough to return a response object. You have to return a Cacheability response cacheable response object and that's kind of thing that everyone overlooks when developing something Like custom like a custom API response that what they do Nothing is cached by default if you just work with response You have to return a cacheable response and provide cacheability metadata for it. So in this time Will it be cached? Why not? What does add cacheability dependency say? Yeah, this will be cached. So finally we have a cached response That's awesome Let's take a look at another example. So you can either return from your controller You can either return a response object or anything that implements response interface and Cacheable object a cacheable response is really what you want to do Want to return if you want to cash it or your controller could basically Return a render array, right? So that's the basic thing to do. So if you work with render is already you probably have More knowledge of cacheability and like it's way easier to do. You don't have to keep that in mind So will this one cache? The answer is no and this is because max age is zero Correct. Okay. Let's take a look at this one. Will this one cash? Yes, and another answer Okay, that this is a tricky question. That's my answer Because this depends on your Drupal settings That you specify for cacheability metadata. So by default Drupal provides some of like default settings that you can tweak But you can really say which cache context and which cache tags like which cacheability metadata are not worth caching and if you specify that in your settings PHP none of those will be cached and By default Drupal comes with a setting that says if something varies by user We don't cash it So this varies by user So it's not gonna be cashed In default Drupal settings, right? But you can tweak it depending on your own like needs and this will cash That's a good exercise So you don't need to know everything about cacheability metadata debug it manually because there is an awesome tool Fabian France was showing a little video yesterday about it and this is the tool you want to use Probably after some patches applied and you know it's still a prototype so you can find it on the project render views and It's a Drupal org and it requires a Drupal 8 patch, but that's really easy to do So what this tool does basically when you load your page you look at the console and you can see all the Cacheability metadata bubbled in your page You can see all the cache tags You can see all the cache contexts and you can see a list of those So you can query for some specific Cacheability metadata and you can find which elements on your page have it So for example, if someone is saying no, no, no, don't cash that page And setting a max age zero and you don't know who does that you just see that your page is not cashed You can use that tool and query for like Max age Zero this one says Context route I'm looking for everything that depends on the route varies on the route But you could say max age zero and that would like pop up all of those elements on your screen And you will be able to see all of those and navigate through those and find like the actual guy Who's doing that and then you're gonna do a good blame probably find a developer and teach him some Cacheability metadata lessons. All right, that's how we do it. So another good thing about that even if the whole like Visual thing doesn't work for you. What I found useful with that module is it prints cacheability metadata in your Dom so you can see some comments about each and every block what cacheability metadata it has and You can even see what cacheability metadata it had before bubbling and after bubbling So you can see how those things bubble up and you can see if he's the like He's the guy that you need to optimize or he just inherited that from someone else what I'd like to say is like I usually Don't cash My rendered output, but what I do when I do I do it permanently so if you want to get the best experience out of for your users and Make it like the highest heat rate. You probably want to cash everything permanently Other than some stuff that you don't want to cash, right? So with this kind of Interesting ways to invalidate your cash I encourage you to look at the cash metadata like closely learn it teach your developers and cash as much as you can so This all couldn't be possible without Vim Liris and Fabian France working on this so long and giving so many presentations that Inspired this talk. So I'd like everyone to give a loud applause to them. Thank you for their work and if you want and If you want to join the session that the sprints on Friday and help develop debug and fix the render vis and Whatever is left on the cash ability thing to do I encourage you to join the Friday sprints and Please please please evaluate my session. I need feedback because this is my first Drupal Khan session so Now we can start with some questions Yep, I Think you need to use the mic Specifying max is nice, but can I do specify a min-h as well? So imagine a comments blog on a highly frequented page on the front page Which I don't want to invalidate on every new comment on that page. I Don't think you can not yet Okay, thanks Awesome to repeat that in general you can but it's not yet done All right two questions The first question is you were talking about ways to find out when when somebody's not caching something that should be and then You said you could do a poll request to go find that person Is there is there another option? Is there a way to alter the cache settings on something via some alter hook or whatever? Yeah cache settings on alter on render arrays. So everything you can alter like Every render array can be altered right at any point in time if there's someone providing an alter hook So just alter that render array. Yeah, you could do that and the second question You were talking about how you you want that the cache hits to be to be really high What are there any specific tools that you use for monitoring the cache hits? Yeah, I think So you could look at the memcache stats It depends on your storage and I think every storage should provide a tool for that for cache hits If you want to look at the page cache hits, that's what you're looking for Well, anything let's say you're using you know triple core You know the cash storage right in the database to triple core provide any any stats or maybe Devel does or anything like that to show you what your cash hits are So So web profiler extension give you some information about that. It's part of the vel module right now. It was merged Thank you Hi about the bubbling I was thinking is it the entity reference also? taken care of so I'm modifying an entity And does it also bubble up to the reference where is the reference? I'm not sure it depends on how into reference module does that but I assume it does Obviously does Thank you We have a problem in our triple seven Modules and sites and I think the point might be the same problem just double-checking. So you have like a sites-wide block like Popular nodes and these block shows on every single page and have 10,000 pages if one one node becomes less popular the output of the block will change and Would that mean that's gonna refresh every single page on sites? Oh, no, no, no, no, no, I can take that Let's let's let's talk about placeholder first. Yeah, I thought about doing placeholder things placeholder ring But on my presentation yesterday you said it's not good to place on everything So we actually but that's not everything. That's just one block. No, this is one block We have other blocks which work same way Some of them are have like contextual filters and they they take the argument from the page and then build something and Some of the page will have the same block Many many places. So yeah placeholders could be but we have other blocks that work same way and should not place hold everything So is there a way out? Right? So either one of those two techniques either JavaScript or placeholder ring is what's available right now So it depends on your the actual Thanks. Yeah, you can use with placeholders so if you have a situation where you have One entity configuration system that is being output through Page attached altar thing it is or hook page attaches page attachments and The output depends upon both say the entity configuration or the entity's values and then Kind of any token in the entire system and and its own custom configuration things Any recommendations on how to Invalidate the render output if the custom Entities are changed. So it's a relationship that is Only defined during the output rendering Hmm, it does the cash tags resolve your issue. I mean if you put your custom entities all of them in the tags Haven't tried yet, please It's a little more complicated than that So the problem is doing hook page attachments I'm you kind of don't have any idea of where to put that cash penalty meter data The idea is you create and render array and then you call Drupal Service renderer at cashable Dependency for the note that you are adding that you are getting information from now You have a render array that's having that's perfect information, but you don't know what you do with it There's one simple thing you can do to get that information. You just render it So then you render it via the renderer and we're actually using that in core as part of the URL generator because we were losing meter data back and forth everywhere and so With that technique you just render it and then you won't lose it and anything that's kind of coming after the page attachments We'll still catch that and That should start work Thank you Any other questions all right, thank you everyone