-
2011-11-15
erial2
I tested Angua RC1 yesterday. New uploader seems work till I select multi files.
Upload status rings round, round, and end.
It looks like well done. But files not apear on list.
I tested another files. I think that problem apear in NO ALPHABET named files.
I upload '天上天下唯我独尊_壁_縦UXGA.png' but it renamed 'UXGA.png'. Um...that's all right. It uploaded.
and...I upload '懐かしのらびたん.jpg'. It renamed '_.jpg' but IT DOESN'T APEAR IN LIST.
I think new uploader couldn't get file names well in UNICODE files now.
Um...I tested in rename MY HAND. '_.jpg -> test.jpg' And it WORKS WELL.
That's not big bug. But...I want to fix that bugs.
-
2011-11-28
ploeger
The problem lies in inc/search.php, line #33, where files starting with _ are kept out of search results. The way we handle non-ASCII-characters is by replacing everything else with an underscore. If the filename ONLY has non-ASCII-characters, this leads to _.png, which is excluded from the search.
I will post this to the mailing list for further investigation and solving.
-
2011-11-28
andi
There are two problems here:
1. The JavaScript that prefills the "upload as" field strips too much. It should only remove special chars, similar to what cleanID does.
2. The backend accepts an upload with an invalid ID. "_.jpg" should not be accepted.
-
2011-11-28
andi
Hmm I just learned that cleanID() has a third parameter called $media which explicitly allows leading and trailing underscores. I can not remember why we (or I) added this, but this suggests that _.jpg would indeed be a valid media ID and should be listed.
-
2011-11-28
andi
This third parameter is used only twice in the whole code base, both times for uploading. This means the current code base allows uploading files which can not be listed or downloaded (/lib/exe/fetch.php?media=_.jpg results in a 404).
So instead of going through the whole codebase to make these IDs possible to use, I'll remove the uploading of these files and obsolete the parameter instead.
-
2011-11-28
andi
-
Related tasks: