Joomla input filter properties tagBlacklist and attrBlacklist have been renamed, possibly leading to incorrect post filtering. When you are using the HTML Purifier filtering method we are automatically reading the Joomla filtering configuration for the current user and applying it as the HTML Purifier configuration. Joomla renamed the properties of the core object providing this configuration in an attempt to remove offensive wording, without deprecating them first (as is necessary for software following the Semantic Versioning standard which Joomla claims to do) and without providing a legacy fallback (a trivial thing to do using PHP's magic __get method). As a result all user groups ended up falling back to the default HTML filtering of HTML Purifier. This is typically more restrictive than what you'd have configured in Joomla itself.
Joomla 4 improvements. We applied necessary changes in our code to support Joomla 4 beta 7. Along with that came a few unexpected but welcome improvements. Labels in the tabbed interface elements are more legible. Custom selects are now rendered as native selects. Checkboxes are rendered as native checkboxes. Long lists and multiselect lists are back into using Chosen for easier item selection.
Darker Dark Mode. Our Dark Mode was intentionally designed to be somewhat bright. This had two side-effects. On one hand it was brighter than the dark templates most people would use. Moreover, the contrast between the background and the text was inadequate for people with vision-related disabilities. Considering that Dark Mode is (also) an accessibility feature we addressed this concern.
Removed the recommended PHP version. This has been a source of confusion. The recommended PHP version was placed in the code manually when a new version was finalised, which would typically be two to three weeks before it's released. The previous version released in early January was finalised between around December 3rd, before PHP 7.3 entered its final ‘security fixes only’ support phase. This led to the discrepancy of our software warning you that PHP 7.3 is getting old in the tooth and needs to be upgraded but also saying that the recommended version if 7.3. Since the PHP version warning is time-based, using the official PHP supported versions timeline dates, we decided to remove the recommended versions altogether from these messages and replace them with a note in our Compatibility page that you should always use the latest version of a currently supported PHP branch which is marked as being in ‘active development’.
New ticket fields do not persist failed validation. This is an issue that caught many a client unaware. Let's say you have a ticket category where all tickets are public by default and the user chooses to file a private ticket. Let's say that you also have a number of fields, some of which are mandatory and fail validation. The reasonable expectation of the user is that upon the form reloading with a validation error they would only need to change the fields that failed validation. What happened in fact is that the ticket had switched back to public because the state of that field was not preserved when the tickegt form validation failed and the page reloaded. We have no addressed that issue, making the behavior of Akeeba Ticket System consistent with the users' reasonable expectation. It was a design choice albeit an unfortunate one so we're treating this as a bug.
Reply text not persisted when someone else replied before we submitted our own reply. That's another case of things working as designed but not as reasonably expected. When you tried to reply to a ticket but the user or another ticket manager had replied to it you received a message that another reply has been posted and your ticket reply text was forever gone. While this makes sense in some circumstances — you probably don't want to post a reply that's inconsistent with the information posted in the meantime — it's annoying that you lost all your text. In many cases you could just edit it and shape it to a reply that you would have liked to be able to post. We fixed that by preserving the text in the editor when we display the message that another reply has been posted in the meantime.
Bug fixes and minor improvements. Please take a look at the CHANGELOG below.
Please consult our Compatibility page to see which PHP and CMS versions are supported by each version of our software. This page is generated from the metadata attached to each version as it is released on our site.