Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.I'm trying to implement cache in such a way we bypass using cache_page all together. The typical way to accomplish that is documented here: https://www.drupal.org/docs/7/creating-custom-modules/suppress-caching-f...
if (!class_exists('DrupalFakeCache')) {
$conf['cache_backends'][] = 'includes/cache-install.inc';
}
// Rely on the external cache for page caching.
$conf['cache_class_cache_page'] = 'DrupalFakeCache';
I'm curious how this is implemented when D8cache is enabled. Would it be something like?
if (!class_exists('DrupalFakeCache')) {
$conf['cache_backends'][] = 'includes/cache-install.inc';
}
// Rely on the external cache for page caching.
$conf['cache_class_cache_page'] = 'D8Cache';
$conf['d8cache_cache_class_cache_page'] = 'DrupalFakeCache';
| Comment | File | Size | Author |
|---|---|---|---|
| #8 | 3012662-fakecache-documentation.patch | 5.1 KB | bdragon |
Comments
Comment #2
fabianx commentedIf you do not want to use cache_page then nothing is needed to be done from your first example.
The reason why you would want to use D8Cache with cache_page is if you want to use the page cache as a permanent but frequently expired backing store and in front of that a CDN / Varnish, which is purely time based with a low ttl (e.g. 10 min). This gives you the best out of both worlds.
Comment #3
generalredneckLet's add to the scenario. How about in the case we are using pantheon_advanced_page_cache acquia_purge or purge_varnish. In those cases a cache clear makes a call to the respective varnish instances. I've not done a lot of testing around this area but wanted to make sure I wasn't borking up the setup by mixing d8cache for everything but pages.
In normal caching scenarios we can set ttl to like 1 day (or longer) because cache clear purges varnishes cache like it would page_cache from the db. You just have to do the DrupalFakeCache setting as a work around to bypass the database controls.
Comment #4
bdragon commentedReopening.
Comment #5
stevectorFabian and Brandon, it's looks to me like Pantheon should consider suggesting DrupalFakeCache for cache_page for all sites (or possibly doing that automatically via pantheon_advanced_page_cache somehow) since our Global CDN includes surrogate keys. Is there any reason we should not make that recommendation for all sites?
Comment #6
generalredneck@stevector,
I'm pretty sure yall do recommend it... at least in any quarterly review yall have with partners and elite members.
But if the question is based around whether that is good practice when having d8cache installed in conjunction with pantheon_advanced_page_cache... I don't know the answer to that and am wondering the same thing.
Comment #7
bdragon commentedSince the CDN is doing the serving, seems like it would be fine to use DrupalFakeCache, yeah.
Whether or not you get any benefit from the page cache at all is dependent on how often/spiky the cdn re-requests a page after a flush and the site editing patterns, I suppose.
As long as the tag invalidation is working properly, you can use whatever.
We should definitely put a "using with Pantheon" section in the README.md -- most of the documentation is dealing with the caching bits, whereas with Pantheon, the bigger issue is the tag invalidation bits.
Comment #8
bdragon commentedInital go at writing some proper documentation on remote caching.
Comment #9
bdragon commentedComment #10
generalredneck@bdragon
OK I think that makes sense to me.
Also to answer my secondary question:
Upon further inspection of Purge, Acquia Purge, (and with it expire) is nothing like Pantheon Advanced Page Cache in the way they operate. In fact, they don't use Drupal's cache clearing mechanism to clear varnish (which I had no clue obviously) and this is by design. This means that the tags have no play in this and page cache can be turned off normally and everything plays the same...
With that said, that leaves the Varnish module out there... which does use the cache system, which also means that you can't have d8cache AND varnish cache turned on the same bin at the same time...
I suspect we loose the benefits of having cache tags at that point but I don't know for certain... Maybe someone else can elaborate on this or it may be better to open another support issue over there.
Comment #11
fabianx commentedRTBC - looks good to me, let's get that in.
Correct, there is also an integration for Purge, but it's not yet on d.org (as far as I know).
You can do that. Basically purge and varnish modules need to support d8cache by implementing the right hooks.
That said it's pretty trivial as only the key needs to match correctly, e.g. X-Key for Varnish and something else for Purge IIRC.
So your best chance in getting support outside of Pantheon's advanced page cache is to open issues in the respective projects.
That said:
Sometimes the best strategy is to use the Page Cache with a PERMANENT TTL (e.g. a week) with D8Cache and use a low forced TTL (page_cache_maximum_age) for the external proxy / CDN, e.g. 600 seconds as guaranteed time.
I think we are good enough here. I will tweak the docs one last time tomorrow and I think we are good to go then and have thought about all edge cases.
Comment #12
bdragon commentedOK, committing as-is, and we can follow up with additional notes if necessary.