Last modified: 2010-05-15 15:41:04 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 7417 - Preformatted multiline text in lists doesn't work anymore
Preformatted multiline text in lists doesn't work anymore
Status: RESOLVED DUPLICATE of bug 1581
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
PC Linux
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: parser
Depends on:
  Show dependency treegraph
Reported: 2006-09-26 13:43 UTC by Ingo Rohloff
Modified: 2010-05-15 15:41 UTC (History)
0 users

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Description Ingo Rohloff 2006-09-26 13:43:48 UTC
The following worked before (Mediawiki 1.6.?) :
# Line A
# Line B <pre><nowiki>
  This is a multiline
  text inside a list
# Line C

With Mediawiki 1.7.1 this is rendered wrong. (The multiline will break the
numbered list.)

I already found out what the problem is: 
In includes/Parse.php  the strip() method changed (since mediawiki 1.6.?). 
This method calls Parser::extractTagsAndParams() to replace all tags with unique
Later these unique identifiers are then "unstripped" again to render the page.

Now the new scheme how the tags are unstripped unfortunately doesn't handle
nested tags
(like in the above <pre><nowiki> example).

Mediawiki 1.6.? first searched for "nowiki" tags and then for other tags.

With the current MediaWiki 1.7.1 this order isn't used anymore, which results in
the bug
(The <pre> is found first, which seems to prevent the <nowiki> tag to get parsed
in the
 "right" way.)

I think in general the nesting of tags has to be fixed more thoroughly at a
later point of time.

Anyway: for the described problem here is a patch which solves it:

-----------------------Snip --------------------

diff -ur mediawiki-1.7.1/includes/Parser.php
--- mediawiki-1.7.1/includes/Parser.php 2006-07-09 07:45:26.000000000 +0200
+++ /srv/www/htdocs/wiki/includes/Parser.php  2006-09-07 17:53:06.294627168 +0200
@@ -478,7 +478,7 @@
    $commentState = array();

    $elements = array_merge(
-     array( 'nowiki', 'gallery' ),
+     array( 'gallery' ),
      array_keys( $this->mTagHooks ) );
    global $wgRawHtml;
    if( $wgRawHtml ) {
@@ -493,10 +493,14 @@
      if ( !in_array ( $v , $dontstrip ) ) continue;
      unset ( $elements[$k] );
-   $matches = array();
-   $text = Parser::extractTagsAndParams( $elements, $text, $matches,
$uniq_prefix );

+   $matchesNoWiki = array();
+   $matchesOthers = array();
+   $text = Parser::extractTagsAndParams( array('nowiki'), $text,$matchesNoWiki,
$uniq_prefix );
+   $text = Parser::extractTagsAndParams( $elements, $text, $matchesOthers,
$uniq_prefix );
+   $matches = array_merge($matchesNoWiki, $matchesOthers);
    foreach( $matches as $marker => $data ) {
      list( $element, $content, $params, $tag ) = $data;
      if( $render ) {

-----------------------Snip --------------------

Actually with this patch, the "renderPreTag" method in Parser.php should work
without the
"Backwards-compatibility hack", but I haven't tried that.
Comment 1 Brion Vibber 2006-09-26 14:43:13 UTC

*** This bug has been marked as a duplicate of 1581 ***

Note You need to log in before you can comment on or make changes to this bug.