Support

Akeeba Ticket System

#42598 Bug in backend attachments?

Posted in ‘Akeeba Ticket System for Joomla! 4 & 5’
This is a public ticket

Everybody will be able to see its contents. Do not include usernames, passwords or any other sensitive information.

Environment Information

Joomla! version
5.4.2
PHP version
8.4.16
Akeeba Ticket System version
5.4.2

Latest post by nicholas on Tuesday, 13 January 2026 01:04 CST

genr8r

Happy New Year Nicholas!

I think I hit a small bug in trying to add attachments to a ticket in the backend of ATS.

Feel free to let me know if I am in error if there is another fix for this.

Thanks,
Brian

 

 Problem

When adding a reply to a ticket in the admin backend, the Attachments subform displays the repeatable rows with +/- buttons, but the file input field ("Choose File" button) does not render inside each row.

Root Cause

Layout path mismatch between the form definition and the actual layout file location:

  • Form XML (administrator/components/com_ats/forms/post_new.xml:61) specifies:

    • layout="akeeba.ats.field.file"

       
  • Admin layout file exists at:

    • administrator/components/com_ats/layouts/akeeba/ats/fields/file.php

       

      (Note: fields plural)

  • Frontend layout file correctly exists at:

    • components/com_ats/layouts/akeeba/ats/field/file.php

       

      (Note: field singular)

The admin layout directory uses fields (plural) while the form XML and frontend use field (singular). Joomla cannot locate the layout, so the file input doesn't render.

Fix

Rename the admin layout directory from fields to field:

administrator/components/com_ats/layouts/akeeba/ats/fields/ → administrator/components/com_ats/layouts/akeeba/ats/field/

genr8r

Hi Nicholas,

This one is closely related enough to put it in the same ticket...

Brian

Problem

The maximum upload size displayed next to attachment file fields shows the value in bytes instead of megabytes. For example, with upload_maxsize set to 10 MB in ATS options, the interface displays "Maximum upload size: 10.00 b" instead of "10.00 MB".

Root Cause

In the custom file field layouts:

  • administrator/components/com_ats/layouts/akeeba/ats/field/file.php (line 95)
  • components/com_ats/layouts/akeeba/ats/field/file.php (line 95)

The code passes the upload_maxsize value to Utility::getMaxUploadSize() as a bare integer.

$custom = ComponentHelper::getParams('com_ats')->get('upload_maxsize', 10); $custom = intval($custom ?? 0) <= 0 ? null : $custom; // Returns: 10 $maxSize = HTMLHelper::_('number.bytes', Utility::getMaxUploadSize($custom));

 

However, Utility::getMaxUploadSize() internally calls HTMLHelper::_('number.bytes', $custom, '') to parse the custom value. This helper expects a string with a unit suffix (e.g., "10M", "25MB"). When it receives just 10 without a suffix, it interprets it as 10 bytes.

Fix

Append the 'M' (megabytes) suffix before passing to getMaxUploadSize():

$custom = intval($custom ?? 0) <= 0 ? null : $custom . 'M';

 

nicholas
Akeeba Staff
Manager

Happy New Year!

Correct, you need to change the layout to akeeba.ats.fields.file.

I have fixed this since December 3rd, but I wasn't going to make a new release over the holiday season when people are away and I was planning on taking ten days off. Now I am going through the far increased workload right after the holidays. Hopefully, I will be able to make a release before February, but I am not holding my breath...

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

genr8r

No worries Nicholas,

I have it corrected in our setup already, just hoping lighten your bug squashing load a bit.

Sorry I hit two items in the same ticket. You might want to check my Thursday, 08 January 2026 12:12 CST comment too for the next update.

Thanks for great support on a great product!

Brian

nicholas
Akeeba Staff
Manager

You can change this:

$custom  = ComponentHelper::getParams('com_ats')->get('upload_maxsize', 10);
$custom = intval($custom ?? 0) <= 0 ? null : $custom;
$maxSize = HTMLHelper::_('number.bytes', Utility::getMaxUploadSize($custom));

To this:

$custom  = ComponentHelper::getParams('com_ats')->get('upload_maxsize', 10);
$custom  = intval($custom ?? 0) <= 0 ? null : $custom;
$custom = ($custom !== null && $custom > 0) ? ($custom . 'M') : null;
$maxSize = HTMLHelper::_('number.bytes', Utility::getMaxUploadSize($custom));

I believe that this will address that issue.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

genr8r

One more note on this...

Updating the admin directory path per my Thursday, 08 January 2026 12:02 CST comment breaks an item for the time spent field in the backend layout.

 

File: administrator/components/com_ats/src/Field/TimespentField.php line 17

// Current (broken) protected $layout = 'akeeba.ats.fields.timespent';

// Should be protected $layout = 'akeeba.ats.field.timespent';

 

Thanks,
Brian

 

nicholas
Akeeba Staff
Manager

No, that does not need to change.

The layout for this field always comes from administrator/components/com_ats/layouts/akeeba/ats/fields/timespent.php which means that the $layout property must be 'akeeba.ats.fields.timespent'. The field class itself overrides the getLayoutPaths() method to fetch the layout file from the correct location regardless of whether you are in the front- or backend of the site.

The field displays correctly in both the front- and backend on Joomla 5.4 and 6.0 using the code as shipped. This code was last updated in October 2021. I confirmed this behavior before replying to you.

Yes, that's right, this implementation means that you cannot override this particular field layout. This is intentional.

The timespent field is just a number field with an extra "Start Timer" / "Stop Timer" button which uses a small bit of JavaScript to auto-update the field's value every second. This JavaScript needs to know the DOM structure of the rendered Joomla field to find the correct INPUT element relatively to the button being clicked. If I allowed you to override this layout, the JavaScript would break. Instead of having me write custom JS for every client with an override to a field only shown to internal staff I chose to prevent you from overriding it instead.

Nicholas K. Dionysopoulos

Lead Developer and Director

🇬🇷Greek: native 🇬🇧English: excellent 🇫🇷French: basic • 🕐 My time zone is Europe / Athens
Please keep in mind my timezone and cultural differences when reading my replies. Thank you!

Support Information

Working hours: We are open Monday to Friday, 9am to 7pm Cyprus timezone (EET / EEST). Support is provided by the same developers writing the software, all of which live in Europe. You can still file tickets outside of our working hours, but we cannot respond to them until we're back at the office.

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!