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

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T9417, the corresponding Phabricator task for complete and up-to-date bug report information.
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)
1.7.x
PC Linux
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: parser
Depends on:
Blocks:
  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: ---


Attachments

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
  </nowiki></pre>
# 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
identifiers.
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
/srv/www/htdocs/wiki/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.


Navigation
Links