Hi,
I have an extension called BugSquish, which I have been happily using on MediaWiki 1.6.10 for quite a long time. I am also aware of other people using it on later versions, but cannot cite specific version numbers where it is known to work. The code works by performing a regex replace on code passed into the ParserAfterStrip hook function that I have set up, to strike out links to bugs that have been marked as fixed.
On MW 1.6 this correctly handles <nowiki> and <pre> tags, in that text within these tags is not parsed by the extension.
On MW 1.14 and above the code within the <nowiki> tags is parsed and ends up having the regex applied to it, though it is subsequently rendered as plain text by the engine (so the page ends up being filled with HTML/CSS gobbledygook, rendered literally).
I am not sure at which revision this change took place.
First question: Is this a bug or a deliberate change in functionality, or have I been mis-using the hook all along? Second question: Assuming this is not a bug, how should I rewrite the code to make it behave as it used to?
The current code for the extension is available here, if you want to test: http://www.kennel17.co.uk/testwiki/BugSquish
Cheers,
- Mark Clements (HappyDog)
On Tue, Oct 6, 2009 at 4:47 PM, Mark Clements (HappyDog) gmane@kennel17.co.uk wrote:
Hi,
I have an extension called BugSquish, which I have been happily using on MediaWiki 1.6.10 for quite a long time. I am also aware of other people using it on later versions, but cannot cite specific version numbers where it is known to work. The code works by performing a regex replace on code passed into the ParserAfterStrip hook function that I have set up, to strike out links to bugs that have been marked as fixed.
On MW 1.6 this correctly handles <nowiki> and <pre> tags, in that text within these tags is not parsed by the extension.
On MW 1.14 and above the code within the <nowiki> tags is parsed and ends up having the regex applied to it, though it is subsequently rendered as plain text by the engine (so the page ends up being filled with HTML/CSS gobbledygook, rendered literally).
I am not sure at which revision this change took place.
First question: Is this a bug or a deliberate change in functionality, or have I been mis-using the hook all along?
This was changed during the parser rewrite several versions ago. The restructuring of the parser meant that strip markers are now handled differently and can't be routed around using that hook anymore. ParserAfterStrip is essentially a deprecated legacy that now functions the same way as ParserBeforeStrip.
Second question: Assuming this is not a bug, how should I rewrite the code to make it behave as it used to?
I haven't studied you code in detail, but I would suggest that using the LinkBegin hook (available 1.14+) is probably the right place to look in the current versions of Mediawiki:
http://www.mediawiki.org/wiki/Manual:Hooks/LinkBegin
This is called whenever an internal / interwiki link is generated and allows one modify the text / destination, apply CSS styles, and/or replace the link with something else entirely.
If you are munging external links (rather than internal / interwiki links), the corresponding hook is LinkerMakeExternalLink.
-Robert Rohde
"Robert Rohde" rarohde@gmail.com wrote in message news:b4da1c6e0910061725m326860f1i402edfd9e66293cd@mail.gmail.com... On Tue, Oct 6, 2009 at 4:47 PM, Mark Clements (HappyDog) gmane@kennel17.co.uk wrote: [SNIP - Re: ParserAfterStrip]
On MW 1.14 and above the code within the <nowiki> tags is parsed and ends up having the regex applied to it, though it is subsequently rendered as plain text by the engine (so the page ends up being filled with HTML/CSS gobbledygook, rendered literally).
I am not sure at which revision this change took place.
First question: Is this a bug or a deliberate change in functionality, or have I been mis-using the hook all along?
This was changed during the parser rewrite several versions ago. The restructuring of the parser meant that strip markers are now handled differently and can't be routed around using that hook anymore. ParserAfterStrip is essentially a deprecated legacy that now functions the same way as ParserBeforeStrip.
I have updated the page on MW.org [1] to explain this. However, can someone confirm that this is a deliberate change? To me it seems like a regression that has not been spotted! (Or is it that the parser has changed to the point where it is no longer possible to have a ParserAfterStrip hook?)
Second question: Assuming this is not a bug, how should I rewrite the code to make it behave as it used to?
I haven't studied you code in detail, but I would suggest that using the LinkBegin hook (available 1.14+) is probably the right place to look in the current versions of Mediawiki:
Thanks - I ended up needing a combination of LinkBegin/LinkEnd to get the result I wanted. You can see the code at http://www.kennel17.co.uk/testwiki/BugSquish
Thanks for your help,
- Mark Clements (HappyDog)
[1] http://www.mediawiki.org/wiki/Manual:Hooks/ParserAfterStrip
On Thu, Nov 12, 2009 at 5:00 AM, Mark Clements (HappyDog) gmane@kennel17.co.uk wrote: <snip>
This was changed during the parser rewrite several versions ago. The restructuring of the parser meant that strip markers are now handled differently and can't be routed around using that hook anymore. ParserAfterStrip is essentially a deprecated legacy that now functions the same way as ParserBeforeStrip.
I have updated the page on MW.org [1] to explain this. However, can someone confirm that this is a deliberate change? To me it seems like a regression that has not been spotted! (Or is it that the parser has changed to the point where it is no longer possible to have a ParserAfterStrip hook?)
It was a willful change. The parser rewrite eliminated stripping as a distinct step. Originally nowikis and the like were removed and replaced with strip markers at the beginning of parser processing, so there was a distinct parser step involved with stripping. The current parser no longer takes this approach and simply adds strip markers as needed whenever it encounters them during processing of the page. Since this occurs within the flow of the rest of the parser operations, there no longer is a point where the parser has done only strip tag removal, and hence there is no point for a ParserAfterStrip to attach itself to.
-Robert Rohde
"Robert Rohde" rarohde@gmail.com wrote in message news:b4da1c6e0911120739o1636328j37f56a01ceccf6b2@mail.gmail.com... On Thu, Nov 12, 2009 at 5:00 AM, Mark Clements (HappyDog) gmane@kennel17.co.uk wrote: <snip>
This was changed during the parser rewrite several versions ago. The restructuring of the parser meant that strip markers are now handled differently and can't be routed around using that hook anymore. ParserAfterStrip is essentially a deprecated legacy that now functions the same way as ParserBeforeStrip.
I have updated the page on MW.org [1] to explain this. However, can someone confirm that this is a deliberate change? To me it seems like a regression that has not been spotted! (Or is it that the parser has changed to the point where it is no longer possible to have a ParserAfterStrip hook?)
It was a willful change. [explanation snipped]
Thanks, Robert, for clearing that up.
- Mark Clements (HappyDog)
wikitech-l@lists.wikimedia.org