[#35808] - Media Manager changes folder and file names to all lowercase
- Closed
- 15 Nov 2021
- Medium
- Build: 4.0.3
- # 35808
Steps to reproduce the issue
From the administrator interface, use the media manager to
(i) create a folder with upper case characters in its name, or
(ii) upload an image with upper case characters in its filename.
Expected result
Names should be created as they have been input.
Actual result
All uppercase letters are converted to lowercase (both as displayed, and as the actual folders or files are created within the folder ).
System information (as much as possible)
PHP : version 7.4.23.
Build : Joomla! 4.0.3 Stable [ Furaha ] 12-September-2021 10:39 GMT
Browser : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:93.0) Gecko/20100101 Firefox/93.0
Database : MySQL 5.7.35-cll-lve
Customer : I'm an administrator for the site.
Web Server : Apache (version number not easily accessible).
Additional comments
The behaviour reported here is different from Joomla 3.9, and from my perspective as a user it is a difference that is not wanted, which is why I am reporting it as a bug.
I note that, if I use the underlying filesystem to change the lowercase back to uppercase, the media manager displays the changed names correctly, so I can not see any technical reason for the Media Manager to make these changes to names.
| Labels |
Removed:
?
|
||
joomla-cms-bot
- | Labels |
Added:
No Code Attached Yet
|
||
I reproduced this. I made a folder called "CAP_letters" and it changed it to "cap_letters".
Maybe it depends on if you're on Linux or Windows hosting. It would make sense, to have all lower case so you don't confuse file names. "This_Image.JPEG" is different to "this_image.jpeg" on Linux. Windows doesn't care one way or the other.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35808.
(sorry for second comment - can't seem to edit my other comment); also reproduced this on a localhost Windows 10 running WAMPServer. "CAPS_letter" changes to "caps_letter" folder name. Changing the name to "CAPS_letter" retains that then in Media Manager.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35808.
I've now upgraded to 4.04, and am still seeing the same problem.
The suggestion from AMurray2016 sounds plausible, but if it was necessary to accommodate Windows 10 hosting in this way I would have expected to see this behaviour as an option in the global configuration, and I can't find any such option.
So I think that the bug is still there.
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/35808.
The media manager doesn't change the folders to lower case. All we do is to create a folder by using the CMS filesystem API. So this is an OS feature/limitation where we don't have any influence.
As a user, my view of the problem is that it arises from using the media manager, and the issues of where that problem lies in the code that the media manager is not very helpful.
As a (now retired) software engineer, I can see from this code that the functions createFolder() and createFile() both invoke getSafeName(), and that this then invokes File::makeSafe(). Having found the PHP code for that, I can see that it invokes the PHP library function transliterator_transliterate() with a set of rules as a parameter. The PHP Manual doesn't document these rules, but it seems pretty obvious that the one called Lower() is going to convert the string to lower case.
This is precisely the behaviour that I as a user don't want, not least because it is different from the behaviour of Joomla version 3.
As I said above, I think that this should be handled by making the use of this conversion dependent on a configuration parameter for the media manager. Then those of us who do not want media file names converting like this (and who are using unix-based hosting) can switch the conversions off.
| Status | New | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2021-11-15 08:01:07 |
| Closed_By | ⇒ | laoneo |
Could not re-procedure the issue with 4..0.4