(re-sending from the "right" account for this list)
Hi.
I (rather urgently) need some input from someone who understands how parser
caching works. (Rob: please forward as appropriate).
tl;dr:
what is the intention behind the current implementation of
ParserCache::getOptionsKey()? It's based on the page ID only, not taking into
account any options. This seems to imply that all users share the same parser
cache key, ignoring all options that may impact cached content. Is that
correct/intended? If so, why all the trouble with ParserOutput::recordOption, etc?
Background:
We just tried to enable the use of the parser cache for wikidata, and it failed,
resulting in page content being shown in random languages.
I tried to split the parser cache by user language using
ParserOutput:.recordOption to include userlang in the cache key. When tested
locally, and also on our test system, that seemed to work fine (which seems
strange now, looking at the code of getOptionsKey()).
On the life site however, it failed.
Judging by its name, getOptionsKey should generate a key that includes all
options relevant to caching page content in the parser cache. But it seems it
forces the same parser cache entry for all users. Is this intended?
Possible fix:
ParserCache::getOptionsKey could delegate to ContentHandler::getOptionsKey,
which could then be used to override the default behavior. Would that be a
sensible approach?
And if so, would it be feasible to push out such a change before the holidays?
Thanks,
Daniel
--
Daniel Kinzler
Senior Software Developer
Wikimedia Deutschland
Gesellschaft zur Förderung Freien Wissens e.V.