![]() Vendor/bin/drush cset ttings api_token XXXXXXXXXXXXXX Vendor/bin/drush cset ttings auth_using token You will need to configure both the Cloudflare module and the Purge module. Or you may choose to configure those modules first, before enabling the processors. This issue will be addressed after configuring the cloudflare module and adding the cloudflarepurger to the purge module configuration. diagnostics: ERROR: Purgers: There is no purger loaded which means that you need a module enabled to provide a purger plugin to clear your external cache or CDN. Vendor/bin/drush pm-enable purge_processor_lateruntime Vendor/bin/drush pm-enable purge_processor_cron Note: You can enable both using one command. If you enable the processors prior to configuring the cloudflare and purge modules, you will likely see this diagnostic error: Vendor/bin/drush pm-enable purge_queuer_coretags Vendor/bin/drush pm-enable cloudflarepurger These may be combined into fewer commands in practice. The following have been separated into more commands for readability. Vendor/bin/composer require 'drupal/cloudflare:^ ' Enable modules ![]() Vendor/bin/composer require 'drupal/cloudflare:^ ' This documentation assumes you have installed Composer and Drush per Install Drupal 9 CMS in an AFS-Based Virtual Host. ![]() For more information, see the Drupal Cloudflare project page. The Drupal 8/9 module is at “beta” status, while the Drupal 9/10 module is at “alpha” status. HTTP/1.Note: As of this writing, neither the Drupal 8/9 or Drupal 9/10 Cloudflare modules are at GA release status. * HTTP/1.0 proxies do not support the Vary header, so prevent any caching by * Disable caching in ancient browsers and for HTTP/1.0 proxies and clients. $expire = ($date > time()) ? $date : Cache::PERMANENT Īnd this expire date is set to "" by FinishResponseSubscriber: /** *) The reason for this behavior is, that Internal Page Cache uses Cache::PERMANENT, if the expire date is in the past: $date = $response->getExpires()->getTimestamp() This is a bit misleading, because the Internal Page Cache does not respect this parameter *), but only puts this value in the response header for reverse proxies and browser caches.įor a high traffic site I would recommend to disable the Internal Page Cache (but keep the dynamic cache!) and use varnish, which will respect the max-age header and provides fine tuning for further handling of the headers. The parameter is "Page cache maximum age". įor the whole page you can set a global max-age in admin/config/development/performance. (edit addition) The block needs to have its cache controlled for anonymous users.įor cache settings of the dynamic cache see the answer from. Every six hours means that it's changed before people wake up across four time zones. The traffic for the site is relatively low volume, so if rendering a thing four times a day even it only needs to be done once a day isn't a problem. Obviously, this is not related to settings.php in any way either, since again I don't want to have this apply to the entire site, and the various modules will have different timeout requirements. I don't want this to apply to the entire site, just this block. ![]() Obviously, this is not related to the Maximum Cache age within the admin area of Configuration > Performance > Caching > Page cache maximum age. (Without checking, obviously.) So how do I add cache tags with specified timeouts? I can't find examples. There's no way for Drupal to know what's changing over there. In other Drupal answers, I've seen "D8 has cache tags and contexts that will automatically invalidate the block if something changes." Ok, my code is checking a second database. Return array('#markup' => $this->t($pageContent), ) does all the work to make $pageContent via non-drupal database queries Now how do I tell this to invalidate every six hours? /** The block is called "RacerProfile" and it dumps all its content into variable "$pageContent". I have the code for a block successfully doing its work and returning it. ![]()
0 Comments
Leave a Reply. |