Improve behavior of hierarchical page names

[christian@…]

I was looking for release notes for trac 0.10.3, when I opened the URL ​http://trac.edgewall.org/wiki/TracDev/ReleaseNotes/0.10 and figured that there might be another page for it. So I removed th "0.10" from the URL's end - and got the standard "describe this page" dialog.

I could certainly search for that page, but that's not what I expected, although I'm a somewhat experienced trac user. I'd assume that trac handled this more elegantly, i.e.:

• notice that the requested page doesn't exist
• query for page names matching the requested pattern
• link to those pages from the "create new page" dialog
  • "However, there are pages with a name similar to the one you've been looking for: … print linked list of page names"

It could be standard functionality to put a list of matching page names in HDF so the current page could easily display a list of sub-pages. This also references #2149, #2150.

[Christian Boos]

Interesting idea. I'll look into it for 0.11, as we want to improve support for Wiki page name hierarchies there (see also #4412).

[Christian Boos]

See also ​googlegroups:trac-dev:3f9bbc0bcb3158e2.

[Christian Boos]

#3021 was also requesting better support for "namespaces" in the TracWiki, and was closed as duplicate.

[Christian Boos]

In order to better support "namespaces" (as in #3021 and #4412), I think it would be good that when resolving a Wiki page link, we first look in the local scope.

Example:

• TracInstall referenced from within a page starting with the '0.11/' prefix should link to 0.11/TracInstall as that page exists
• TracInstall reference from within a page starting with the 'TracDev/' prefix will link to the toplevel TracInstall, as TracDev/TracInstall doesn't exist
• for disambiguation needs, it's possible to refer to the toplevel page using the ["/TracInstall"] or [wiki:/TracInstall] syntax

[Remy Blank <remy.blank@…>]

Patch against 0.11-stable making wiki TracLinks in wiki pages scoped

[Remy Blank <remy.blank@…>]

The patch above makes wiki TracLinks in wiki pages scoped. Given the following pages:

• FirstLevel
• FirstLevel/SecondLevel
• FirstLevel/SecondLevel/ThirdLevel
• FirstLevel/SecondLevel/OtherThirdLevel

Then the links below, placed on FirstLevel/SecondLevel/ThirdLevel, resolve as follows:

• FirstLevel → FirstLevel
• SecondLevel → FirstLevel/SecondLevel
• ThirdLevel → FirstLevel/SecondLevel/ThirdLevel
• OtherThirdLevel → FirstLevel/SecondLevel/OtherThirdLevel
• [wiki:/OtherThirdLevel] → OtherThirdLevel
• MissingPage → MissingPage

The patch also adds a test case for the typical scenarios.

[Remy Blank]

Updated patch for current trunk

[Remy Blank]

Oops, I didn't notice the milestone for this ticket. The patch above is the same but for the current trunk. Feedback appreciated.

[Christian Boos]

Patch looks great.

[Remy Blank]

Thanks for the review. I'll apply it later this week, and also update the documentation.

[Remy Blank]

Improved usability for creating hierarchical pages

[Remy Blank]

I wasn't too happy with the usability of the previous patch. This patch adds two improvements:

• Non-existing pages link to a sibling page of the container page, instead of a top-level page. This means that, in the same situation as comment:5 (i.e. when a link is placed on FirstLevel/SecondLevel/ThirdLevel), the following mapping is done:
  • MissingPage -> FirstLevel/SecondLevel/MissingPage

• When accessing a non-existing hierarchical page, in addition to to the "Describe … here." message, a list of links to the same page, but higher up in the hierarchy, is presented. For example, when viewing FirstLevel/SecondLevel/MissingPage, the following links are displayed:
  • FirstLevel/MissingPage
  • MissingPage

These improvement should make it easier to create the desired page.

I am not sure about one thing, though. Currently, the links on non-existing hierarchical pages point to the page viewer. Should they point to the editor instead (i.e. with action=edit)?

Comments welcome.

[Remy Blank]

Patch applied in [7685].

[Christian Boos]

Replying to rblank:

• Non-existing pages link to a sibling page of the container page, instead of a top-level page. This means that, in the same situation as comment:5 (i.e. when a link is placed on FirstLevel/SecondLevel/ThirdLevel), the following mapping is done:
  • MissingPage -> FirstLevel/SecondLevel/MissingPage

eblot recently reported to me a non-intuitive behavior, due to the above feature. Inside a page called "HwDocs/HwBoards", he was using the following links:

=== [wiki:HwDocs/HwBoards/B1 Board1] ===

=== [wiki:HwDocs/HwBoards/B2 Board2] ===

=== [wiki:HwDocs/HwBoards/B3 Board3] ===

The following HTML was generated:

<h3 id="Board1"><a class="wiki"
href="/trac/sdk/wiki/HwDocs/HwBoards/B1">Board1</a></h3>
<h3 id="Board2"><a class="wiki"
href="/trac/sdk/wiki/HwDocs/HwDocs/HwBoards/B2">Board2</a></h3>
<h3 id="Board3"><a class="missing wiki"
href="/trac/sdk/wiki/HwDocs/HwDocs/HwBoards/B3"
rel="nofollow">Board3</a></h3>

HwDocs/HwBoards/B1 exists and is correct, HwDocs/HwDocs/HwBoards/B2 also exists, but was wrongly created at that location when the link looked like the one for Board3.

What about having HwDocs/HwBoards/xyz behave like ./xyz here, as we're on the ! HwDocs/HwBoards page? Perhaps more generally, when a sub-path correspond to some existing page higher in the hierarchy of the current page, chances are that one wants to target a page starting from there. E.g. in the same HwDocs/HwBoards page, HwDocs/Overview would point to /HwDocs/Overview.

[Remy Blank]

Replying to cboos:

What about having HwDocs/HwBoards/xyz behave like ./xyz here, as we're on the HwDocs/HwBoards page? Perhaps more generally, when a sub-path correspond to some existing page higher in the hierarchy of the current page, chances are that one wants to target a page starting from there. E.g. in the same HwDocs/HwBoards page, HwDocs/Overview would point to /HwDocs/Overview.

Heh, not sure I follow you there ;-)

