The check_plain() is called twice in the source

i tried with the latest CVS code. but it seems to working perfectly. i am using fedora core 3

I have also had this problem.

My solution:
Find the line dealing with the description in the upload.module, comment out the check_plain() function, in order not to check the description;

i dont think so the problem with the check_plain function. dont do like that because its a security issue. check your php.ini settings for below

; Magic quotes for incoming GET/POST/Cookie data.
magic_quotes_gpc = On

If the above line is there, then the existing drupal settings should work fine.

there's nothing to be done with drupal

Totally OT, but very cool to see bahai.us looking into Drupal! :D

Find the line 447 dealing with the description in the file /modules/upload.module, change the codefrom
$text = check_plain($file->description ? $file->description : $file->filename);
To
$text = $file->description ? $file->description : $file->filename;

Then everything will be ok.

The reason is:
in the following line 448:
$rows[] = array(l($text, $href), format_size($file->filesize));

the function l() is used to build the html of a link. It does the check_plain() to the variable $text again by default.

That is to say. When your description is original like : "love" & 'hate'

at the line 447 it will become: & quot;love& quot; & amp; & #039;hate& #039;

after line 448 it's changed to: & amp; quot;love& amp; quot; & amp; amp; & amp; #039;hate& amp; #039;

so you all see the results like: & quot;love& quot; & amp; & #039;hate& #039;

There isn't a patch.

The above patch works. However, it doesn't solve a larger issue which is that you can't download the files with special characters like & in there. The ampersand gets converted to %26. So if you uploaded a file called 'good&welfare.jpg', drupal tries to find a file called 'good%26welfare'. This returns a 404 error.

My last post is slighly inaccurate. You can't download files with ampersands in them because func_get_args() in the file_download() function in files.inc only returns everying up to the first ampersand. So 'good&welfare' yields 'good'.

To Steve Dondley: i checked the problem too. Exacter description is:

CASE 1:
You can upload a file named e.g. "a&b.txt" sucessfully, but after that, you cannot download it anymore, because Drupal gives a download address as http://yourdomain.com/system/files/a%26b.txt

if you look at your file directory on your server, the file is NOT there. so that is to say, Drupal didn't have got that file but it claimed yes.

CASE 2:
If the file is called "A & B.txt"(with space in the filename), so after upload, drupal will give a download URL as download address as http://yourdomain.com/system/files/a+%26+b.txt

The file is now really on the server, but you cannot download it. If you type the url as
http://yourdomain.com/files/a%20&%20b.txt

Bump! It shows. if you try http://yourdomain.com/system/files/a%20&%20b.txt, the same problem: page not found.

So the problem should be with the intepretaion of filename in the upload.module. I'll try to figure that out next week.

Finally i figure the problem out! It's just the same problem with check_plain(), but this time because of check_url()! Interesting is, check_url() will use check_plain() in its routine(see http://api.drupal.org)

Here is the solution ;-)

find line 446 with

      $href = check_url(($file->fid ? file_create_url($file->filepath) : url(file_create_filename($file->filename, file_create_path()))));

chage it to

      $href = ($file->fid ? file_create_url($file->filepath) : url(file_create_filename($file->filename, file_create_path())));

If you see line 448, you will find our old friend l() function, which calls check_plain() and check_url() in its routine:

      $rows[] = array(l($text, $href), $file->filemime, format_size($file->filesize));

so i attach here a modified upload.module, which includes the two patchs above and a Show-File-Type-In-The-Attachment-List modification. Hope everybody will be happy!

Sorry, the above patched upload.module only works when the "download method" is set up as "public". With "private" is there still something to be done.....:-(

motou:

This solved it for me: http://drupal.org/node/76503

http://drupal.org/node/68886

This patch as also comitted to 4.7 and is in 4.7.3.