Howdy,
So tonight I set off writing a short little extension for mediawiki, and got in a fight with the parser.
My extensions characteristics, in short, are that: it takes arguments from my defined tags and the content between the tags, and inserts them into a javascript function.
To make my javascript 'pretty', I like to stick a few \n's in the $input strings (the content between the tags). Of course the parser is more then happy to turn these into:
</p><p><br />
</p><p><br /> </p> <pre>
(for 5 \n's), which really busts up the javascript. :)
http://meta.wikimedia.org/wiki/MediaWiki_extensions_FAQ#How_can_I_avoid_modi... ... implies the parser would have to be mucked with to prevent conversion of the newlines.
But!!!!... a section or two above, it's stated that when you forcibly render text with the parser, you can turn off the <p> tags with a simple 'false': http://meta.wikimedia.org/wiki/MediaWiki_extensions_FAQ#How_do_I_render_wiki...
I'd think it'd be a short step to allow the extension to set a variable, or call a method, essentially giving the parser the same 'false', as when it is called directly: $wgOut->parse('text', false); That sure would make life easier. E.g. $wgParser->setHook( "MyExtension", "renderMyExtension", 'false'); ... or maybe $wgParser->setPtag('false');
Hopefully somebody can tell me if I've missed some easy answer, or this functionality is already there (no, I haven't read through Parser.php yet). Or a second best: that there would be interest into adding this into nearby release?
I'm aware there is probably a 'long way' around this problem, i.e.: set a hook for ParserAfterTidy, then find my tags+content, strip my tags and their args, re-insert my args+content, and finally dump all of the page again... bleh...
Thanks, Luke
Or we could fix the sanitiser to remove all the common crap the parser inserts.
Rob Church
On 05/02/06, LJ lukehjohnson@gmail.com wrote:
Howdy,
So tonight I set off writing a short little extension for mediawiki, and got in a fight with the parser.
My extensions characteristics, in short, are that: it takes arguments from my defined tags and the content between the tags, and inserts them into a javascript function.
To make my javascript 'pretty', I like to stick a few \n's in the $input strings (the content between the tags). Of course the parser is more then happy to turn these into:
</p><p><br />
</p><p><br /> </p> <pre>
(for 5 \n's), which really busts up the javascript. :)
http://meta.wikimedia.org/wiki/MediaWiki_extensions_FAQ#How_can_I_avoid_modi... ... implies the parser would have to be mucked with to prevent conversion of the newlines.
But!!!!... a section or two above, it's stated that when you forcibly render text with the parser, you can turn off the <p> tags with a simple 'false': http://meta.wikimedia.org/wiki/MediaWiki_extensions_FAQ#How_do_I_render_wiki...
I'd think it'd be a short step to allow the extension to set a variable, or call a method, essentially giving the parser the same 'false', as when it is called directly: $wgOut->parse('text', false); That sure would make life easier. E.g. $wgParser->setHook( "MyExtension", "renderMyExtension", 'false'); ... or maybe $wgParser->setPtag('false');
Hopefully somebody can tell me if I've missed some easy answer, or this functionality is already there (no, I haven't read through Parser.php yet). Or a second best: that there would be interest into adding this into nearby release?
I'm aware there is probably a 'long way' around this problem, i.e.: set a hook for ParserAfterTidy, then find my tags+content, strip my tags and their args, re-insert my args+content, and finally dump all of the page again... bleh...
Thanks, Luke _______________________________________________ MediaWiki-l mailing list MediaWiki-l@Wikimedia.org http://mail.wikipedia.org/mailman/listinfo/mediawiki-l
Cynicism aside Rob, I appreciate the reply.
Did a bit more digging, and found this 'bug' in bugzilla: http://bugzilla.wikimedia.org/show_bug.cgi?id=1772 Seems like it's been around awhile. I updated the version, added a note, and voted for it.
For the time being I can work around it by limiting the text I insert between my tags (no newlines). However, I'd like to publish my extension, and I'm unlikely to do so if I have to have the caveat of: 'you have to format the tagged content just-so...'.
Don't know if my previous global flag or callable method ideas have much merit ( or are feasible to integrate into the parser structure ). But, it'd be nice if a developer latched on to them... :)
LJ
On 2/4/06, LJ lukehjohnson@gmail.com wrote:
Howdy,
So tonight I set off writing a short little extension for mediawiki, and got in a fight with the parser.
My extensions characteristics, in short, are that: it takes arguments from my defined tags and the content between the tags, and inserts them into a javascript function.
To make my javascript 'pretty', I like to stick a few \n's in the $input strings (the content between the tags). Of course the parser is more then happy to turn these into:
</p><p><br />
</p><p><br /> </p> <pre>
(for 5 \n's), which really busts up the javascript. :)
http://meta.wikimedia.org/wiki/MediaWiki_extensions_FAQ#How_can_I_avoid_modi... ... implies the parser would have to be mucked with to prevent conversion of the newlines.
But!!!!... a section or two above, it's stated that when you forcibly render text with the parser, you can turn off the <p> tags with a simple 'false':
http://meta.wikimedia.org/wiki/MediaWiki_extensions_FAQ#How_do_I_render_wiki...
I'd think it'd be a short step to allow the extension to set a variable, or call a method, essentially giving the parser the same 'false', as when it is called directly: $wgOut->parse('text', false); That sure would make life easier. E.g. $wgParser->setHook( "MyExtension", "renderMyExtension", 'false'); ... or maybe $wgParser->setPtag('false');
Hopefully somebody can tell me if I've missed some easy answer, or this functionality is already there (no, I haven't read through Parser.phpyet). Or a second best: that there would be interest into adding this into nearby release?
I'm aware there is probably a 'long way' around this problem, i.e.: set a hook for ParserAfterTidy, then find my tags+content, strip my tags and their args, re-insert my args+content, and finally dump all of the page again... bleh...
Thanks, Luke
Moin,
On Monday 06 February 2006 06:17, LJ wrote:
Cynicism aside Rob, I appreciate the reply.
Did a bit more digging, and found this 'bug' in bugzilla: http://bugzilla.wikimedia.org/show_bug.cgi?id=1772 Seems like it's been around awhile. I updated the version, added a note, and voted for it.
For the time being I can work around it by limiting the text I insert between my tags (no newlines). However, I'd like to publish my extension, and I'm unlikely to do so if I have to have the caveat of: 'you have to format the tagged content just-so...'.
Don't know if my previous global flag or callable method ideas have much merit ( or are feasible to integrate into the parser structure ). But, it'd be nice if a developer latched on to them... :)
Btw, the Graph::Easy extension (returing HTML) also runs into this. Even when you add no emoty lines and leading spaces, mediawiki seems to insert a paragraph every N lines or so. This of course creates wierd empty spaces in the generated table :(
In the end I stripped *ever* \n from the output and now return a gigantous long line.
A way to switch this off from my extension would be great, because the emitted HTML becomes impossible to debug or inspect.
Best wishes,
Tels
[got to this one a little late... for those who've forgotten, empty lines in the javascript output of LJ's parser hook extension were being enclosed in <p></p> by the parser]
On Mon, 06 Feb 2006 18:40:13 +0100, Tels wrote:
Moin,
On Monday 06 February 2006 06:17, LJ wrote:
Cynicism aside Rob, I appreciate the reply.
Did a bit more digging, and found this 'bug' in bugzilla: http://bugzilla.wikimedia.org/show_bug.cgi?id=1772 Seems like it's been around awhile. I updated the version, added a note, and voted for it.
For the time being I can work around it by limiting the text I insert between my tags (no newlines). However, I'd like to publish my extension, and I'm unlikely to do so if I have to have the caveat of: 'you have to format the tagged content just-so...'.
Don't know if my previous global flag or callable method ideas have much merit ( or are feasible to integrate into the parser structure ). But, it'd be nice if a developer latched on to them... :)
Btw, the Graph::Easy extension (returing HTML) also runs into this. Even when you add no emoty lines and leading spaces, mediawiki seems to insert a paragraph every N lines or so. This of course creates wierd empty spaces in the generated table :(
In the end I stripped *ever* \n from the output and now return a gigantous long line.
A way to switch this off from my extension would be great, because the emitted HTML becomes impossible to debug or inspect.
I've had a similar problem with cells for a summary table being too bloated when the content is enclosed in <p></p> tags.
My solution was the "'long way' around" as LJ put it - preemptively add identifiable paragraph tags within the tag rendering hook, within an identifiable block, and then remove them in a ParserBeforeTidy hook. Doing this properly also required escaping any preexisting such block markers in a ParserBeforeStrip hook - all in all an inefficient schlep and I agree that a method of indicating to the parser that it should avoid paragraph tag insertion for any given hook would be useful.
Ultimately it works though, without needing to return all content on a single line or otherwise give up formatting, and the approach could be adapted for newlines - the tag rendering function would enclose itself in the block markers and convert empty lines to the pair of identifiable paragraph tags.
For reference, the tags I'm using are <p class="remove"> and </p >, and the block markers are __STARTREMOVEPARA__ and __ENDREMOVEPARA__.
Also, LJ, you originally wrote:
a section or two above, it's stated that when you forcibly render text with the parser, you can turn off the <p> tags with a simple 'false'
Iirc, this only applies to the first line of text provided to the parse function - later lines will be enclosed in <p></p> tags as usual.
mediawiki-l@lists.wikimedia.org