Interwiki::getURL() accepts an argument, the string to replace $1 with.
However it doesn't urlencode it so $interwiki->getURL( 'A&B' ); can
return
http://somewiki.com/index.php?title=A&Bmp;B, so the outside caller is
required to do the urlencoding instead of the getURL where it should be
done (especially since getURL is the one that better understands the
context that $1 is in).
Scanning all of trunk and the extensions folder, it doesn't seam like
ANY part of core or any extensions make use of Interwiki::getURL with
the argument. If any use it they omit the argument and work like
Title::getFullURL which itself urlencodes data and does the substitution
of $1 on it's own outside of the Interwiki class.
Anyone have an objection to me changing the code so that
Interwiki::getURL properly urlencodes it's input and accepts normal text
instead of text required to be pre-urlencoded?
Pros:
- Saner api
- In the future we have the option of deciding to use different
urlencoding calls depending on if $1 is located in the path portion of
the url or the query portion of the url if it makes sense (like if we
ever get [[google:foo bar]] fixed we can use + instead of %20).
Cons:
- If someone later tries to use Interwiki::getURL inside an extension
the argument behavior will be different between versions before 1.19 and
1.19 and after. ie: They'll have to version test for 1.19 and if older
add a wfUrlencode call themselves.
--
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [
http://daniel.friesen.name]