Page MenuHomePhabricator

Stable version extension subheading not rendered after saving edit when parser cache used
Closed, ResolvedPublic


Author: netocrat

The stable version extension uses the ArticleViewHeader hook to display its
subheading. If the parser cache is in effect, then after saving an edit the
parsed page is cached without this subheading having been rendered. Subsequent
views will bypass the ArticleViewHeader hook's implementation in the view()
method of Article.php because the earlier call to tryParserCache() will return
true. This sort of problem is warned about in the comment above the hook.
Purging the page is the only way I've found for the user to refresh the page so
that the header is shown.

Possible fixes:
a) Add a hook immediately after tryParserCache() in Article::view() that the
extension can direct to the same code as its ArticleViewHeader hook (privately
tested and seems to work OK); disadvantage: very slightly mitigates the
usefulness of caching
b) Add a hook(s) to allow addition of content immediately prior to a save to the
parser cache, either after new saves only - i.e. immediately prior to the
$parserCache->save() call in Article::editUpdates() - or in general - i.e. at
the start of ParserCache::save(); advantage is that caching is not compromised;
disadvantage is that non-primary content may be cached
c) Add a hook(s) somewhere in Skin.php and SkinTemplate.php so that extensions
can arbitrarily append/prepend content to pages based on article/user; same
disadvantage as (a); advantage is general usefulness for extensibility

Version: unspecified
Severity: normal



Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 9:08 PM
bzimport set Reference to bz5142.
bzimport added a subscriber: Unknown Object (MLST).

fernandoacorreia wrote:

In my opinion, option "c" would be very useful for personalization and access

netocrat wrote:

Yes, that seems to work. It's a variation of option (a). I'm closing this bug
as fixed.