Wikipage path not intuitive

[funsheep@…]

I'm using trac since version 0.11.5 and got complaints and an unsorted website-hierarchy, because it was not intuitive where the current page is located in the hierachy. Therefore i changed the wiki_view.html template as follows:

22,24c22
<       <p class="path noprint" py:if="not 'WikiStart' in page.name">
<         <a class="pathentry" title="View WikiStart" href="${href.wiki('/')}">/</a>
<         <span py:with="parts=page.name.split('/')">
---
>       <p class="path noprint" py:if="'/' in page.name" py:with="parts = page.name.split('/')">
27,29c25,26
<           class="pathentry sep" py:if="idx != len(parts) - 1">/</span></py:for>
< 	</span>
<         <br style="clear: both" />
---
>           class="pathentry sep" py:if="idx != len(parts) - 1">/</span></py:for>
>         <br style="clear: both" />

After several weeks (8 or so) using this patch i no longer get complains about lost users and the hierachy of the webpages is far more consistent (i do not have to move pages around anymore).

If the wikipage is not WikiStart a / is shown to get back to WikiStart and even, if the page is not located in a hierachy (e.g. /foo) / foo are shown as links (as would it would be, if the page were located in / xyz / foo).

[Remy Blank]

A single / as a link is probably difficult to click on. We could use the same approach as in the source browser:

root / foo / bar

where root is displayed in grey and links to the wiki root, and foo and bar are displayed in red.

What do others think?

[Christian Boos]

Yes, but using wiki: instead of root, then we even give a hint about the TracLinks syntax to use for that page.

Ideally, one should then be able to copy/paste that path and get the correct link, without intermediate spaces, like we can do in the source browser.

[Christian Boos]

Show wiki: <page> [ / <subpage> …]

[Christian Boos]

I think we should even do something similar with the source browser and show source: instead of root.

[Remy Blank]

Mmh, my RSS reader seems to have missed comment:2 and comment:3…

I haven't tested the patch, but I like the idea. +1 for the source browser as well.

[funsheep@…]

I tried the patch in my installation: The following changes have to be made to the patch:

- <a class="pathentry first" title="View WikiStart" href="href.wiki()">wiki:</a> 
+ <a class="pathentry first" title="View WikiStart" href="${href.wiki()}">wiki:</a> 

I like the way it works. Thanks!

[Christian Boos]

Replying to funsheep@…:

I tried the patch in my installation: The following changes have to be made to the patch:

ack. Thanks for testing!

[Christian Boos]

Fixed patch applied in r8867.

[Christian Boos]

Changed root to source: in r8869 (in MultiRepos though, as there we already have the separate path_links.html template file for the path index).

[Remy Blank]

In [8869], the following probably doesn't do what you want:

title="${(_('Go to repository root'), _('Go to repository index'))[reponame]}"

You should probably wrap the reponame in a bool():

title="${(_('Go to repository root'), _('Go to repository index'))[bool(reponame)]}"

[Christian Boos]

Thanks! Fixed in r8870.

[mrelbe <mikael@…>]

Hmm, I was hoping the wiki path would be presented just beneath the navigation bar, as the context menu is… I tried to apply some custom styling as

p.path { margin-top: -13px }

which makes the path vertically aligned with the context menu. But the context menu links becomes un-clickable since the p.path covers it…

I really think they should be vertically aligned.

[mrelbe <mikael@…>]

I actually found a way to apply custom formatting that aligns the wiki path and context menu vertically without disabling the context menu links:

Apply the following custom styling:

h1, h2, h3, h4, h5 { clear: left }
p.path { float: left; margin-top: -13px }

The top-margin depends of course on the font used for wiki path and context menu (this number comes from using Verdana at default size).

The first headline of the wiki page then comes rather close to the wiki path, which can be fixed by adding something like:

p.path { padding-bottom: 20px }

I guess it would be better to change the templates instead…

[mrelbe <mikael@…>]

The proposal above is not optimal (it breaks other pages than wiki pages). This works and looks good I think:

.wikipage h1, .wikipage h2, .wikipage h3, .wikipage h4, .wikipage h5 { clear: left }
p.path { float: left; margin-top: -13px; padding-bottom: 13px }

[Christian Boos]

A page doesn't necessarily start with a section heading…

I'm looking into moving the p.path above in the page structure.

[anonymous]

Would be nice, if the attachments sites also mach this style. Currently there is one link which misses the wiki: and is bold and black

[Christian Boos]

Reopening for addressing comment:14 (Eli also mentioned that on #irc).

[Christian Boos]

Replying to cboos:

Reopening for addressing comment:14

Should be fixed in r9095. This still uses a negative margin, so it's far from optimal, but it should do the job for now. Better fix welcomed ;-)

[Christian Boos]

Each time I do a wiki page save and see the notification above the wiki path, this annoys me…

[Christian Boos]

Better placement of the wiki path. Patch applies on r9373,

[Christian Boos]

Please review attachment:wiki-path-above-notice.patch​.

[Remy Blank]

Works and looks great! Maybe use py:if="value_of(resourcepath_template)" in the <xi:include> in the spirit of being close to strict-compliant?

[Christian Boos]

Thanks for the review! Patch committed in [9386], with the requested change.

[Remy Blank]

Oops, sorry, bad advice. This should have been value_of('resourcepath_template') (with quotes). Fixed in [9394].

[Christian Boos]

After the upgrade, when looking at wiki pages, I thought something was missing, but couldn't tell what ;-)