On 11/12/13 08:22, Daniel Kinzler wrote: > 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?
No, the set of options which fragment the cache is the same for all users. So if the user language is included in that set of options, then users with different languages will get different parser cache objects. That is to say, the options key stores the list of options which vary the cache. ParserOptions::optionsHash() uses this list to form a parser output key (as in ParserCache:getParserOutputKey()) which is specific to the actual options requested. If the parser output varies by language for some users, and not others, then you may possibly have a problem, but it doesn't sound like that is what you are doing. > 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. That's probably because you incorrectly used $wgLang or RequestContext::getLanguage(). The user language for the parser is the one you get from ParserOptions::getUserLangObj(). During page save, a default ParserOptions is used, with the default user language, for the purposes of link table construction. The ParserOutput thus generated will be saved into the ParserCache. So it's not correct to use the context user language during parse, this will cause pollution of the parser cache. > 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()). It's not necessary to call ParserOutput::recordOption(). ParserOptions::getUserLangObj() will call it for you (via onAccessCallback). > ParserCache::getOptionsKey could delegate to ContentHandler::getOptionsKey, > which could then be used to override the default behavior. Would that be a > sensible approach? No. -- Tim Starling _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
