Roan Kattouw wrote:
One easy hack
to reduce this problem is just to only provide a few
options for stub threshold, as we do with thumbnail size. Although
this is only useful if we cache pages with nonzero stub threshold . .
. why don't we do that? Too much fragmentation due to the excessive
range of options?
Maybe; but the fact that the field is present but set to 0 in
the
parser cache key is very weird. SVN blame should probably be able to
tell who did this and hopefully why.
Roan Kattouw (Catrope)
Look at Article::getParserOutput() on how $wgUser->getOption(
'stubthreshold' ) is explicitely check that it is 0 before enabling the
parser cache.
*There are several other entry points to the ParserCache in Article,
it's a bit mixed.
Note that we do offer several options, not only the free-text field. I
think that the underlying problem is that when changing an article from
98 bytes to 102, we would need to invalidate all pages linking to it for
stubthresholds of 100 bytes.
Since the pages are reparsed, custom values are not a problem now.
I think that to cache for the stubthresholds, we would need to cache
just before the replaceLinkHolders() and perform the replacement at the
user request.