Support

No, this is a problem with your PHP configuration. You can set whatever upload size in media manager. If it's larger than PHP's max_upload_size or post_max_size it will be reduced to the smaller of these two PHP configuration values.

The default settings of max_upload_size and post_max_size are, indeed, 2MB.

Also remember that Cron Jobs are handled by a different PHP executable than web requests. Each PHP executable has its own configuration file, independent from other PHP versions' or executables' configuration files. I understand that you are using a CRON job to fetch the emails which means that you need to edit the configuration for that PHP CLI version and set max_upload_size and post_max_size to 10M.

The .user.ini file only applies to PHP-FPM. PHP-FPM uses the PHP CGI binary (it's the same binary for CGI and FastCGI) which has one set of configuration, the one that you can edit through your hosting control panel.

The CRON job runs though the PHP CLI binary. Typically, its configuration is not accessible through the hosting control panel. Moreover, the .user.ini file does not apply to it. You can either ask your host to change its configuration or, as you did, change its configuration in the command line if it is allowed.

Also, we are not entirely sure if /usr/bin/php is PHP-CLI or PHP-CGI on your server, or which PHP version it actually is. It is very possible (almost certain!) that your server runs multiple versions of PHP. While your site has been configured to use PHP 7.4 — via a .htaccess line which selects the correct PHP-FPM instance using an AddHandler or SetHandler directive — the /usr/bin/php would be the default PHP version of your server which could be a different one, e.g. PHP 7.3.

Please do ask your host to confirm the path of the PHP CLI binary for PHP 7.4 and use that in your CRON command line. Then please do ask them to change the two configuration settings I told you about in the PHP CLI configuration.

I am currently working on rewriting Akeeba Ticket System for Joomla 4. The past two days I have actually been working on the email receiving feature. I have found out a few things:

• UTF-8 subjects: this is caused partially because of how Horde decodes UTF-8 and partly legacy code from the Joomla 1.x/2.5 days. Some characters like ü can be expressed in UTF-8 in different ways. For example, ü can either be a single glyph (U with dieresis) or a combination of the U glyph and the dieresis glyph. The former works. The latter introduces an issue when creating the ticket URL alias. Now that I know what the problem is I can solve it. This will be fixed in ATS 4 for Joomla 3, it's literally adding one character in one line of code and removing another line of code.
• Horde says it's compatible with PHP 5.3 and later. What it does NOT say is that it doesn't work correctly with PHP 7.4 and not at all with PHP 8. The PHP 7.4 compatibility issues result in the message envelope not being read correctly. On PHP 8 it bombs out completely because Horde uses a while(...each(...)) construct instead of a foreach(...). That's the kind of code people wrote in the early PHP 4.0 days. Luckily there's Rector which can address these issues. I am not 100% confident I can backport this to ATS4 for Joomla 3 but I will try...
• Horde could not be updated anymore because it's distributed via PEAR and the Composer to PEAR bridge was removed in Composer 2.0. I need to implement a special trick to get it updated. Sure, yes, I can use an older Composer version — however, the PEAR bridge in the latest Horde adds hardcoded paths specific to my computer which means I need to do some additional workarounds to replace them with relative paths.

I hate having to use Horde but I have no choice :( Gmail / GSuite moved away from standard IMAP authentication and into XOAUTH2. The only PHP library which supports XOAUTH2 authentication is Horde. Yahoo and Microsoft now also use XOAUTH2 so it's not like I can pretend I can go back to using PHP's imap extension. Even more so when the PHP developers have said that the C library it uses internally hasn't been updated since 2007 and there's fat chance anyone will ever implement any additional features, including XOAUTH2, in it. Yikes. We are left with two options: use Horde or remove any feature that reads email. The latter is not a realistic option so Horde, with all its drawbacks, it is then!

Regarding the attachment size, I will investigate further today. I have so far found that the size of the attachment doesn't matter; Horde reads it fine. The most likely problem is the extension of the file. If it doesn't match Joomla media manager's acceptable list of extensions it won't be included in the ticket. I will take a wild guess and say that you are trying to upload a ZIP file but the zip extension is not allowed by default in Joomla; you'd have to add it manually in the Media Manager's Options page. I will also guess that it's very likely that the extension is .ZIP (uppercase) instead of .zip (lowercase) but since Joomla's file extension checks are case–sensitive it blocks the upload.

I am working on workaround for the checks on filenames and the file extensions BUT this requires an overhaul of the attachments upload feature which means that it will only be available in Akeeba Ticket System 5 for Joomla 4 only. We are no longer adding any new features to ATS4 or our Joomla 3 software in general as we explained in mid–August 2021. Joomla 3 has an expiration date of August 17th, 2023 and our clients are already moving en masse to Joomla 4. Based on our usage stats, the month–over–month use of Joomla 4 is more than doubling. In fact, if we break it down to weeks it shows an accelerating trend. There's no business sense in spending time to complete a big refactoring for ATS 4's attachments when less than half of our clients will be using Joomla 3 by the time we are done. It makes more sense to implement the new features in ATS 5 for Joomla 4.

Not a waste of time at all! In fact, your tickets came at the perfect time :) Email parsing is very complicated. I need to spend a day or so to “load” all that code in my mind and set up a bunch of mail servers and email accounts to troubleshoot deeper issues. As it happens, yesterday was the second day I was working exclusively on that code so what better time to troubleshoot it than now? That's why I was able to figure out the UTF-8 issue immediately. That code felt “icky”. You gave me enough information to reproduce your issue, track it down to the icky code and fix it.

Regarding the 2MB limit, I cannot reproduce it with the updated version of Horde. I actually did try it with a 2.9MB JPEG and it works great.

In the latest version of Horde the 2MB limit applies to parsing MIME–encoded email parts on the web server. However, as it has been the case since we implemented replies by email, we are asking the mail server to decode the MIME part. I confirmed that we are receiving the full binary contents of the attachment, we save it properly and that they are correct down to the last byte.

I am not sure about the older Horde version used in ATS4, though. My plan is to use the same Horde version in both versions of ATS for my sanity's sake. So... this problem is MOST LIKELY going to be resolved in the next release.

You don't need to reply to this ticket. You can either let it auto–close in 4 weeks or you can come back here and close it yourself.