Modify

Opened 3 years ago

Closed 15 months ago

#9718 closed defect (fixed)

Resolve relative wiki paths in pattern for wiki pages too

Reported by: hasienda Owned by: hasienda
Priority: normal Component: WikiCalendarMacro
Severity: normal Keywords: wiki page
Cc: rjollos Trac Release: 0.11

Description (last modified by hasienda)

As ilewismsl reported in a comment to #9703, both calendar macros don't treat patterns for wiki path generation no longer relative to the current page.

Links are always resolved as absolute paths and have always been before. Nevertheless it would be nice to have configured wiki page paths resolved as relative links.

Attachments (0)

Change History (16)

comment:1 Changed 3 years ago by hasienda

  • Status changed from new to assigned

I can reproduce this behavior here. Breaking of existing applications is foreseeable, if the macro is expanded from a subpage. So this has to be fixed before the next release.

Thank you for taking the time to report this issue. You made a difference, enabling me to fix it.

comment:2 Changed 3 years ago by hasienda

  • Description modified (diff)
  • Severity changed from major to normal
  • Type changed from defect to enhancement

It has been a mistake of mine to believe, that this ever worked before. In fact I found no evidence for this functionality in the code history of both macros.

comment:3 Changed 3 years ago by hasienda

  • Summary changed from Regression: wiki path generation from pattern is not relative to current page. to Wiki path generation from pattern is not relative to current page.

comment:4 Changed 3 years ago by hasienda

  • Summary changed from Wiki path generation from pattern is not relative to current page. to Resolve relative wiki paths in pattern for wiki pages too

comment:5 follow-up: Changed 3 years ago by hasienda

(In [11174]) WikiCalendarMacro: Enable parsing of relative wiki path patterns, refs #9718.

Thanks to Ian for the suggestion.

comment:6 Changed 3 years ago by hasienda

Editing the wiki documentation I found a hint regarding #9398, that suggested to document this feature.

Seem like it has been advertised before it's existence. So this has actually been a documentation bug too, but never mind, at least it's there now.

comment:7 Changed 3 years ago by hasienda

  • Cc rjollos added
  • Type changed from enhancement to defect

I stand corrected after further examination of that wiki page's history.

In #6314 JoshuaH recommended a patch to get support for relative TracLinks in WikiCalendarMacro, that has been refitted and committed in [7323] by Ryan Ollos. But this has never been propagated to WikiTicketCalendarMacro and has obviously been left out in the big macro merge [10203] too - similar story as for #9719.

That said, it's great to have this ironed out at least now. Makes me much more confident about the upcoming plugin release wikicalendar-2.0.0.

comment:8 Changed 3 years ago by hasienda

(In [11175]) WikiCalendarMacro: Correct changelog after discovering about #6314, refs #6314, #9703 and #9718.

For both of these macros it's a real pain to discover and document history
and give proper credit to contributors due to considerable activity without
proper coodination and housekeeping in the repository.

comment:9 in reply to: ↑ 5 Changed 2 years ago by ilewismsl

Replying to hasienda:

(In [11174]) WikiCalendarMacro: Enable parsing of relative wiki path patterns, refs #9718.

Works well for me. Thank you.

Have you looked at ExtractUrlPlugin and the associated Trac ticket #7728? The ticket certainly seems like a good idea. I have not had a chance to look at the associate hack yet, but it might be useful for your work.

comment:10 follow-up: Changed 2 years ago by hasienda

The excellent ServerSideRedirectPlugin utilizes this hack.

I happily use ServerSideRedirect, but for this macro I went with some code taken from trac.wiki.api.WikiSystem, which is rather clean and minimal compared to the ExtractUrlPlugin. Added bonus: Current code in this plugin saves an external dependency avoiding some possible trouble for one-shot installations.

But in general I recognized the lack of such helper method in Trac core, and would value it's integration. OTOH, Trac 0.14 as current target is rather far in the future for some development, that should be done now, right?

comment:11 Changed 2 years ago by hasienda

  • Description modified (diff)

comment:12 in reply to: ↑ 10 Changed 2 years ago by ilewismsl

Replying to hasienda:

that should be done now, right?

Yes. I just noticed the ticket and hack, because many hacks and even Trac built in macros like TitleIndex, do not handle relative links or do not handle them correctly. I just wanted to make sure you knew it existed; there are a lot of hacks. I do not understand Trac or WikiCalendar well enough to judge the right solution here and what you did works well for me.

comment:13 Changed 16 months ago by hasienda

  • Resolution set to fixed
  • Status changed from assigned to closed

(In [12842]) WikiCalendarMacro: Releasing current, tested macro package as final product, closes #64, #578, #6636, #7564, #7653, #8818, #9568, #9718 and #9719.

After a long time one of the oldest Trac hacks (see changeset [53]) is united
with its ambitious fork WikiTicketCalendarMacro for convenience.
While maintaining separate wiki pages for both macros, upstream development
continues together in the source:wikicalendarmacro/trunk branch.

comment:14 Changed 16 months ago by jun66j5

  • Resolution fixed deleted
  • Status changed from closed to reopened

I got the following on Python 2.4. str.startswith() accepts a tuple as prefix on Python 2.5+. See http://docs.python.org/2/library/stdtypes.html#str.startswith.

  File "/home/jun66j5/src/trac/trac-hacks/wikicalendarmacro/trunk/wikicalendar/macros.py", line 328, in _resolve_relative_name
    if not pagename.startswith(('./', '../')):
TypeError: expected a character buffer object
  • wikicalendar/macros.py

     
    2626 
    2727from trac.config import BoolOption, Configuration, Option 
    2828from trac.core import Component, implements 
     29from trac.util.compat import any 
    2930from trac.util.datefmt import format_date 
    3031from trac.util.text import shorten_line, to_unicode 
    3132from trac.web.href import Href 
     
    325326        This method handles absolute as well as relative wiki paths. 
    326327        """ 
    327328        # Code taken from trac.wiki.api.WikiSystem at r10905. 
    328         if not pagename.startswith(('./', '../')): 
     329        if not any(pagename.startswith(prefix) for prefix in ('./', '../')): 
    329330            return pagename.lstrip('/') 
    330331        base = referrer.split('/') 
    331332        components = pagename.split('/') 

comment:15 Changed 16 months ago by hasienda

(In [12853]) WikiCalendarMacro: Improve function for compatibility to Python2.4, refs #9718.

comment:16 Changed 15 months ago by hasienda

  • Resolution set to fixed
  • Status changed from reopened to closed

(In [12991]) WikiCalendarMacro: Releasing current, tested macro package as final product, closes #7639, #8175, #9718, #10991, #10992 and #10993.

Special thanks to Jun Omae for pushing development by testing and providing
valuable hints in our discussion about utilizing Babel for better
localization and for making macro execution thread-safe as well.

Add Comment

Modify Ticket

Action
as closed .
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from hasienda. Next status will be 'closed'.
The resolution will be deleted. Next status will be 'reopened'.
Author


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

 
Note: See TracTickets for help on using tickets.