Broken InterWiki Link

[jeff.wise@…]

The following InterWiki link behaves strangely:

Syntax	Behavior
[tps-t6:1234567]	Displays as-is, not hyperlinked.
[tps-t6:1234567 test]	Displays test hyperlinked to a working URL.
tps-t6:1234567	Displays tps-t6:1234567 hyperlinked to a working URL.

If I change the InterWiki link to tps instead of tps-t6, all of the above syntaxes generate a hyperlink to a working URL as expected.

[Christian Boos]

Seems to work here:

----
trac-dev:135
[trac-dev:135]
[trac-dev:135 Workflow: ...]
----

---

​trac-dev:135 ​135 ​Workflow: ...

---

Can you try to upgrade to 0.10.2?

[jeff.wise@…]

Before I take the upgrade route, your links above work for me as well when I cut and paste them into a wiki. I had already tried trac-dev thinking it was a dash issue. I think the problem may lie in the number before the colon. The dash may or may not be a factor.

[Tim Hatch <trac@…>]

I can confirm this is an issue with the latest trunk. It's being caught by the log formatter regexp at source:trunk/trac/versioncontrol/web_ui/log.py@4282#L238​.

[Christian Boos]

Ah, right!

[tps-t6:1234567]
[------:-------]   - revision range
 tps-t             - intertrac prefix
      6 1234567    - the two revisions

requiring a space would break existing stuff like: ​[G100:110]

Well, I'll sleep over it ;)

[Tim Hatch <trac@…>]

Would it be too hackish for the log formatter to be able to pass on it, after finding an invalid intertrac prefix, and construct an interwiki link instead? Are there other places that could have the same problem, or is it just this one?

[Tim Hatch <trac@…>]

Ooh, or better yet, look up valid intertrac/interwiki prefixes and adjust the INTERTRAC_SCHEME regexp to be an alternation of them?

[Tim Hatch <trac@…>]

Just a note, [tps-t6: 1234567] with a space after the colon works for interwiki.

[anonymous]

Replying to Tim Hatch <trac@timhatch.com>:

Just a note, [tps-t6: 1234567] with a space after the colon works for interwiki.

[tps-t6: 1234567] doesn't complete the URL. In this scenario, 1234567 is just a label for the URL tps-t6 points to with an empty argument.

[Christian Boos]

One workaround I can suggest for now is to make use of the multiple arguments facility:

tps-ts6 http://tps-system6/object-id/$1$2  # Link to $1$2 in tps6

Then, tps-ts6:123456 as well as [tps-ts6::123456] should work… (not tested though)

[jeff.wise@…]

Replying to cboos:

One workaround I can suggest for now is to make use of the multiple arguments facility:

tps-ts6 http://tps-system6/object-id/$1$2 # Link to $1$2 in tps6

Then, tps-ts6:123456 as well as [tps-ts6::123456] should work… (not tested though)

I tested it against 0.10.

Syntax	Display	URL
[tps-t6::1234567]	:1234567	Y
[tps-t6:1234567]	[tps-t6:1234567]	N
[tps-t6:1234567:]	1234567:	Y
[tps-t6:1234:567]	1234:567	Y

[Christian Boos]

Well, so that works except for the extraneous ":" displayed, which is of course a bit annoying.

The suggestion of Tim would work (alter INTERTRAC_SCHEME) and is probably the best thing to do, but it looks a bit complex to implement, like the need rebuild the wiki rules when the config changes. It's probably what I'll end up doing if I get no better idea in between ;)

[Christian Boos]

#5324 was closed as duplicate (it was talking about intertrac links, but it's the same issue).

There, the suggestion was made to use ":" as a separator for the shorthand links as well. That would work well for tickets and reports, but not for changesets for the reasons explained in comment:4.

We can probably make a special case there: in [ET64:100] either consider it's r100 in project ET64 if that intertrac/interwiki link exists, otherwise revert to the usual interpretation as [64:100] in project ET.

[xurizaemon]

We're seeing similar issues, where a prefix (gwiki:) works sometimes and doesn't get linked other times. We're on Trac 10.4 (ubuntu Feisty packages). Is there a way of defining the order in which each Wiki parser gets run on the content? Am I barking up the wrong tree?

[Christian Boos]

Replying to xurizaemon:

We're seeing similar issues, where a prefix (gwiki:) works sometimes and doesn't get linked other times. … Am I barking up the wrong tree?

As gwiki: is not a problematic prefix as discussed here, I believe your problem is rather due to the change notification issue, see TracDev/Proposals/Journaling#ReactingonWikicontentchange

After a while, all the server processes are aware of the new content of InterMapTxt. This is a separate issue which is going to be addressed in milestone:0.12.

[anonymous]

Replying to cboos:

As gwiki: is not a problematic prefix as discussed here, I believe your problem is rather due to the change notification issue, see TracDev/Proposals/Journaling#ReactingonWikicontentchange

I'll try an apache2ctl restart and see if that makes it behave. Thanks for the info.

Do "problematic prefixes" refer only to /[a-z-]+[0-9]+:/ as above? I did wonder at first if using a legitimate WikiWord as a prefix was causing the Wiki entry to hijack the InterTrac reference, because I'd used GreenWiki before gwiki, and it sometimes linked instead to that Wiki page (which I'd created AFTER updating InterMapTxt).

[Christian Boos]

Replying to anonymous:

Do "problematic prefixes" refer only to /[a-z-]+[0-9]+:/ as above?

Yes

I did wonder at first if using a legitimate WikiWord as a prefix was causing the Wiki entry to hijack the InterTrac reference, because I'd used GreenWiki before gwiki, and it sometimes linked instead to that Wiki page (which I'd created AFTER updating InterMapTxt).

Same explanation for the "sometimes" than for the "gwiki:" case.

[Christian Boos]

The LogModule should simply try to be a bit more robust here.

[Christian Boos]

Not for 0.12.x.