Support

I cannot reproduce this using your issue description. On a new Joomla 4.0.3 site with Admin Tools 7.0.5 installed I set up a secret word (foobar). When I try to access the backend as /administrator/index.php?invalid, just  /administrator/index.php or /administrator I get redirected to the front-page and I get a blocked request logged as expected. When I access the backend as /administrator/index.php?foobar I see the login page, again as expected.

Please go to Global Configuration on your site and set Error Reporting to Maximum and Debug Site to Yes. Save & Close. Then open a new Private Mode instance of your browser (this ensures a clean session in Joomla) and try to access your backend with the wrong or none at all secret URL parameter. It will give you much more detailed information. Please copy it here. It tells me the chain of events that led to the error and exactly where it comes from. Afterwards remember to set Error Reporting back to None and Debug Site to No.

PHP Error: I believe you have left “Do not send email notifications for these reasons” completely empty. This will indeed trigger this error. It will be addressed in the next version of Admin Tools.

Temporary Super User: I cannot reproduce this issue on the same Joomla and PHP version. There is no field called automation on that form or the database table; there never was, in fact. My only guess is that there must be a third party extension doing pre-processing of forms without checking the form context correctly. Since we are using Joomla core MVC all our forms go through the standard Joomla pre–processing events which means that third party plugins can modify them.

The email notification code is common, it does not make sense to have different email code for each type of blocked request. The list was empty. Because of the quirky way Joomla works, an empty list causes Joomla to populate it with the default value. The default value is indeed just the “Site IP Disallow List”. If you had just saved that page the problem would have gone away.

The problem is now moot as I added some code to expect an empty list in a way that does not throw an error in PHP 8. For what it's worth, the code was written in a way that PHP 5 and PHP 7 only threw a Notice (which was absorbed) without causing a problem. With PHP 8 the PHP internal functions are now type–safe meaning that we can no longer use that shortcut. We did try to catch as much as we could but the reality is that this kind of fundamental changes are nearly impossible to be addressed in automated tests and code review; they are something the developer needs to have in mind when writing the code in the first place. We expect a couple of these edge cases we didn't think about to crop up.

Yes, I understand that the way the Configure WAF, .htaccess Maker etc forms behave now is frustrating by not letting you have an empty list without falling back to the default value. That's how Joomla decided to implement forms back in Joomla 1.5. Not much we can do about it. I am currently experimenting with adding “fake” items, i.e. items which don't actually do anything except satisfy the non–empty list requirement to prevent the default value kicking in. While that works, it's confusing to the end user. If, for example, I name it “None” what does including “None” and ”Admin Query String” in the same list is supposed to do? Trying to understand what is less confusing for the user is a complicated matter...