[development] Wrong usage of urlencode and drupal_urlencode

Wim Mostrey drupal at mostrey.be
Wed Apr 11 09:18:13 UTC 2007

 From what I can see an easy fix is this, for l():

Drupal 5

check_url(url($path, $query, $fragment, $absolute))


check_url(urldecode(url($path, $query, $fragment, $absolute)))

Drupal 6

check_url(url($path, $options))


check_url(urldecode(url($path, $options)))

This needs extensive testing to see the impact on url-aliases and such 
ofcourse. An alternative would be to not use url() in l() but to create 
a seperate function that doesn't include urlencoding, since you don't 
need it anyway if you're using l().


Wim Mostrey wrote:
>  From the php.net handbook:
> "This function is convenient when encoding a string to be used in a 
> query part of a URL, as a convenient way to pass variables to the next 
> page."
> Currently the urlencode function is not only used for passing the url 
> but also for displaying it, using l() for instance. Many modules 
> experience errors because of this issue: upload, filefield, image, 
> imagecache, .. Also just linking to a filename using l() fails. The 
> value field always contains the correct filename (for example "this is 
> a+test.pdf") while the actual link refers to the urlencoded filename 
> (for example "this+is+a%2Btest.pdf" or "this+is+a+test.pdf") on which it 
> breaks, since that file does not exist.
> I feel that while url() shouldn't be altered, l() should urldecode (or 
> have a drupal_urldecode) the output created by url(). Currently all 
> those modules are fixing this issue themselves, or are not addressing 
> the issue at all, while I believe core should address this.
> Wim

More information about the development mailing list