Last modified: 2012-03-30 14:04:50 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 T37382, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 35382 - Tag hook: recursiveTagParse() - TOC not loaded
Tag hook: recursiveTagParse() - TOC not loaded
Status: NEW
Product: MediaWiki
Classification: Unclassified
Parser (Other open bugs)
unspecified
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-03-21 12:50 UTC by Subfader
Modified: 2012-03-30 14:04 UTC (History)
2 users (show)

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


Attachments

Description Subfader 2012-03-21 12:50:21 UTC
<foo>
== Heading 1 ==
Text

== Heading 2 ==
Text

== Heading 3 ==
Text
</foo>

This creates no TOC.

<foo>
__TOC__
...

This forces the TOC, but is a lame workaround.

__TOC__
== Heading 1 ==

<foo>
__TOC__
== Heading 2 ==
</foo>

This creates 2 TOCs so it clearly is bug that needs a fix.

Support desk discussion: http://www.mediawiki.org/wiki/Thread:Project:Support_desk/Tag_hook:_recursiveTagParse%28%29_-_TOC_not_loaded
Comment 1 Subfader 2012-03-23 13:24:45 UTC
Same for ref-tags inside tags:

<foo>
Text text.<ref name="bar" />
</foo>

Thuis returns a UNIQ error.

Raising importance level to "normal". It's not a minro issue imo.
Comment 2 Mark A. Hershberger 2012-03-23 16:08:07 UTC
(In reply to comment #1)

> Raising importance level to "normal". It's not a minro issue imo.

How often is this problem seen?
Comment 3 Bawolff (Brian Wolff) 2012-03-24 00:10:28 UTC
(In reply to comment #1)
> Same for ref-tags inside tags:
> 
> <foo>
> Text text.<ref name="bar" />
> </foo>

You're sure that's true on current mediawiki? There was a very similar bug fixed in 1.18.


>How often is this problem seen?

I would put it at  rarely. Very few extensions put headers inside of tag hooks that I am aware of.
Comment 4 Subfader 2012-03-24 12:35:00 UTC
Wiki at work. 1.18.0 iirc.

It doesn't matter how often it is seen imo. A bug is a bug and needs a fix.

Bawolff, can you point me to the recent fix?
Comment 5 Bawolff (Brian Wolff) 2012-03-24 22:28:51 UTC
(In reply to comment #4)
> Wiki at work. 1.18.0 iirc.
> 
> It doesn't matter how often it is seen imo. A bug is a bug and needs a fix.

Well yes, but some bugs need to be fixed more than others ;) 

Note: Just to clarify, by rarely I mean its relatively rare that people make tag extensions that would have the TOC or headers inside the tag. The actual bug appears everytime someone does such a thing.


> Bawolff, can you point me to the recent fix?

r99062. It should be included in 1.18.1 (and 1.18.2). It was not included in 1.18.0
Comment 6 Subfader 2012-03-30 14:04:50 UTC
1.18.0 here and r99062 didn't fix it. 

In LocalSettings.php:

$wgHooks['ParserFirstCallInit'][] = 'efMoreMarkup';
function efMoreMarkup( &$parser ) {
       $parser->setHook( 'gruen', 'efGruenHook' );
      return true;
}
function efGreyHook( $input , $args , $parser )	{
$input = $parser-> recursiveTagParse( $input );
       return '<span class="grey">' . $input . '</span>';
}

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


Navigation
Links