InterTrac links with blank target don't work even though TracLinks of the same form do

[ben@…]

Inside a wiki page [wiki: blah] works to link to the top level of the wiki; however, [trac:wiki: blah] doesn't work (I get a '"wiki:" is not a TracLinks' error).

If I turn intertrac compat mode, then the link works (because the originating Trac instance formats the link).

[cboos]

Suggesting:

• trac:wiki or [trac:wiki] for linking to the Wiki module
• [trac:] for linking to the toplevel (#4314)

Which can be implemented by removing a few checks in the intertrac module:

trac/wiki/intertrac.py

@@ -41 +41 @@
 
     def process_request(self, req):
         link = req.args.get('link', '')
-        if not link:
-            raise TracError('No TracLinks given')
         link_elt = extract_link(Context(self.env, req), link)
         if isinstance(link_elt, Element):
             href = link_elt.attrib.get('href')
-            if href:
-                req.redirect(href)
-        raise TracError('"%s" is not a TracLinks' % link)
+        else:
+            href = req.href(link)
+        req.redirect(href)
 
-
     # IWikiMacroProvider methods
 
     def get_macros(self):

Invalid InterTrac links will instead trigger a "No handler matched request to <link>" error.

[cboos]

Same change than the inlined diff, plus some tests and a cosmetic change for the link title when there's no target.

[cboos]

Patch applied in [6137].

[Kevin Gabbert]

I'm having this same exact problem in .11rc1 (windows). The most recent download at this time

was there a regression?

the exact error I get is:

Internal Error

"wiki:" is not a TracLinks

[cboos]

What is currently implemented is the suggestion presented in comment:1, i.e. [<intertrac-prefix>:wiki].

However, I agree that [<intertrac-prefix>:wiki:] could be normalized to the same target.

I use this opportunity to add a reminder about another problem with InterTrac links:

[trac:SpamFilter SpamFilter],
[trac:SpamFilter the SpamFilter]

renders as:

SpamFilter, the SpamFilter

(while the second works as expected, the first also shows the trac: prefix when it shouldn't)

[osimons]

Replying to cboos:

(while the second works as expected, the first also shows the trac: prefix when it shouldn't)

That would be me in [6417], and it only occurs when the target and label are identical. Problem is that the _make_link() code does not know the differenence as the _lhref_formatter() sets label to target if no label is set before passing on to rendering.

The reason for wanting the prefix was to treat intertrac/wiki links like any other external link like http:// and similar. The default behaviour without label should include the external target.

I haven't looked into what that match argument passed in to _make_link() actually contains, but if that allows me to identify 'no label' it would just be a matter of changing if label == target: to something looking into the match object instead (formatter.py).

[osimons]

Replying to osimons:

Replying to cboos:

(while the second works as expected, the first also shows the trac: prefix when it shouldn't)

That would be me in [6417], and it only occurs when the target and label are identical. Problem is that the _make_link() code does not know the differenence as the _lhref_formatter() sets label to target if no label is set before passing on to rendering.

Seems match contains the full wiki link text. Using some string trickery, it should then be possible to detect if there is no actual label set when the strings are identical. This works when testing your examples:

trac/wiki/formatter.py

@@ -390 +390 @@
             else:
                 return olabel or otarget
         else:
-            if label == target:
+            if label == target \
+                    and match[match.find(label):].rstrip(']') == label:
                 # add ns for Inter* links when nothing is set
                 label = ns+':'+label
             return self._make_intertrac_link(ns, target, label) or \

[cboos]

What about passing the fullmatch object to _make_link and look for the 'label'group? If present, then always use it, otherwise use ns:label because it will be either a shref or a lhref with no label set. That would be cleaner I think.

[osimons]

Replying to cboos:

What about passing the fullmatch object to _make_link...

Yup. Makes more sense than trying to reparse it again. Committed in [7238:7239] for 0.11 and trunk.

That concludes the detour from the main ticket topic, I guess.

[cboos]

Last fix done in [7312].