Last modified: 2011-04-14 15:11:22 UTC
the attached micro-extension puts an HTML comment into the page's wikitext. Originally this comment was a way of passing information to a later phase of the extension's processing. However, when previewing a page, this causes extra line breaks to appear between the form fields at the bottom of the edit form. I'm mystified. I guess I'm not supposed to introduce HTML comments in the wikitext during parsing? This "EditDisruptor" extension works on MW 1.13 as well as the current svn trunk.
Could not attach the php file. Here it is: <?php $wgHooks['ParserAfterTidy'][] = 'edit_disruptor'; function edit_disruptor( &$parser, &$text ) { $text .= "\n<!-- comment -->\n"; return true; } ?>
Wikitext parsing is used in a lot of places in the UI, not just for displaying article pages, and those line breaks are indeed likely to muck things up. You might be wanting another hook (something for display? or something specific to articles, or at least just checking what title you're processing?)
To clarify: that code there is a minimal example to reproduce the bug. The actual extension that has the problem attaches a more meaningful comment to the page text (in its ParserAfterTidy hook) only at the appropriate times. The purpose is to inject information into the parser cache, so it can be used to customize the sidebar depending on what's in the page, without requiring the page to be parsed on every view. Using this HTML comment to pass armored information through the parser apparently does nothing bad to the parser, the parsed wikitext looks fine, but then it somehow causes wfMsgExt() to fail to strip the p tags from the labels attached to the form controls at the bottom of the edit form. The form controls are strewn across multiple lines and look obviously wrong in the browser. This is bizarre behavior, and can't possibly be desirable. What's going on?
maybe you're right that it's doing that by disrupting parsing of the UI elements. I'm going to give it a closer look.
Yes, it's because sticking that comment on the end of the parsed messages interferes with the regexp it uses to remove p tags. I need to work out how to get that material into the parser cache without messing up the other parser operations.
Thanks for giving me the hint I needed!
You can try to use ParserLimitReport hook (http://www.mediawiki.org/wiki/Manual:Hooks/ParserLimitReport) which is called when adding the "limit report" comment, or even better, use the page_props table to save this information (see ParserOutput::setProperty()).