• Conflict of two features (each works well independently)

Calling plugins in headings in pages where maketoc is used can cause breakage. For example, this happens when calling the ANAME or FOOTNOTE plugins.

Effect on ANAME

Although Tiki generates anchors for all headings automatically, I find using ANAME is a great way of creating manageable and easily memorable Anchors for otherwise unwieldy headings
If a heading within a tiki page is coded as follows

!! Fourth and Even More Forgetful Heading{ANAME()}Quick4{ANAME}

<h3 class="showhide_heading" id="Fourth_and_Even_More_Forgetful_Heading">  Fourth and Even More Forgetful Heading<a id="Quick4"></a></h3>

{ALINK(aname=Quick4)}Link to Fourth Heading by its Quick4 Anchor{ALINK}

However, add MAKETOC to the page above the source line where ANAME is last used and it breaks the ANAME anchor(s). For this example, the maketoc is restricted to level 2 headings only as {maketoc levels="2"} which makes the generated HTML a little more compact.
Tiki generates the following HTML in response to the inclusion of maketoc

<ul><li><a href='#First_Level_Two_Heading' class='link'> First Level Two Heading</a>
</li><li><a href='#Second_Long_and_Equally_Unmemorable_Heading' class='link'> Second Long and Equally Unmemorable Heading</a>
</li><li><a href='#Third_Painfully_Difficult_Heading' class='link'> Third Painfully Difficult Heading</a>
</li><li><a href='#Fourth_and_Even_More_Forgetful_Heading' class='link'> Fourth and Even More Forgetful Heading<a id="Quick4"></a></a>
</li><li><a href='#Fifth_Long_and_Not_Very_Memorable_Heading' class='link'> Fifth Long and Not Very Memorable Heading</a>
</li></ul></li></ul><!--toc--></div><br />

The effect of this is that the tiki anchor Quick4 is now incorrectly linked to the TOC entry, being the first instance of HTML ANCHOR within the HTML file.

If the MAKETOC plugin is included below the ANAME, then the ANAME works as intended, since that is the first occurrence of the generated HTML ANCHOR statement.

I have a couple of test pages which illustrate this issue, if they are of any use in your testing.

Effect on FOOTNOTE

Calling FOOTNOTE returns an HTML A element with an id, so using that same identifier twice causes invalid HTML. Additionally, since browsers favor the first element using the identifier in such cases, the TOC's instance wins if {maketoc} precedes headings, which is not what we want.

Cause

Plugin calls are executed in parse_first(). (Calls to plugins in "html" format are replaced by alphanumeric fingerprints.) After, parse_data_process_maketoc() is called and expands "{maketoc}" to headings, so that each plugin call in a heading in the TOC has its result (or fingerprint) twice in the source. (After, replace_preparse() replaces fingerprints with the result of plugin functions (stored during parse_first's execution).)

This issue happens because maketoc therefore causes a plugin call's result to be repeated in the TOC (instead of possibly executed again specifically for TOC-s), which has 2 problems:

• plugins don't expect their output included twice in the page, so some (such as ANAME) may use HTML's id attribute in a manner incompatible with maketoc, causing invalid HTML
• plugins don't expect their output to be included in an HTML A element, so some (such as FOOTNOTE) for example generate links themselves, again causing invalid HTML

I believe there is no general solution to this. Each plugin needs to adapt its behavior when the output is to be used in a heading. For example, SUP can return the same thing, but ANAME should return nothing.

A solution could be implemented by potentially calling a plugin function twice per in-heading plugin call. With an extra parameter indicating a call for a TOC, FOOTNOTE could return just text, no link. However, if there are 2 independent calls, it would be hard for FOOTNOTE to know that it should return the same number.

wikiplugin_foo_info() could return an extra "headings" array element indicating what to do if the plugin is called in a heading. For SUP, this could be "'headings' => 'same'". For the GOOGLEANALYTICS plugin, the value could be "ignore".

Unfortunately, in order to do that, we need to distinguish headings before plugins are called. As of r66644, plugins are called (in parse_first()) well before headings are distinguished (in parse_data_process_maketoc()).

Dirty hack

The 2 patches attached provide a dirty solution which seems to work well on UTF-8 databases. These would need validation for compatibility with other encodings before being integrated.

The very same patch works verbatim against Tiki 15 too.

This is very much of a hack and may very well cause regressions.

This bug has been demonstrated on show2.tiki.org

Please demonstrate your bug on show2.tiki.org