relative links are not rendered with '?' when the page doesn't exist

[cboos]

Yeah, good point, this should probably be implemented as well, for consistency.

[cboos]

… and this raises the interesting question of the relationship between the WikiContext and the model objects, how to know if such an object exists and how to retrieve it.

[cboos]

I should have another look at that.

Also, there's the related question of how to handle links to pages from within a sub-hierarchy. It would be quite useful to not have to bother where the page is located and have the link point to the closest page in the hierarchy.

e.g. within 0.10/TracGuide, a reference to TracBrowser will preferably point to 0.10/TracBrowser if it exists, then TracBrowser (top-level) if it doesn't.

[rblank]

Replying to cboos:

It would be quite useful to not have to bother where the page is located and have the link point to the closest page in the hierarchy.

e.g. within 0.10/TracGuide, a reference to TracBrowser will preferably point to 0.10/TracBrowser if it exists, then TracBrowser (top-level) if it doesn't.

This is implemented in a patch attached to #4507, waiting for feedback.

[rblank]

I'd like to have a look at this, now that #4507 is fixed, if you don't mind.

[rblank]

Patch against 0.11-stable fixing the rendering of relative links

[rblank]

This turned out to be trickier than I thought, as the relative links are processed generically and not in the wiki module. The patch above fixes the rendering of relative links of the types ./... and ../.... I have not fixed the /... and //... links, as I don't think there's a reasonable way to do that.

All corner cases should be handled correctly (pages with a version number, URL arguments, a [.] link viewed in the page history, and any combinations of the above). But I'd be grateful if I could get some feedback before applying the patch.

[cboos]

The approach looks good, I'll have more time next week to check the patch more thoroughly.

[cboos]

I've looked at the patch a bit more in details, and it's fine by me.

[rblank]

Thanks for the review, patch applied in [7777] (cool number ;-)

[rblank]

Mmmh, merging to trunk is tricky due to interaction with scoped links. I'll keep this ticket open to track the merge.

[rblank]

I have merged [7777] to trunk, but I'm not really happy with the solution to the interaction with scoped links. More precisely, I'm not happy with this​ at all.

The trouble is, the link resolvers have no way of knowing if a target link should be absolute or relative, and the wiki link resolver resolves as scoped unless the target starts with /.

The special case for the wiki realm is ugly, but it works. A cleaner option could be to augment the link resolver interface with an additional argument that specifies if the target should be resolved as absolute. Something like 4416-absolute-link-resolver-r7799.patch​. But this feels like a big change for a small issue.

Opinions?

[rblank]

Fix for wiki realm special case

[cboos]

Give me some more time to think about it.
It's also the opportunity to address links like wiki:../other correctly (#6884).

[cboos]

Just an update to say I didn't yet get around to this one, but it's high prio for me.
I have the feeling that the relative link should be passed as such to the resolvers, and that the wiki resolver in this case can decide to do something about it.

[cboos]

Remy, if you don't have objections, I'd like to move this ticket to 0.11.4:

• 0.11.3 will therefore appear clean - all tickets closed
• I'd like to try a different approach, so I'd like to post-pone closing this ticket

[rblank]

Actually, this ticket *is* fixed in 0.11-stable (comment:9). The open point in comment:11 is the merge to trunk, where it interacts with wiki page scoping (only present on trunk), which I am not satisfied with.

Maybe we should close this ticket and create a new one for trunk?

[cboos]

Replying to rblank:

Maybe we should close this ticket and create a new one for trunk?

Ok, let's close this one and I'll make a note on #6884.