Opened 12 years ago
Last modified 11 years ago
#9718 closed defect
Resolve relative wiki paths in pattern for wiki pages too — at Version 11
Reported by: | Steffen Hoffmann | Owned by: | Steffen Hoffmann |
---|---|---|---|
Priority: | normal | Component: | WikiCalendarMacro |
Severity: | normal | Keywords: | wiki page |
Cc: | Ryan J Ollos | Trac Release: | 0.11 |
Description (last modified by )
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.
Change History (11)
comment:1 Changed 12 years ago by
Status: | new → assigned |
---|
comment:2 Changed 12 years ago by
Description: | modified (diff) |
---|---|
Severity: | major → normal |
Type: | defect → 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 12 years ago by
Summary: | Regression: wiki path generation from pattern is not relative to current page. → Wiki path generation from pattern is not relative to current page. |
---|
comment:4 Changed 12 years ago by
Summary: | Wiki path generation from pattern is not relative to current page. → Resolve relative wiki paths in pattern for wiki pages too |
---|
comment:5 follow-up: 9 Changed 12 years ago by
(In [11174]) WikiCalendarMacro: Enable parsing of relative wiki path patterns, refs #9718.
Thanks to Ian for the suggestion.
comment:6 Changed 12 years ago by
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 12 years ago by
Cc: | Ryan J Ollos added; anonymous removed |
---|---|
Type: | enhancement → 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 12 years ago by
(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 Changed 12 years ago by
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 Changed 12 years ago by
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 12 years ago by
Description: | modified (diff) |
---|
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.