How to programmatically set the age of a cache for a module in Drupal 8?

Question

Drupal 8:

I have code for a block that successfully does its job and returns it. The block is called "RacerProfile", and it passes all its content to the variable "$ pageContent". At the very end, it returns #markup. OK. Now, how can I say that this is not valid every six hours?

/** * Provides a 'Racer Profile' Block * * @Block( * id = "racer_profile", * admin_label = @Translation("Slider v1 block") * ) */ class RacerProfile extends BlockBase { /** * {@inheritdoc} */ public function build() { // does all the work to make $pageContent via non-drupal // database queries. However, for this example, let just // just imagine it gets the time of day. Then, let set // let set the cache age to 5 seconds so F5-F5-F5-F5... should // show 12 changes per minute on a repeatable schedule $pageContent.= "<p> Date and Time: " . date("F jS Y h:i:s A"); return array( '#markup' => $pageContent, '#cache' => ['max-age' => 5 ,], ); } } 

In other Drupal answers, I saw that "D8 has tags and cache contexts that will automatically change the value of a block if something changes." Great, but my code is checking the second database. Drupal has no way of knowing what's going on there. (Without verification, obviously.) So, how do I add cache tags with the specified timeouts? (Or do cache tags even do this?) I cannot find examples.

Notes:

- the above code does not give the desired result. The page is static for anonymous users. It changes only when the user / admin clears the cache through the web admin.

-Obviously, this does not apply to increasing the maximum cache in the administration area Configuration> Performance> Caching> Maximum cache cache age. I do not want this to apply to the entire site, only to this block. In addition, this setting does not seem to control this aspect of caching in any way, but instead is cache information that is screwed into the header of the displayed pages.

-Obviously, this has nothing to do with settings.php parameters, since again I do not want this to apply to the entire site, and different modules will have different timeout requirements.

- The traffic for the site is relatively low, so if you visualize a thing four times a day, even this needs to be done only once a day, this is not a problem. Every six hours, this means that it has changed before people wake up in four time zones. Basically .;) I directly declare here that I am interested in this work in general, before I worry about optimizing the download or use.

- I have several custom blocks with different expiration periods.

- Of course, I have a lot of problems with Google, and you still have to find examples that indicate a specific (measured in unit time) timeout for the module. Even in the D8 module examples on drupal.org

- Namely, the block should have its cache control for anonymous users. People without accounts, the "public" browses the site.

Answer 1

You can add cache settings to the array of rendering blocks:

 '#cache' => [ 'max-age' => 60 * 60 * 24, ], 

Time is measured in seconds. See Also: https://www.drupal.org/developing/api/8/cache/max-age

If you have tips on things that should have called reset, you can use some other caching controls . It looks like you have a very clear idea that you want to cache where and when, so learning about the cache API materials is probably worth your time.

Given what you are extracting from the second database, you can also examine BigPipe , which you did not ask for, but is intended for use in cases where it takes some time to collect all the information for this page. It is likely that using blocks built through BigPipe will provide a better user experience than data cached in Drupal for a fixed period of time (the entire cache mechanism has been rebuilt so that we can get away from this template).

Answer 2

It turns out that this is the “main” error in D8 that it is working on: https://www.drupal.org/node/2352009

In short, the internal cache page module currently ignores the "max-age" property, which may be related to cached metadata from rendering arrays.

Even if you did not use the internal cache module and instead of an external cache such as Varnish, the maximum HTTP header is always set to what you set at the "maximum age of the page cache" in the performance settings. See https://www.drupal.org/node/2732129 , which has a workaround if necessary.