Edgewall Software
Modify

Opened 14 years ago

Closed 12 years ago

#6884 closed defect (fixed)

./TracLinks does not work

Reported by: conny@… Owned by: Remy Blank
Priority: normal Milestone: 0.12.1
Component: wiki system Version: 0.11b1
Severity: normal Keywords:
Cc: Branch:
Release Notes:
API Changes:
Internal Changes:

Description

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

Attachments (4)

relative_wiki_links.diff (475 bytes ) - added by shookie@… 13 years ago.
simple workaround fix
post_match_check.diff (575 bytes ) - added by shookie@… 13 years ago.
small patch that re-checks the link target
new_group_nsrel.diff (2.7 KB ) - added by shookie@… 13 years ago.
big patch that alters the central rules regex
6884-relative-camelcase-r9984.patch (3.0 KB ) - added by Remy Blank 12 years ago.
Allow relative and absolute prefix to CamelCase links.

Download all attachments as: .zip

Change History (25)

comment:1 by Christian Boos, 14 years ago

Milestone: 0.11

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])

in reply to:  1 comment:2 by osimons, 14 years ago

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.

comment:3 by Christian Boos, 14 years ago

Milestone: 0.110.11.1
Priority: normalhigh

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.

comment:4 by anonymous, 14 years ago

OK thats goog

comment:5 by osimons, 14 years ago

#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.

comment:6 by Christian Boos, 13 years ago

Milestone: 0.11-retriage0.12

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

comment:7 by Christian Boos, 13 years ago

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.

by shookie@…, 13 years ago

Attachment: relative_wiki_links.diff added

simple workaround fix

comment:8 by shookie@…, 13 years ago

Priority: highnormal

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

comment:9 by shookie@…, 13 years ago

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.

by shookie@…, 13 years ago

Attachment: post_match_check.diff added

small patch that re-checks the link target

by shookie@…, 13 years ago

Attachment: new_group_nsrel.diff added

big patch that alters the central rules regex

comment:10 by Remy Blank, 13 years ago

Owner: changed from Christian Boos to Remy Blank

I'll look into that.

comment:11 by Remy Blank, 13 years ago

Resolution: fixed
Status: newclosed

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.

comment:12 by anonymous, 12 years ago

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.

comment:13 by Remy Blank, 12 years ago

Milestone: 0.120.12.1
Resolution: fixed
Status: closedreopened

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).

comment:14 by Christian Boos, 12 years ago

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").

in reply to:  14 comment:15 by Remy Blank, 12 years ago

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).

comment:16 by Christian Boos, 12 years ago

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

comment:17 by Remy Blank, 12 years ago

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.

in reply to:  17 comment:18 by Christian Boos, 12 years ago

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.

by Remy Blank, 12 years ago

Allow relative and absolute prefix to CamelCase links.

comment:19 by Remy Blank, 12 years ago

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?

comment:20 by Christian Boos, 12 years ago

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

comment:21 by Remy Blank, 12 years ago

Resolution: fixed
Status: reopenedclosed

Applied in [9985].

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Remy Blank.
The resolution will be deleted. Next status will be 'reopened'.
to The owner will be changed from Remy Blank to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.