Let me try to reformulate: if the current page and the destination path have a non-empty common base pointing to an existing page, the destination should be rooted there. Is that what you mean?

My initial reaction is -0, for the following reasons:

• The path resolution rules become quite complicated to explain. Scoped pages are already not that easy to grasp. but this is becoming really difficult.

• The situation Manu describes is only non-intuitive because of an initial page creation error. The fix is quite simple, delete the bad page.

• However, it seems that it's not easy to pick the right page name when creating a scoped page. Currently, all possible variants are proposed for a non-existing page, starting with the one that is rooted deepest in the hierarchy. This is clearly not ideal.

So I'd rather introduce a fix to avoid creating the wrong page in the first place, rather than introduce more complex scoping rules. How about applying the algorithm you propose to select the first page to use when navigating to a non-existing page? For the case you describe, when clicking on "HwDocs/HwBoardds/B2", that would be:

• This page doesn't exist. It looks like you are trying to create "HwDocs/HwBoards/B2". You can do so here.

• Alternatively, you can also create the page at other locations in the page hierarchy:
  • HwDocs/HwDocs/HwBoards/B2

So this would not change the path resolution algorithm, only the suggestion for creating a new page.

[Christian Boos]

Replying to rblank:

Let me try to reformulate: if the current page and the destination path have a non-empty common base pointing to an existing page, the destination should be rooted there. Is that what you mean?

Yes.

My initial reaction is -0, for the following reasons:

• The path resolution rules become quite complicated to explain. Scoped pages are already not that easy to grasp. but this is becoming really difficult.

Agreed, I'm all for finding a simpler solution.

• The situation Manu describes is only non-intuitive because of an initial page creation error. The fix is quite simple, delete the bad page.

No, see "Board3". The problem comes from the repetition "HwDocs/HwDocs/…" in the missing link. Manu interpreted that as a bug, and so did I until I read again the explanation in comment:10.

• However, it seems that it's not easy to pick the right page name when creating a scoped page. Currently, all possible variants are proposed for a non-existing page, starting with the one that is rooted deepest in the hierarchy. This is clearly not ideal.

So I'd rather introduce a fix to avoid creating the wrong page in the first place, rather than introduce more complex scoping rules. How about applying the algorithm you propose to select the first page to use when navigating to a non-existing page? For the case you describe, when clicking on "HwDocs/HwBoardds/B2", that would be:

• This page doesn't exist. It looks like you are trying to create "HwDocs/HwBoards/B2". You can do so here.

• Alternatively, you can also create the page at other locations in the page hierarchy:
  • HwDocs/HwDocs/HwBoards/B2

So this would not change the path resolution algorithm, only the suggestion for creating a new page.

Yes, that's a good solution.

[Remy Blank]

Fixed the relative page resolution for non-existing pages according to comment:12 in [8449].

I'm not happy about the list of page suggestions, though. Currently, it will display existing pages as if they didn't exist. I'd like to improve it at least so that it doesn't display existing pages, and maybe even make it a "Related pages" list showing both page name suggestions and existing pages with the same name.

[Remy Blank]

An even better algorithm was committed in [8450].

[Christian Boos]

Thanks for looking back at this one, one nasty problem less to worry about ;-)

Especially the unit test in r8450 is nice as it shows the problem reported by Manu is fixed. Anything else that prevents the ticket from being closed?

[Remy Blank]

Replying to cboos:

Anything else that prevents the ticket from being closed?

Yes, I am working on improving the display of the page name suggestions for non-existing pages. There are two issues:

• Currently, all suggestions are displayed as non-existing pages, even if they do exist.

• I'd like to add another section below the suggestions, something like "Possibly related pages" that lists pages with similar names. Not sure yet how to generate it.

