Ticket #4411 (closed defect: fixed)
Opened 5 years ago
Last modified 5 years ago
absurls in wiki_to_html doesn't seem to take care of relative links
| Reported by: | ittayd@… | Owned by: | cboos |
|---|---|---|---|
| Priority: | high | Milestone: | 0.11 |
| Component: | wiki system | Version: | 0.10.3 |
| Severity: | normal | Keywords: | |
| Cc: | |||
| Release Notes: | |||
| API Changes: | |||
Description
i have a page with 'Page' link. using wiki_to_html(text, self.env, req, absurls=True) still leaves the href as '<a href="./SomeOtherPage?">'
Attachments
Change History
comment:1 Changed 5 years ago by cboos
- Component changed from general to wiki
- Milestone set to 0.11
- Owner changed from jonas to cboos
- Priority changed from normal to high
comment:2 Changed 5 years ago by cboos
- Resolution set to fixed
- Status changed from new to closed
comment:3 follow-up: ↓ 5 Changed 5 years ago by ittayd@…
my case was that i was trying to use wiki_to_html from one page in another. this means my 'req' contains the wrong href. is this solved with contexts?
comment:4 Changed 5 years ago by ittayd@…
and why not use urlparse?
comment:5 in reply to: ↑ 3 Changed 5 years ago by cboos
Replying to ittayd@qlusters.com:
my case was that i was trying to use wiki_to_html from one page in another. this means my 'req' contains the wrong href. is this solved with contexts?
Yes, that's the purpose of the Wiki contexts.
and why not use urlparse?
... and why use it? Sorry, but maybe you should be more explicit here.
The [./SomeOtherPage Page] link now work as advertised in trunk, AFAICT:
it will produce a link to a sub-page of the current page.
For a sibling page, you'd have to use [../SomeSiblingPage Next Page].
In addition, if the rendering context specifies abs_urls=True, then the generating links will be absolute ones.
comment:6 follow-up: ↓ 7 Changed 5 years ago by ittayd@…
to elaborate:
- say i'm in page foo/bar/zoo, and i call wiki_to_html on A/B/C, then if it contains D, the url will be http:/.../wiki/A/B/D.
- urljoin provides the functionality of joining a base and relative url.
comment:7 in reply to: ↑ 6 Changed 5 years ago by cboos
What you described was the 0.10 behavior, which tried to make the behavior of relative TracLinks similar to those of relative URLs.
I changed this semantic for 0.11 (as documented in r4442), because there was no way to take the current page into account, which is required for being able to create relative links to sub-pages. With URLs, you obviously don't have this issue, as anything which is not prefixed will be relative to the current page. Conversely, in the Wiki, non-prefixed links are still "absolute" ones, e.g. linking to TracBrowser from anywhere in the Wiki, however deep, still links to .../wiki/TracBrowser.
So, for relative TracLinks written in some content attached to page A/B/C, we have the following semantics:
| TracLinks | 0.10 | 0.11 |
| . | A/B parent | A/B/C self |
| .. | A/B/D grand-parent | A/B parent |
| ./D | A/B/D sibling | A/B/C/D sub-page |
| ../D | A/D uncle... | A/B/D sibling |
Not to mention that without WikiContext (so in 0.10), you have no ways to specify links relative to page A/B/C when calling wiki_to_html in page foo/bar/zoo.
With 0.11, if ctx is set to be the context for wiki:foo/bar/zoo, then rendering A/B/C content with correct relative links is a matter of calling:
ctx('wiki', 'A/B/C').wiki_to_html(abc_content)



Well, this should have worked in trunk, since the introduction of WikiContext and the related refactoring of relative links (r4442).
... but apparently it's broken for some reason, I'll check.