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?
The other is that I'm using FCKEditor, and as expected, selecting "Rich edit" just shows a <special> tag where my tagged text is. It looks like FCKEditor issues haven't been discussed for 4-5 years, but if anyone can point out an article I haven't found yet on how to support new tags, I'd appreciate it. In my case, I just want it to treat the tag like it wasn't there, nothing is blocked while editing.
Any insights would be appreciated, thanks. Sal
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
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@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@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@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
mediawiki-l@lists.wikimedia.org