From what I can see an easy fix is this, for l(): Drupal 5 -------- check_url(url($path, $query, $fragment, $absolute)) To check_url(urldecode(url($path, $query, $fragment, $absolute))) Drupal 6 -------- check_url(url($path, $options)) To 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 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