Features / Usability

Features / Usability

Wiki link syntax: Extrange behaviour with !-titles and Wiki Links

posts: 956

Hi there:

I post this comment here because I don't know it the problem is related to the type of Wiki link syntax I have preconfigured (complete in my case, no idea on tw.o), or it is something related to a bug (already posted, in a similar form, at sf.net tw.o-bug-reports).

When there is a Wiki link (either WikiWord or forced with double parenthesis), combined with a title mark (!), some extrange behaviour occurs, especially with the double parenthesis. See the example below.

This code:

1 ((New Page)) 2 New Page)) 3 ((New Page 4 ((NewPage)) 5 NewPage)) 6 ((NewPage ! 7 ((New Page)) ! 8 New Page)) ! 9 ((New Page ! 10 ((NewPage)) ! 11 NewPage)) ! 12 ((NewPage

Produces (on Tiki 1.8.4 and 1.9.CVS - here-):

1 New Page
2 New Page))
3 ((New Page

4 NewPage
5 NewPage))
6 ((NewPage

7 New Page

8 New Page))

9 ((New Page

10 NewPage

11 NewPage))

12 ((NewPage

Well, examples in lines 3, 5, 9, and 11 don't produce the expected result. Shouldn't they show the double parenthesis on the text? Is this because the type of wiki link syntax especified at Admin>Wiki>Wiki link format ? Is this something related to a bug?

This strange thing is not important, but if you add instead of one link to a !-title, two Wiki links, the some wrong behaviour may occur (for the curious, see the longer bug report at sf.net )

posts: 32

I too have been bitten by this problem

For me it occurs on pages where there is more than one instance of (( )) ie you're forcing a link, or preventing a link more than once, seems to work fine if you only have one on a page


))DontTurnthisIntoALink(( some text blah blah blah ))DontMake this a link either((

What I think is happening is it's not seeing the first )) and instead was reading (( some text blah blah blah )) and turning this into a forced link

I cannot remember exactly what versions I checked out, but I think I found this to be a problem from 1.76 onwards - I've not had time to look into it yet myself, but noticed that the 1.61 parsing function IS NOT affected by this, so I reverted back to that (with the loss of some functionality).

I plan to address this when I get a chance if nobody else does first.