Thanks Tim. I tried it out, and oddly enough it didn't behave consistently.
Sometimes it print the text for the edit link (e.g. "[<a
href="/xxx/index.php?title...]") next to the first header, with edit links
working in the following headers, and other times it only showed the text
with no links... and now it's doubling the header numbers. But when it did
work, at least the edit link worked right. I guess I'll work on upgrading
MW and trying this again.
Regards,
Sal
-----Original Message-----
From: mediawiki-l-bounces(a)lists.wikimedia.org
[mailto:mediawiki-l-bounces@lists.wikimedia.org] On Behalf Of Tim Starling
Sent: Tuesday, July 10, 2012 5:15 PM
To: mediawiki-l(a)lists.wikimedia.org
Subject: Re: [MediaWiki-l] recursiveTagParse() side effects
On 11/07/12 02:08, Sal Quintanilla wrote:
I'm working on a tag extension that prevents
rendering of blocked
output under certain circumstances. It either does or does not use
recursiveTagParse() to do the right thing for blocks between my
<block></block> pairs. It works exactly the way I want it to, but I've
got
a couple of side effects.
The biggest one is that when headers are involved, the section edit
links report "Cannot find section" when clicked. I'm not sure what to
do about that, any ideas?
By wrapping headings in an xmlish tag, you are hiding them from
Parser::extractSections(), which doesn't call your extension to expand them.
I'm not sure if it's fixable. You could try using
Parser::setTransparentTagHook() instead of Parser::setHook().
-- Tim Starling
_______________________________________________
MediaWiki-l mailing list
MediaWiki-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/mediawiki-l