Edgewall Software
Modify

Opened 10 years ago

Closed 10 years ago

Last modified 5 years ago

#8857 closed enhancement (fixed)

Wikipage path not intuitive

Reported by: funsheep@… Owned by: Christian Boos
Priority: normal Milestone: 0.12
Component: wiki system Version: 0.11.5
Severity: normal Keywords: layout css
Cc: mikael@… Branch:
Release Notes:
API Changes:

Description

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).

Attachments (2)

t8857-wiki-path-r8861.diff (2.0 KB ) - added by Christian Boos 10 years ago.
Show wiki: <page> [ / <subpage> …]
wiki-path-above-notice.patch (4.0 KB ) - added by Christian Boos 10 years ago.
Better placement of the wiki path. Patch applies on r9373,

Download all attachments as: .zip

Change History (27)

comment:1 by Remy Blank, 10 years ago

Version: none0.11.5

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?

comment:2 by Christian Boos, 10 years ago

Milestone: 0.12

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.

comment:3 by Christian Boos, 10 years ago

Owner: set to Christian Boos

by Christian Boos, 10 years ago

Attachment: t8857-wiki-path-r8861.diff added

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

comment:4 by Christian Boos, 10 years ago

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

comment:5 by Remy Blank, 10 years ago

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.

comment:6 by funsheep@…, 10 years ago

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!

in reply to:  6 comment:7 by Christian Boos, 10 years ago

Replying to funsheep@…:

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

ack. Thanks for testing!

comment:8 by Christian Boos, 10 years ago

Resolution: fixed
Status: newclosed

Fixed patch applied in r8867.

comment:9 by Christian Boos, 10 years ago

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).

comment:10 by Remy Blank, 10 years ago

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)]}"

comment:11 by Christian Boos, 10 years ago

Thanks! Fixed in r8870.

comment:12 by mrelbe <mikael@…>, 10 years ago

Cc: mikael@… added

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.

comment:13 by mrelbe <mikael@…>, 10 years ago

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…

comment:14 by mrelbe <mikael@…>, 10 years ago

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 }

comment:15 by Christian Boos, 10 years ago

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

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

comment:16 by anonymous, 10 years ago

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

comment:17 by Christian Boos, 10 years ago

Keywords: layout css added

comment:18 by Christian Boos, 10 years ago

Resolution: fixed
Status: closedreopened

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

in reply to:  18 comment:19 by Christian Boos, 10 years ago

Resolution: fixed
Status: reopenedclosed

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 ;-)

comment:20 by Christian Boos, 10 years ago

Resolution: fixed
Status: closedreopened

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

by Christian Boos, 10 years ago

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

comment:22 by Remy Blank, 10 years ago

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?

comment:23 by Christian Boos, 10 years ago

Resolution: fixed
Status: reopenedclosed

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

comment:24 by Remy Blank, 10 years ago

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

comment:25 by Christian Boos, 10 years ago

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

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain Christian Boos.
The resolution will be deleted. Next status will be 'reopened'.
to as closed The owner will be changed from Christian Boos to the specified user.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.