Priority: Urgent
Current State: Closed
Released In: 1.1.0
Target Release: minor
Applies To: Engine
Component:
Branches:
This is trunk only
This is a bug injected because of the code changes of TOC in trunk.
Here is an example
Blabla
Blabla
Blabla
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