[Mediawiki-l] Relative order of extension hooks?

Sat Nov 12 20:33:30 UTC 2005

I'm building a MediaWiki drop-in Extension, and it's been very
straightforward

However, I have a few questions, some practical, and another
about the rationale for the current design.

I'd like my Extension to be able to have an effect outside the
 ...  (especially the
<title> and h1.firstHeading values.

But, I can't find a hook that gets a shot at changing the HTML
which includes those. Am I missing one?

Or, is such a hook trampling on the prerogative of Skins, so it
couldn't be sure to find stable patterns to replace?

If so, can the Skin code be sure the article has already been
parsed/HTMLized, so that it could make use of information found
inside the article body?

Regarding the design:

I'm perplexed about the reason Extensions are handled along with
(and after) the html/nowiki/math/pre/gallery stripping.

It seems that if Extensions were by default given a chance to
modify the running text before strip(), they would have a superset
of their current capabilities. For example, they could very easily
generate wikitext to be interpreted later, or provide for Extension
tag expansion/modification of the contents inside <html>/<math>/etc
tags. They wouldn't lose any capability -- if they wanted their
output untouched by later steps, they could insert their own
<nowiki> or <html> tags. If they wanted to refrain from altering
content inside other tags (like <nowiki>), they could receive and
switch on a parameter which helps them understand their context.
(For example, a pseudo-XPath to the current extension tag.)

Is there a compelling reason I'm missing for the current placement,
or was it just a convenient/arbitrary choice at the time?

(I realize that I could hook into the ParserBeforeStrip hook to
achieve the same effect, at the cost of doing the iteration over
found Extension tags directly.)

Thanks for any answers/insights,

- Gordon @ Bitzi