I'd like to fix at least the first issue, and see if I can come up with something sensible for the second.

[Christian Boos]

Ah, good! Also, remember the discussion about improving the readability of the relative links? We could strip off the "./", "../" and "/" prefixes, that are kind of "implementation details" and getting in the way when reading the rendered wiki text.

[Remy Blank]

#8558 was closed as a duplicate, and suggests making it clearer that the page doesn't exist and what the options are for the user.

[Remy Blank]

Fixed the formatting for page suggestions higher in the hierarchy, and added a list of pages with similar names in [8461].

[Remy Blank]

Replying to cboos:

Also, remember the discussion about improving the readability of the relative links? We could strip off the "./", "../" and "/" prefixes, that are kind of "implementation details" and getting in the way when reading the rendered wiki text.

Is this what you had in mind?

trac/wiki/api.py

@@ -267 +267 @@
 
     def _format_link(self, formatter, ns, pagename, label, ignore_missing,
                      original_label=None):
+        if pagename == label:
+            label = label.lstrip('/')
+        elif label.startswith('./') and pagename.endswith(label[2:]):
+            label = label[2:]
+        elif label.startswith('../') and pagename.endswith(label[3:]):
+            label = label[3:]
         pagename, query, fragment = formatter.split_link(pagename)
         version = None
         if '@' in pagename:

[Christian Boos]

I think we shouldn't modify a label specified explicitly.

So currently we have:

 - [./SubPage] => ./SubPage
 - [./SubPage ./SubPage] => ./SubPage

What I meant was:

 - [./SubPage] => SubPage
 - [./SubPage ./SubPage] => ./SubPage

So I think the replacement should happen earlier.

[Christian Boos]

Ah, forgot to say: I tested the rest of the new enhancements, and that looks really good now!

[Remy Blank]

Replying to cboos:

I think we shouldn't modify a label specified explicitly.

Yes, that's what I thought, too, but the information that no label was specified is lost quite early during parsing, and so far I haven't found a good place to insert that modification. OTOH, it was late last night, so I'll give it another go :-)

[Remy Blank]

Ok, I think [8464] solves this adequately. A few additional test cases show how the prefixes are stripped.

Now can we close this or what? ;-)

[Christian Boos]

Yes, we can close it, the patch looks good ;-)

[rgasler@…]

Replying to cboos:

Replying to rblank:

Let me try to reformulate: if the current page and the destination path have a non-empty common base pointing to an existing page, the destination should be rooted there. Is that what you mean?

Yes.

My initial reaction is -0, for the following reasons:

• The path resolution rules become quite complicated to explain. Scoped pages are already not that easy to grasp. but this is becoming really difficult.

Agreed, I'm all for finding a simpler solution.

• The situation Manu describes is only non-intuitive because of an initial page creation error. The fix is quite simple, delete the bad page.

No, see "Board3". The problem comes from the repetition "HwDocs/HwDocs/…" in the missing link. Manu interpreted that as a bug, and so did I until I read again the explanation in comment:10.

• However, it seems that it's not easy to pick the right page name when creating a scoped page. Currently, all possible variants are proposed for a non-existing page, starting with the one that is rooted deepest in the hierarchy. This is clearly not ideal.

So I'd rather introduce a fix to avoid creating the wrong page in the first place, rather than introduce more complex scoping rules. How about applying the algorithm you propose to select the first page to use when navigating to a non-existing page? For the case you describe, when clicking on "HwDocs/HwBoardds/B2", that would be:

• This page doesn't exist. It looks like you are trying to create "HwDocs/HwBoards/B2". You can do so here.

• Alternatively, you can also create the page at other locations in the page hierarchy:
  • HwDocs/HwDocs/HwBoards/B2

So this would not change the path resolution algorithm, only the suggestion for creating a new page.

Yes, that's a good solution.

Hi,

I would like add a small late comment to this thread:

In case 'HwDocs' and 'HwDocs/HwBoards' don't exist all the links will resolve to 'HwDocs/HwDocs/HwBoards' instead… I find this behavior not being very intuitive or consistent.

Adding the following test to the wiki page HwDocs/HwBoards:

[wiki:HwDocs/HwBoards/B1]

will produce

<a class="wiki"
href="/trac/sdk/wiki/HwDocs/HwDocs/HwBoards/B1">Board1</a>

[Christian Boos]

Ok, we have already discussed this glitch before, the real problem IMO is that this link will lead to a page showing the following:

 The page HwDocs/HwDocs/HwBoards/B1 does not exist. You can create it here.

 You could also create the same page higher in the hierarchy:

 HwDocs/HwDocs/B1?
 HwDocs/B1?
 B1?

i.e. among the proposed targets, the HwDocs/HwBoards part is gone. The (only) proposition should have been HwDocs/HwBoards/B1 as that was specified in the link itself. If we can agree on that (or a better solution), let's create a follow-up ticket.