./TracLinks does not work

[conny@…]

Quoting the manual:

To create a link to a SubWiki-page just use a '/':

 WikiPage/SubWikiPage or ./SubWikiPage

but in "/wiki/mypage" the link:

[wiki:./subpage]

creates a link to

/wiki/subpage

instead of the expected:

/wiki/mypage/subpage

[Christian Boos]

You're right, there seem to be a problem when the explicit wiki: prefix is given.

In the meantime, you can use:

[./subpage]

(["./subpage"] seems to have the same problem than [wiki:./subpage])

[osimons]

Replying to cboos:

You're right, there seem to be a problem when the explicit wiki: prefix is given.

Why should this link syntax actually work? The relative ([./TheSubPage] and [../OtherPage]) and absolute ([/wiki/ThePage]) will generate all sorts of issues if mixed with realms. To me it makes no sense to mix resource/project context-aware links with realm/provider link style.

They are different link styles for different purposes, and should be treated as such.

[Christian Boos]

Thanks for the feedback, it made me think a bit more thoroughly about the issue. I think that this is purely a wiki link resolver issue that can and should be handled in WikiSystem._format_link​.

The current problem is more visible with .. links: wiki:"../other" is not taking you to a sibling page, but to /other (replacing the /wiki part), which is not good and doesn't make sense, as you specified wiki:.... I consider this to be a bug, due to pagename == "../other" in the context of line 326 in _format_link:

 href = formatter.href.wiki(pagename, version=version) ...

This is not blocking 0.11 - would be nice to have but not necessary.

Note that when written from a ticket like here, that link won't make sense anyway - but this is also a situation we can detect in _format_link.

[anonymous]

OK thats goog

[osimons]

#7388 closed as duplicate.

It basically makes a note about the 'Missing Page' link style not being supported by relative and absolute links. I suppose if we arrive at fully supporting such syntax as context-aware, then by definition it should also generate correctly formatted links.

[Christian Boos]

See also the discussion in #4416, in particular comments 6 and 11.

[Christian Boos]

There's also the problem of [#id ... ] links, also handled by the same code.

One problem I just noticed with r7777 is that it won't work at all with the composite ids stuff of MultiRepos.

