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: [email protected] [mailto:[email protected]] On Behalf Of Tim Starling Sent: Tuesday, July 10, 2012 5:15 PM To: [email protected] 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 [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-l _______________________________________________ MediaWiki-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
