The href of customized navigation items doesn't work as documented

[Ryan J Ollos]

TracNavigation#Notes suggests that the following mappings should occur:

• /projects/project1/wiki/WikiStart → /projects/projects1/wiki/WikiStart
• wiki/WikiStart → /projects/project1/wiki/WikiStart (when in the project1 environment).

This is not the case however. An href beginning with / is treated as project-relative. There does not seem to be a way to create an interproject link in a multiproject/multienvironment setup sharing the same base url link without using the base url in the href or using .. in the href (e.g. ../project2/wiki/WikiStart).

Using an href such as wiki/WikiStart results in repeated clicks on the mainnav button mapping to /projects/project1/wiki/WikiStart → /projects/project1/wiki/WikiStart/wiki/WikiStart → /projects/project1/wiki/WikiStart/wiki/WikiStart/wiki/WikiStart.

Unfortunately I think the proper fix would change the behavior for existing users:

trac/web/chrome.py

@@ -724 +724 @@
                         label = category_section.get(name + '.label')
                         href = category_section.get(name + '.href')
                         if href:
-                            if href.startswith('/'):
+                            if not href.startswith(('http://',
+                                                    'https://', '/')):
                                 href = req.href + href
                             if label:
                                 item = tag.a(label) # create new label

[Olemis Lang <olemis+trac@…>]

Replying to rjollos: […]

This is not the case however. An href beginning with / is treated as project-relative.

yes

There does not seem to be a way to create an interproject link in a multiproject/multienvironment setup sharing the same base url

afaik , no … unless InterTrac or a custom TracLinks expression is installed .

Using an href such as wiki/WikiStart results in repeated clicks on the mainnav button mapping to /projects/project1/wiki/WikiStart → /projects/project1/wiki/WikiStart/wiki/WikiStart → /projects/project1/wiki/WikiStart/wiki/WikiStart/wiki/WikiStart.

wiki/WikiStart is a relative wiki path , varies depending on (wiki) context

Unfortunately I think the proper fix would change the behavior for existing users:

yep, I'm not very sure about it …

[…]

[Ryan J Ollos]

Since either the documentation needs to be changed or the patch needs to be applied, I vote for applying the patch on the trunk since it make the configuration more flexible, and documenting the behavior for Trac < 1.2. That will avoid breaking configurations on 1.0-stable and earlier.

For example, after the patch is applied a user that has an href = /wiki/WikiStart with a base URL for the project http://example.com/proj1 will need to change to href = wiki/WikiStart otherwise the link will direct to http://example.com/wiki/WikiStart. However, after the patch a link can be created to another project using href = /proj2/wiki/WikiStart, which will map to http://example.com/proj2/wiki/WikiStart. See ​th:#11443 for a related issue.

I'll wait for feedback from the other Trac devs before proceeding.

[ethan.jucovy@…]

A backwards-compatible alternative for interproject links might be href = //proj2/wiki/WikiStart. Personally I would find that + the current behavior less surprising than resolving relative links to the project base.

(Though perhaps // should be interpreted as a protocol-relative absolute URL, as it would be if seen directly in a browser. It currently just becomes http://example.com/proj1//proj2/wiki/WikiStart which is almost certainly never useful.)

Granted, relative links don't seem like a very desirable feature for the mainnav. I can imagine (maybe still unlikely) uses for relative links in the metanav though, in plugins that also implement IRequestHandler — e.g. contextual help, or "create a ticket linked to the page I'm on", or "show me API functions available for this resource".

[Ryan J Ollos]

Milestone renamed

[Ryan J Ollos]

Milestone renamed