Modify

Opened 4 years ago

#8189 new defect

RelativeWikiFormatter: Erroneous link-rendering of page words iff a wiki page with that name exists

Reported by: jholg Owned by: coderanger
Priority: normal Component: HierWikiPlugin
Severity: normal Keywords:
Cc: Trac Release: 0.11

Description

The HierWikiPlugin uses an internal "pagebase" in its formatter module that is basically supposed to hold the "subpages-prefix" of a wiki page. However, for trivial, non-hierarchical wiki page names the current implementation resolves to an empty pagebase, in effect selecting all wiki page names for its page selector pattern:

>>> PAGES = ['Foo', 'Bar', 'Moo', 'Moo/Boo']>>> pagename = 'Foo'
>>> pagebase = '/'.join(pagename.split('/')[:-1])
>>> if pagebase != '':
...     pagebase += '/'
...
>>> print pagebase

>>> pages = set([p[len(pagebase):] for p in PAGES if p.startswith(pagebase)])
>>> pattern = r'\b(?P<relwiki>' + '|'.join(pages) + r')\b'
>>> print pattern
\b(?P<relwiki>Moo|Foo|Bar|Moo/Boo)\b
>>>

Which leads to

  • a normal word (e.g. Bar) on a wiki page being rendered as a link, although it is not in WikiPage syntax and there is no link syntax ([... ]) involved
  • if there is an existing wiki page of this same name ('Bar')
  • but unfortunately the link target is 'wikiBar' rather than 'wiki/Bar' due to this Href class behaviour:
>>> href = Href('www.example.org')
>>> href('', 'name')
'www.example.org//name'
>>>

So if you click on this link you'll end up creating a wiki page '/Bar'.

Note that this behaviour manifests itself only after a recreation of the RelativeWikiFormatter instance, i.e. after you restart tracd/apache/... or disable and re-enable the plugin component (reason: see below). Attached patch fixes this, by using a pages_re that only matches for actual 'page/subpage/...' of page: Fixed RelativeWikiFormatter pages_re creation to only match for rendering relative subpages (page/subpage/...) of the currently to-be-rendered page. This also corrects the erroneous rendering of non-CamelCase-named regular wiki pages as links, with an offending leading slash in the link target href.

In effect, on a page "Team" with subpage "Team/Lead" and the page source text

TitleIndex

WikiStart

Lead

Team/Lead

this is the rendering behaviour:

TitleIndex --> rendered as link, links to (existing) wiki page TitleIndex

WikiStart --> rendered as link, links to (existing) wiki page WikiStart

Lead --> rendered as link, links to sub-page Team/Lead

Team/Lead --> rendered as link, links to (existing) wiki page Team/Lead 

While this fixes the (imho) erroneous linking of arbitrary page names without WikiPageName syntax, it generally only renders subpages after RelativeWikiFormatter has been reloaded/recreated.

This is due to this source code line which does not do what it's intended to do, in my understanding:

WikiSystem(self.env)._compiled_rules = None

As the WikiSystem instance does not have any _compiled_rules attribute this line is without any effect (maybe this worked in older Trac releases, I don't know).

The _compiled_rules attribute belongs to the Formatter instance, and so far I haven't found a way to force the syntax providers to be reloaded. My Trac knowledge is somewhat limited...

Patch: attachment:subpage_link_rendering.diff

Holger

Attachments (1)

subpage_link_rendering.diff (4.7 KB) - added by jholg 4 years ago.
only provide link-rendering syntax for actual page subpages

Download all attachments as: .zip

Change History (1)

Changed 4 years ago by jholg

only provide link-rendering syntax for actual page subpages

Add Comment

Modify Ticket

Action
as new The owner will remain coderanger.
Author


E-mail address and user name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.