But even if we ditch the composite ids, r7777 is making assumptions about how the links are formed (using _make_link(resource.realm, target,..., with target = unicode(resource.id)). This will break anything that doesn't follow that schema, as the path = get_resource_url above is actually ignored.

[shookie@…]

simple workaround fix

[shookie@…]

I have a workaround for the problem, which has the advantage of being very small and limited to one place: an additional check in Formatter._lhref_formatter. Because as has been said, when using the wiki:./path syntax, it doesn't recognize relative paths.

A real solution would involve finding out why the line

            result = re.sub(self.wikiparser.rules, self.replace, line)

in Formatter.format doesn't fill the <rel> match, which in turn means tinkering with the LHREF_RELATIVE_TARGET regex in WikiParser. But that is part of such a big convoluted regex that it's easy to mess up, so it will probably take a while.

The workaround fix is attached as a diff now.

Regards

Jan Schukat

[shookie@…]

Looked at the regular expressions in WikiParser. The <rel> group cannot be filled by the big matcher regex for links with the namespace prefix, since a group name can only be given once in an regex. So there are two alternative ways to tell Formattter._lhref_formatter that it actually has a relative link with a namespace:

1. Check the linktarget from the <ltgt> group with the WikiParser.LHREF_RELATIVE_TARGET regex + only have to change one place, (similarly to the crude workaround I posted before)
2. Introduce a new group <nsrel> in the big WikiParser._post_rules, that it should check additionally to <rel>
   • need to change Formatter, and WikiParser
   • need to add additional code to deal with quotes
   • big expansion in the big rules regexp ? if anyone refers to groups in the rules by index, that would be broken now, but that would be bad style anyway, so hopefully no one did that

Probably should take the patch that is more efficient, but that's hard to without real profiling. Maybe even pre-compile the regex in patch #1.

I tend towards patch #1 atm.

[shookie@…]

small patch that re-checks the link target

[shookie@…]

big patch that alters the central rules regex

[Remy Blank]

I'll look into that.

[Remy Blank]

Relative page references in wiki: links have been added in [8732]. As suspected in comment:3, this could be solved in WikiSystem._format_link(). Only leading .. and . path components are interpreted: for example, [wiki:MyPage/../OtherPage] is left intact.

[anonymous]

The title of the ticket suggests that this ticket it is about ./ links in general.

Looking at the patch in [8732], the tests in source:trunk/trac/wiki/tests/wikisyntax.py?rev=9541​ as well as the documentation it seems to fix only part of the problem. (Is there another related ticket for the following problem??)

WikiPage/SubWikiPage or ./SubWikiPage or ../WikiPage/SubWikiPage

[WikiPage/SubWikiPage] or [./SubWikiPage] or [../WikiPage/SubWikiPage] 

[wiki:WikiPage/SubWikiPage] or [wiki:./SubWikiPage] or [wiki:../WikiPage/SubWikiPage]

generates

<a class="missing wiki" href="/demo-0.12/wiki/WikiPage/SubWikiPage" rel="nofollow">Wiki Page/Sub Wiki Page?</a> or ./SubWikiPage or ../WikiPage/SubWikiPage
</p>
<p>
[<a class="missing wiki" href="/demo-0.12/wiki/WikiPage/SubWikiPage" rel="nofollow">Wiki Page/Sub Wiki Page?</a>] or <a class="missing wiki" href="/demo-0.12/wiki/WikiPage/SubWikiPage" rel="nofollow">Sub Wiki Page?</a> or <a class="missing wiki" href="/demo-0.12/wiki/WikiPage/SubWikiPage" rel="nofollow">Wiki Page/Sub Wiki Page?</a> 

</p>
<p>
<a class="missing wiki" href="/demo-0.12/wiki/WikiPage/SubWikiPage" rel="nofollow">Wiki Page/Sub Wiki Page?</a> or <a class="missing wiki" href="/demo-0.12/wiki/WikiPage/SubWikiPage" rel="nofollow">Sub Wiki Page?</a> or <a class="missing wiki" href="/demo-0.12/wiki/WikiPage/SubWikiPage" rel="nofollow">Wiki Page/Sub Wiki Page?</a>

./SubWikiPage and ../WikiPage/SubWikiPage are not expanded

if that is the desired behavior can somebody:

• add test that ommit the "wiki:" Prefix
• change the documentation (TracLinks#Relativelinks) for ./SubWikiPage
• or point to another ticket that marks this as a bug.

[Remy Blank]

The ./SubWikiPage and ../WikiPage/SubWikiPage syntax was never intended to be supported (at least by me), but I can see that it would make sense. Let's add it (PatchWelcome, of course).

[Christian Boos]

But only for CamelCase pages, I'd say, as the risk of collision is quite high, e.g. when people are talking about files (as in "when you're in the lib/ directory, the behavior depends on the ../control.cfg file").

[Remy Blank]

Replying to cboos:

But only for CamelCase pages, I'd say, …

That was my intention, yes. It's probably only a matter of tweaking a regexp, as the resolution mechanism is already implemented. I'll also make sure that absolute references work (/WikiPage).

[Christian Boos]

I suspect that after this change, we'll get some more votes for #7658 ;-)

[Remy Blank]

Right, I have never really liked automatic camelcase linking anyway. Want me to push #7658 into 0.12-stable as well? Of course, I would also update all pages in the TracGuide to use explicit links.

[Christian Boos]

Replying to rblank:

Right, I have never really liked automatic camelcase linking anyway. Want me to push #7658 into 0.12-stable as well?

Eventually yes, but maybe rather for 0.12.2.

Of course, I would also update all pages in the TracGuide to use explicit links.

… and we should then take the opportunity to use the Help: or tracguide: prefix. For now that could simply be an alias to the wiki, but it would be a step in direction of #3386.

[Remy Blank]

Allow relative and absolute prefix to CamelCase links.

[Remy Blank]

The patch above fixes the issue, but the fix broke a test case for camelcase counter-examples, more specifically /ThisIsNotWikiEither and /ThisIs/NotWikiEither are now considered camelcase links.

Ok to commit?

[Christian Boos]

Yep, I've tested the patch by looking at all my wiki pages and found no issues besides:

• parent links ../<parent> not working, but not related to this patch as [../<parent>] also doesn't work
• CamelCase prefixed by - get recognized, as in CamelCase-OtherCamelCase, which I'm not sure we want, but this is more related to #4542 I fixed yesterday

[Remy Blank]

Applied in [9985].