Minimum requirements raised to PHP 7.1, Joomla 3.9. In an effort to support the upcoming Joomla 4.0 we had to do major and far-reaching changes to our software. Some of the necessary changes were impossible while supporting older PHP versions such as 5.6 and 7.0 – versions of PHP which have been end of life for well over a year. As noted, we consider versions of PHP which went EOL over six months ago to be good candidates for removal. Further to that, our usage statistics show that less than 5% of total sites and less than 0.5% of current Joomla version sites use them, therefore we decided to drop support. On a similar note, Joomla versions lower than or equal to 3.8 represent less than 2% of the Joomla sites of our users so we decided to drop support for them to make it possible to prepare our software for Joomla 4.
Improved Apache and IIS server signature removal. The server signature is now being removed more reliably in many more server setups.
Improved CORS handling. In previous versions you could only explicitly enable CORS from all sources. The other option was to let the implied browser and server default which typically means that only same-origin requests are allowed. The problem is that “typically“ doesn't mean “always“. If you wanted to explicitly disable cross-origin requests you had to create a manual rule in your server configuration. We now give you the option to explicitly enable all origins, explicitly disable cross-origin requests or let your server and browser decide.
Added support for Joomla 4 API application in the .htaccess Maker and Web.Config Maker. Joomla 4 comes with a JSON API application which supports its own SEF URLs. We were asked by the Joomla porject to improve their .htaccess file to make that possible. This change reflects the changes we contributed to Joomla itself.
Added support for automatically serving .css.gz/.js.gz files in the .htaccess Maker and Web.Config Maker. This is a new feature added in Joomla 4. Core CSS and JavaScript comes in three formats: as-is, minified and a GZipped version of the minified file. Using some Apache and IIS trickery it's possible to server the pre-compressed GZip file instead of the minified file without having Apache compress it on the fly. This provides a marginal performance benefit which is still welcome on very busy sites.
Removed Change Database Collation and Repair & Optimise Tables features under Joomla 4. Joomla 4 uses a new database driver which vets the SQL commands which are executed against the database. Unfortunately, it does not support the SQL commands required to repair and optimize tables. Besides, these operations are best performed through a dedicated database tool such as phpMyAdmin or Adminer, provided by your host. Therefore we decided to remove this feature from Joomla 4 and will completely eliminate it when we remove Joomla 3 support from our software around the end of 2022.
Removed the CSRFShield feature. This made sense back in 2010 and Joomla 1.5 when extensions didn't always use Joomla's anti-CSRF token. It's now 2020 and not using it is a security issue that lands you out of the Joomla Extensions Directory. Therefore this Admin Tools feature doesn't make sense. Moreover, unlike ten years ago, POST requests are now used for far more than just POSTing forms, a fact that made this feature useless – it ended up blocking way too many legitimate requests.
Use JAccess instead of DB queries. This addresses rare cases where Admin Tools would misidentify the Super User groups of your site and makes it possible for our software to work correctly on Joomla 4.
Improve the rendering of the System - Admin Tools plugin options. We are now using special CSS classes to render Yes / No options as easier to identify switches. Some aspects of these changes may not work in Joomla 4.0 Beta 1 just yet. There's a known bug in Joomla which is being resolved for 4.0 Beta 2.
Improve the rendering of the component options. Similar to the above but for the component's Options.
Changed the terms blacklist and whitelist to be more clear. The provenance of these terms actually originates in the Middle Ages where votes were cast by placing a white or black stone (colors commonly found in riverbanks) in a container, the black stone being a vote against and the white stone being a vote for. The terms reappeared in the early 20th century as military jargon during WWI and WWII. The point is, while widely used in IT circles – presumably owning to the military origins of computing in general and the Internet in particular – they don't make intuitive sense anymore. For these reasons we chose to use the more transparent and neutral terms IP Disallow List, WAF Deny List, Exclusive Allow IP List and Allowed Domains with related changes in our documentation.
Changed the term Security Exceptions to Blocked Requests for clarity. The term “exception“ has the bad habit of meaning two very different things in IT: something went wrong (and was caught) or something was allowed in contravention to another rule. When Admin Tools was first published in 2010 it was mostly expert users, familiar with this weird duality in meanings using it. In the meantime we succeeded in making security a mainstream good which means that more people, who don't intuitively understand this obscure terminology, are using the software. As a result, by using the inscrutable term “Security Exception“ we ended up misleading users into thinking that something went through instead of being blocked. This is a disservice to our users so we decided to change the terminology in our software and our documentation to provide more clarity and prevent further misunderstandings.
Joomla 4 related bug fixes. Some features of our software were broken under Joomla 4. We had held back on the fixes until the first beta was released to make sure that we don't change our code before Joomla's core API was stable enough to warrant such changes.
The "User groups to check for well-known passwords" feature could cause a PHP notice when modifying the component Options. The way this information was stored in Joomla's component options storage would confuse Joomla when rendering the component options page, causing information loss and a PHP Notice to be emitted.
Temporary Super Users feature does not work when Monitor Super Users or Disable Editing Backend Users features are enabled. There was a chicken and egg problem in the implementations of these three features which caused the Temporary Super Users to trigger the request blocking code in the other two features, essentially rendering the Temporary Super Users feature inactive.
Some help text blocks were using the wrong class, making them illegible in Dark Mode.. We went through the Dark Mode text again to make sure the colors used allow you to read the help blocks.
Email Templates help text referenced country and continent which were removed in version 5.5.0.. We removed this information from the default email text. This change CAN NOT be applied retroactively to existing installations. You will have to edit the email templates yourselves.
.htaccess/NginX Conf/web.config Maker: more options for the expiration time. In the past you could either turn this option off or use optimized expiration times (1 week or 1 month, depending on the media type). This version adds the option for a flat, 1 year expiration time as recommended by Google's PageSpeed Insights.
Bug fixes and minor improvements. Please take a look at the CHANGELOG below.
We only officially support using our software with the latest Joomla! release branch, 3.9. We strongly advise you to run the latest available version of Joomla! for security reasons. Older versions of Joomla! have known major security issues which are being actively exploited to hack sites.
Our software should run on Joomla 4.0 which is currently in Beta. Please note that Joomla 4 is not stable yet. It should not be used on production sites. Some breakage is expected; we are working on fixing issues on Joomla 4 but it may take a while since it's still changing, albeit not at the rate it was changing pre-Beta.
We only officially support using our software with PHP 7.1, 7.2, 7.3 or 7.4. We strongly advise you to run the latest available version of PHP on a branch currently maintained by the PHP project for security reasons. Older versions of PHP have known major security issues which are being actively exploited to hack sites and they have stopped receiving security updates, leaving you exposed to these issues.
Please note that earlier PHP versions including but not limited to PHP 5.3, 5.4, 5.5, 5.6 and 7.0 are no longer supported and our software no longer works on them.