#31301 – Attachment: file with .JPG (uppercase file extension) cannot be uploaded

Posted in ‘Akeeba Ticket System’
This is a public ticket. Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.
Monday, 29 April 2019 15:19 CDT
Hi Nicholas,

I hope you and your lovely family are all well. Long time no see since the last Joomla event ;-)

I am still enjoying working with ATS since May 2013. Today, a client of mine came across a weird issue with attachment to a ticket, where a file with .JPG (uppercase file extension) cannot be uploaded. I did further tests, but the same file just renamed with .jpg (lowercase) can be uploaded. My Test user is only authorised in frontend.

After a few search, I found this very instructive ticket, and I've checked my settings also in the Joomla Media manager.

So I did test in the media manager with the same two files, with the same user, with Edit permission in a frontend joomla article (and not Administrator or Super User of course). Both could be uploaded, but the uppercase .JPG file extension has been automatically changed to lowercase .jpg.

My Media > Options are (and see attached)
- Legal Extensions (File Types) : bmp,csv,doc,gif,ico,jpg,jpeg,odg,odp,ods,odt,pdf,png,ppt,txt,xcf,xls,BMP,CSV,DOC,GIF,ICO,JPG,JPEG,ODG,ODP,ODS,ODT,PDF,PNG,PPT,TXT,XCF,XLS
- Legal Image Extensions (File Types) : bmp,gif,jpg,png
- Legal MIME Types : image/jpeg,image/gif,image/png,image/bmp,application/msword,application/excel,application/pdf,application/powerpoint,text/plain,application/x-zip

My default settings are updated from

I did another test with changing the Media > Options and adding the uppercase file extensions:
- Legal Image Extensions (File Types): bmp,gif,jpg,png,jpeg,BMP,GIF,JPG,PNG,JPEG

This time ATS did accept my .JPG file. And still fine directly in Media manager.

Any idea why this is happening? If it happens to be a Joomla issue, I will report it in the Issue Tracker.
Please let me know if I can perform any further test to help you.

Kind regards,
Custom Fields
Joomla! version (in x.y.z format) 3.9.4
PHP version (in x.y.z format) 5.6.40
Akeeba Ticket System version (x.y.z format) 2.4.3
Tuesday, 30 April 2019 00:44 CDT
Hello Herve! We're doing good, thank you :)

The TL;DR version is that what you experienced is the normal way Joomla works and there's no reason to be worried. The rest of the reply is a more technical discussion of how uploads work in ATS and Media Manager, their different context and explain their different behaviour.

ATS is using Joomla's API to handle uploads, namely the JHelperMedia::canUpload() method. This is a "black box" as far as our code is concerned. It will return false if Joomla rejects the upload based on the settings in Media Manager.

So let's shed some light into the black box, shall we? ;)

First, Joomla checks if the file's extension is within the "Legal Extensions (File Types)" list. In both cases the file is. There is, however, a second check. If you have enabled the "Restrict Uploads" option in Media Manager's Options page the JHelperMedia will check if the extension of the file belongs in the "Legal Image Extensions (File Types)" list. Before you made the change the uppercase JPG extension was not in that list, therefore the file failed to upload.

As for why the Media Manager works differently: it converts the file name to lowercase before calling the JHelperMedia::canUpload() method. In this case the lowercase .jpg extension is in both "Legal Extensions (File Types)" and "Legal Image Extensions (File Types)" lists. Therefore the file can be uploaded and that explains why the extension is lowercase.

The problem is that this essentially renames the file without asking you. This is perfectly acceptable for a Media Manager but not for a ticket system, where the filename may carry significance depending on the use case. Moreover, ATS does not store the file using its nominal filename and extension. We store it with a random alphanumeric key as its filename and store the filename and extension in the database. We only use the filename and extension when you are trying to download the file. This makes the security issues Joomla is trying to mitigate in the Media Manager completely moot (inapplicable to our case) which is why we don't try to make the filename safe, convert it to punycode and lowercase it like Joomla's Media Manager does. You can say that ATS is more lax with filenames because its indirect access to the file (the download goes through Joomla's index.php instead of the server directly) affords us this luxury.

So, what you observed is the expected Joomla behaviour, therefore there is no bug in either Joomla or ATS. What you did was the correct solution to the problem you experienced. No need to file any bug reports :)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic

Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Tuesday, 30 April 2019 07:57 CDT
Hello Nicholas!

I'm pleased that you are all good ;-)

Thank you very much for your detailed and very well documented reply! I have learned something new, and I am very glad there is no bug to report, and to have done the correct solution for my next clients, users of ATS in the frontend.

A short addition to the ATS documentation, with a link to this ticket, may be useful for other users to get a better configuration for attachments to ticket ;-)

Have a great day and week!
Wednesday, 01 May 2019 01:40 CDT
Our policy is to not provide support or documentation for core Joomla features because then we have to track two feature sets: ours and Joomla's. We trust that our clients know how to build Joomla sites and troubleshoot core Joomla issues -- as you demonstrated :)

Yes, I know that ATS' documentation still contains references to articles on using Joomla ACLs. When the documentation was first written, in 2011, ACLs were still a new thing for most of our clients migrating from Joomla 1.5. Joomla's documentation was very sparse on information on the topic and there were too few people who actually knew how this feature worked, making it unlikely that someone could find peer help on the forum. In that context we had to point people to documentation on Joomla ACLs, something which will be removed. I just didn't have the time last year to deal with deep documentation refactoring. Between GDPR, launching Admin Tools for WordPress, modernizing our code base in preparation for PHP 7.4 and Joomla! 4 and implementing a new, more efficient to sell subscriptions -- not to mention having a baby -- my time for documentation has been extremely limited. Hopefully this summer I'll be able to focus on documentation :)

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native

🇬🇧English: excellent

🇫🇷French: basic

Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

This ticket is closed, therefore read-only. You can no longer reply to it. If you need to provide more information, please open a new ticket and mention this ticket's number.

Support Information

Working hours: Typically we work Monday to Friday, 9am to 7pm Cyprus timezone (EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets, but we cannot respond to them, outside of our working hours.

Support policy: We would like to kindly inform you that when using our support you have already agreed to the Support Policy which is part of our Terms of Service. Thank you for your understanding and for helping us help you!

Cookies Notification - Action required

This website uses cookies to provide user authentication and improve your user experience. Please indicate whether you consent to our site placing these cookies on your device. You can change your preference later, from the controls which will be made available to you at the bottom of every page of our site.