Resolve relative wiki paths in pattern for wiki pages too

[Steffen Hoffmann]

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.

[Steffen Hoffmann]

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.

[Steffen Hoffmann]

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.

[Steffen Hoffmann]

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

Thanks to Ian for the suggestion.

[Steffen Hoffmann]

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.

[Steffen Hoffmann]

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.

[Steffen Hoffmann]

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

[Ian Lewis]

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.

[Steffen Hoffmann]

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?

[Ian Lewis]

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.

[Steffen Hoffmann]

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

[Jun Omae]

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

@@ -26 +26 @@
 
 from trac.config import BoolOption, Configuration, Option
 from trac.core import Component, implements
+from trac.util.compat import any
 from trac.util.datefmt import format_date
 from trac.util.text import shorten_line, to_unicode
 from trac.web.href import Href
@@ -325 +326 @@
         This method handles absolute as well as relative wiki paths.
         """
         # Code taken from trac.wiki.api.WikiSystem at r10905.
-        if not pagename.startswith(('./', '../')):
+        if not any(pagename.startswith(prefix) for prefix in ('./', '../')):
             return pagename.lstrip('/')
         base = referrer.split('/')
         components = pagename.split('/')

[Steffen Hoffmann]

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

[Steffen Hoffmann]

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