textpattern
Spaces swallowed on file upload in UI
This isn't a bug, per se, but does lead to unexpected behaviour under certain circumstances.
STR:
- Prepare a file for upload with the filename:
This is a test.txt(note: there are two spaces between 'a' and 'test'). - Upload via Content>Files.
- Note that the success message says that the file "This is a test.txt" (one space) has been uploaded successfully. And it's shown with one space in the file download list and on the file details panel. All good.
- Tapping to Download (hover over it) the file shows that the double space is preserved as a '++' in the file download link. Similarly, if you use the Textile/Tag/HTML tag builder, they contain the proper double spacing.
- If you are not aware of this and want to use the file in a shortcode (say) or a file_download tag to attach it to an article as a download, the user may go to the Files panel and simply copy the filename (with one space) as shown on-screen and plug it into the tag:
<txp:file_download filename="This is a test.txt" /> - This leads to the file_download tag failing because it cannot find that file in the filesystem.
This is an ultra, ultra corner case and I don't think there's anything we can do about it. But if anyone has any clever ideas on the best approach (pass filename through a regex on upload to swallow multiple spaces and use that when we move_ulpoaded_file?) then it might be handy.
This has just happened on a live site and the admin there sent me a request asking why his download tag wasn't working!
In a similar vein:
.png
(32 space characters) is saved/downloaded as png, minus the ., for hyper corner case points.
It appears GitHub Markdown truncates double spaces in inlined code.
Hmmmm yeah. Not sure if this is a problem or not. I mean, there isn't much we can do about it short of stripping some/all/double spaces on upload, which changes a user's filename and thus might be construed as meddling. I can't really see a reason for double spaces in a filename, but, y'know.