Topic on Project:Support desk/Flow

I'm using tags like

<foo>
== Heading 1 ==
Text

== Heading 2 ==
Text

== Heading 3 ==
Text
</foo>

To create a div around the content:

function efMoreMarkup( &$parser ) {
      $parser->setHook( 'foo', 'efFoo' );
      return true;
}
function efFoo( $input , $args , $parser )	{
      $input = $parser-> recursiveTagParse( $input );
      return '<div class="foo">' . $input . '</div>';
}

But then tag doesn't work and the TOC is not loaded (forcing it via __TOC__ doesn't help). Is there a solution to it so the tag doesn't need to be set below each heading? [MW 1.18.0]

I have the same Problem. Have someone any solution ?

I suppose use a parser function instead of a tag extension is not considered a valid solution? (It would probably fix the issue).

Placing __TOC__ inside the <foo> seems to work in my tests. For example:

<foo>
__TOC__
== Heading 1 ==
Text

== Heading 2 ==
Text

== Heading 3 ==
Text
</foo>

produces a toc on my test wiki.

Note, using parser tags in this manner has some other limitations. Namely <foo> cannot be nested, and PST (processing subst:, pipe trick, and ~~~~) is not done on the contents of foo

The fun part of this is:

__TOC__
==header==

<foo>
__TOC__
==header 2==

</foo>

produces 2 ToC's. I guess its an artifact of when recursiveTagParse happens vs normal header/TOC magic happens.

btw, this should probably be filed as a bug. It probably wouldn't be a trivial fix, so it might languish in bugzilla like many non-trivial parser changes tend to, but its probably somewhat do-able, after all it already has $isMain argument to determine if its coming from a recursiveTagParse

Created a bug report: https://bugzilla.wikimedia.org/show_bug.cgi?id=35382