Admittedly, not many Drupal pages will be using true locally relative links, but I encountered a small issue with them anyway.
Test-case:
before:
<a href="a.htm">A</a> -http://a.htm/ - WRONG
<a href="here/b.htm">B</a> -here/b.htm - PROBLEMATIC
<a href="../there/c.htm">C</a> -../there/c.htm - PROBLEMATIC
<a href="../d.htm">D</a> -../d.htm - PROBLEMATIC
<a href="e.com">E</a> -http://e.com/ - Looks right, but is actually WRONG
<a href="http://f.com">F</a> -http://f.com/ - RIGHT
<a href="http://g.com/">G</a> -http://g.com/ - RIGHT
after:
when run on the page '/drupal-5.1/obit/o.htm'
<a href="a.htm">A</a> -/drupal-5.1/obit/a.htm - CORRECT
<a href="here/b.htm">B</a> -/drupal-5.1/obit/here/b.htm - CORRECT
<a href="../there/c.htm">C</a> -/drupal-5.1/obit/../there/c..htm - ACCEPTABLE
<a href="../d.htm">D</a> -/drupal-5.1/obit/../d.htm - ACCEPTABLE
<a href="e.com">E</a> -/drupal-5.1/obit/e.com - ACTUALLY CORRECT
<a href="http://f.com">F</a> -http://f.com/ - CORRECT
<a href="http://g.com/">G</a> -http://g.com/ - CORRECT
I'm thinking about ../ compression, but not today.
The attached patch produces the correct results this by passing the relative $base value (the URL of the context page) through when resolving the 'normalized' URL in links_parse_url()
I'm aware that links_parse_url() is a fragile beast, but I didn't touch the regexps - just the bit after it was told NOT to $accept_bare. Auto-extracted links should never have been bare in the first case.
I'm rooting the result as if I ran url($base.$link). It may be easier if I included the full server path, but I don't like doing that for internal links, it's not portable enough. Even including the subsite path is a compromise. The question is whether the later system can handle the concept...
Patch is against todays 1.5 update.
| Comment | File | Size | Author |
|---|---|---|---|
| links_relative.patch | 4.4 KB | dman |