Closed (fixed)
Project:
Drupal core
Version:
8.0.x-dev
Component:
comment.module
Priority:
Major
Category:
Bug report
Assigned:
Unassigned
Issue tags:
Reporter:
Created:
20 Feb 2015 at 16:36 UTC
Updated:
13 Mar 2015 at 14:14 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
wim leersBlocked on #2428563: Introduce parameter-dependent cache contexts.
Comment #2
wim leers#2428563: Introduce parameter-dependent cache contexts landed, now unblocked. Taking a first stab at this.
Comment #3
andypostSuppose better to apply
CommentPagerCacheContextfrom comment field formater somehowis it possible if:
1) bubbling is not supported yet #2429257: Bubble cache contexts
2) comment formatter could be changed to contrib provided one
Comment #4
wim leersBriefly discussed this with catch yesterday. We saw 2 general approaches:
QueryStringCacheContext: hashes the entire query string, and hence varies cache items using this context whenever a single detail about it is different.QueryParameterCacheContext: varies cache items using a query parameter that a render array varies by.I'm not a fan of approach 1 because it would cause even the typical Google Analytics query parameters that appear when used from feed readers to cause caches not to be used, even though Drupal never ever reacts to either of those query parameters.
I implemented approach 2.
But then I noticed that this doesn't actually work very well for pagers, because Drupal's pagers (see
pager.inc) actually don't use separate query parameters… but the same query parameter:page, with the values for the different pagers encoded as an integer at a different location in a list of comma-separated page numbers (seepager_find_page()).So I added a
PagerCacheContextas well.In doing so, I found a small bug in #2428563: Introduce parameter-dependent cache contexts: the
CacheContextsservice, when converting cache context tokens to keys, if given the same cache parameter-dependent cache context multiple times, with different parameters, it only keeps one of them. Very simple fix (with expanded test coverage) included.Comment #5
wim leersAlso note this bit in the patch:
i.e. once we have bubbling, we can automatically make sure that anything using a pager automatically sets the appropriate cache context, and hence it automatically bubbles up everywhere!
Comment #6
wim leersFiled #2433591: Views using pagers should specify a cache context as a sister issue.
Comment #8
wim leersFiled an issue for that @todo cited in #5: #2433599: Ensure every (non-views) pager automatically associates a matching cache context.
Comment #9
wim leersFixed test failures.
Comment #10
wim leersOops. Chrome--
Comment #11
fabianx commentedThis is off-topic, but this .missing is interested.
We should just still execute fields that have #access => FALSE so that we always have the same cache contexts and no variations :-p.
The PR looks good, gonna hopefully review later for RTBC.
Comment #12
andypostI still think that this context should apply within formatter, also this is a way to solve #11 about #access
Comment #13
fabianx commentedDo we need to sanitize this in any way?
Overall like a query parameter cache context, but perhaps we should have a cache_context.request.query
instead?
So we could also have cache_context.request.cookie, which is another important use case?
Comment #14
wim leersPerhaps it's better to just omit
UrlQueryParameterCacheContext, because it's not actually necessary to fix this issue? We can easily add it later.Comment #15
fabianx commentedSounds good, lets get this in first.
Comment #16
wim leersAlright, done.
Comment #17
fabianx commentedThis is technically an API change (though it was just introduced, so disruption is zero.
--
RTBC!
Comment #18
berdirI still need to read all the issues around that, but why is removing that only possible there?
Shouldn't the bubble issue allow us to remove it already, assuming the pager actually adds this context as well?
Comment #19
wim leersIndeed, plus: this is an API function that is very, very, very rarely used. Only code that provides a UI that shows cache contexts is affected. In core, that's only
BlockBase. In D8 contrib, likely nothing yet.Because pager uses
#theme => pager, not#type => pager. Preprocess functions cannot add cache tags. But#type => pagermeans we can have a#pre_rendercallback which adds it.Correct. But bubbling isn't in yet.
Comment #20
berdirOk, I'm not sure to which issue that @todo should actually point to. It currently points to #2429617: Make D8 2x as fast: Dynamic Page Cache: context-dependent page caching (for *all* users!), but I think it should point to #2433599: Ensure every (non-views) pager automatically associates a matching cache context?
That would make sense to me, but pointing it to the first seems strange, because I'd expect need to solve those kind of issues before being able to use that kind of caching?
Comment #21
fabianx commentedYes, lets put the @todo to this issue: #2433599: Ensure every (non-views) pager automatically associates a matching cache context
CNW, sadly on that ...
Comment #22
wim leers#20: LOL! Oops!
Fixed.
Comment #23
catchCommitted/pushed to 8.0.x, thanks!