Item9423: TOC is broken if a header contains wikiword link as first word

This is trunk only

This is a bug injected because of the code changes of TOC in trunk.

Here is an example

Some header

Blabla

Some other header

Blabla

PatternSkin is a nice skin

Blabla

I am happy with TablePlugin

Notice the TOC links. The ones that contain a wikiword do not link down to the anchor but to the wikiword. You never want the links in the TOC to be broken like this. The TOC links must always link to the anchors.

Yet another release blocker.

-- KennethLavrsen - 01 Aug 2010

Found root cause

Yet another code refactoring related bug

-- KennethLavrsen - 01 Aug 2010

Checked in fix but it is only half a solution.

The anchors are still broken. They are genrated from the rendered text instead of the raw.

The unit tests are so basic and useless that they do not show the problem.

I suspect the problem is related to FindElsewherePlugin

-- KennethLavrsen - 01 Aug 2010

Yes.

The problem is when you use WikiWords that are rerendered by FindElsewherePlugin.

In 1.0.9 the anchors are generated before the handler that find elsewhere is using.

In 1.1.0 the anchors are generated after. Or maybe regenerated. Problem is that the anchor in TOC is without the encoded square brackets.

Different bug than this. I will open a new.

-- KennethLavrsen - 01 Aug 2010

Nope.

The order is the same. Problem seems to be related to a square bracket is now encoded as _91 and _93. That is new in trunk.

But this encoding is not happening if they were added by FindElsewherePlugin.

What other plugins will create same problem?

Is the TOC called earlier now after the refactoring?

-- KennethLavrsen - 01 Aug 2010

Fixed in Item9426

-- KennethLavrsen - 02 Aug 2010

Unit tests for this bug checked in

Closing as it was not in 1.0.9

-- KennethLavrsen - 02 Aug 2010

Commenting is disabled while not logged in