Modify

Opened 14 years ago

Closed 9 years ago

#8189 closed defect (wontfix)

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

Reported by: jholg Owned by:
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 14 years ago.
only provide link-rendering syntax for actual page subpages

Download all attachments as: .zip

Change History (3)

Changed 14 years ago by jholg

Attachment: subpage_link_rendering.diff added

only provide link-rendering syntax for actual page subpages

comment:1 Changed 10 years ago by Ryan J Ollos

Owner: Noah Kantrowitz deleted

comment:2 Changed 9 years ago by Ryan J Ollos

Resolution: wontfix
Status: newclosed

The plugin is deprecated since Trac has equivalent functionality as of trac:milestone:1.1.2. If you find any missing function please open a ticket for Trac.

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.

Add Comment


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

 
Note: See TracTickets for help on using tickets.