Introduce ContentAlterParserOutput hook
authorGergő Tisza <tgr.huwiki@gmail.com>
Fri, 19 Sep 2014 10:09:54 +0000 (10:09 +0000)
committerGergő Tisza <tgr.huwiki@gmail.com>
Mon, 29 Sep 2014 18:44:39 +0000 (18:44 +0000)
commit6c0afc3cc9756492ec42c5411fabac2943d4eb73
tree51d22aca7cbb9ecc4fbc323ae389dfc754f2dd8b
parent0126e6356ad34ecd6db3bb4f5b8aa39066d51b44
Introduce ContentAlterParserOutput hook

This hook is the counterpart of ContentGetParserOutput: it gives
high-level access to the parsing of a content object (as opposed
to lower-level parser hooks like ParserBefore*/ParserAfter* which
are called for all kinds of non-content input like interface
messages and don't have the necessary context to know what kind of
input is being parsed), but it is called when the parsing has
already finished.

The intention is to provide a convenient location for ParserOutput
modifications which depend on some global property of the parsed
content, but need to happen before LinksUpdate. Currently there are
no hooks between parsing (initiated by WikiPage::doEditUpdates()
calling WikiPage::prepareContentForEdit()) and updating the link
tables (initiated by the same method calling
Content::getSecondaryDataUpdates()), so any hook an extension would
try to use would face one of the following problems:
* the parsing output is not available yet
* LinksUpdate has run already, modifying list properties is unsafe
* there is not enough context to tell what's being parsed

A typical use of this hook would be to add tracking categories when
something is missing from the text (e.g. there are no references).
For the concrete use case, see I43ed79b6a54cd31820ecae8139e29c5880f5dd1b

Alternative approaches that have been suggested and do not require
a new hook but are not robust / do not rely on a clear contract:
* use ParserAfterTidy or a similar hook, assume that the input
  being parsed is the main page content iff limit reporting is
  enabled
* use ParserAfterTidy or a similar hook, assume that the input
  being parsed is the main page content iff
  ParserOptions::getInterfaceMessage() is false (this would yield
  some false positives, but in those cases adding a tracking
  category would probably have no effect)

Change-Id: I685b285fcc772382993116f7822a832eeecc0681
RELEASE-NOTES-1.25
docs/hooks.txt
includes/content/AbstractContent.php