Edgewall Software
Modify

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

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.

comment:2 Changed 5 years ago by cboos

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

... and the reason was precisely that r4442 was not merged, damn ;)
Corrected in r4461.

comment:3 follow-up: 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: 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)
View

Add a comment

Modify Ticket

Change Properties
<Author field>
Action
as closed
The resolution will be deleted. Next status will be 'reopened'
to The owner will be changed from cboos. Next status will be 'closed'
Author


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

 
Note: See TracTickets for help on using tickets.