Support

This is meant for new users who don't know how Admin Tools works and want to start pretty fast with Admin Tools. That's why it's called Quick Start.

It is not meant to be the One And Only configuration possible. If that was the case there would be no other configuration page in Admin Tools except that.

You have your personal preferences on how you want to set up your sites. Fair enough. Apply these preferences instead of using the Quick Start page. You can even export settings from one site and import them in another, meaning you only have to change the email addresses in Configure WAF and the domain names in the .htaccess Maker.

To address your specific points NOT ABOUT YOUR USE CASE but the mass distributed software, general use case.

> It automatically fills in the secret word for the admin URL, but I have been advised to stop using this feature by you guys.  I hardly get locked out since I have stopped using it.

This feature still makes sense. Not everyone's server supports .htaccess files in the administrator folder and even if they do they might be using an extension which requires special allowances in its configuration to let it work.

The secret URL parameter is a feature implemented purely in PHP. As for being locked out, since several months ago we have introduced a feature which "remembers" you if you are using the same browser and does not lock you out.

> It automatically fills in the blocked requests email

Because this is of paramount importance when developing a site. This is the primary use case of Quick Setup; someone installs Admin Tools on a site they are still developing. They can expect to be the only person accessing the site. When they get blocked they need to know why and have a quick way to unblock themselves (Rescue Mode). Hence enabling these emails and rescue mode in Quick Setup.

> but I get so many notifications it has become something I ignore

As documented, this is not a feature you should be using in production unless you are actually troubleshooting an issue. Even then you probably need to only to get an email for just specific block reasons which is already possible since September 2010.

> Perhaps there is a better way to solve this issue? Maybe a summary email. 

Nope. Read the documentation. You should NOT concern yourself with blocked requests on a production site unless you are troubleshooting something. Admin Tools is designed to handles these itself.

> It might be nice to have a deselect all from the logs part of WAF and then add in only the ones we need.

It makes far more sense to disable the ones you do NOT want to be notified about. People tend to see which emails they receive too many of and add that to the exclusion list. Having people imagine what they don't receive and select that in an inclusion list is more challenging for the user. People are good at reaction, they are not good at being proactive. It's human nature.

> It does not automatically fill in the PHP errors email address but I find this super useful.

See, it used to but most people are confused by it. They think it reports a problem in Admin Tools itself despite the email content and the documentation saying otherwise. So we no longer do that. This is a great troubleshooting tool if you are experienced enough to use it. You are and so are we. The average user? Not so much.

> It fills in the email address for logs of backend logins but that doesn't seem to be optional it fills it in either way.

These fields are optional. These are also low volume emails and very useful. We know of at least two sites just last year who detected an intrusion thanks to these emails according to their owners.

> Just some feedback, I don't know if you have reviewed that section in a while, but some of it now seems counterintuitive.

The code for Quick Setup was overhauled in 7.1.0 released in February 2022. I went through every single setting in WAF, .htaccess Maker, NginX Conf Maker and Web.Config Maker, re-evaluating what should be the default in the generic use case while keeping ini mind this is mass distributed software.

Every time we add a new feature we also consider what should be the default option for it in the mass distributed software generic use case and whether it makes sense to have a configuration option in the Quick Setup page.

We don't write software and "throw it over the wall". The reason we do support ourselves, the developers, instead of having separate development and support staff is that we need to be in touch with our users, their needs, and their challenges. The support requests inform us about the assumptions, mistakes, and logical leaps users tend to make. These are the input for our constant development effort in all of our software.

Always keep in mind that by nature of it being mass-distributed software it can never fit an individual use case with the default configuration or a quick setup. As a matter of fact, I have explicitly documented that the configuration options need to be tailored for each site individually. No two sites are alike, no two persons have the same workflow, or conventions. The configuration export and import feature is there to alleviate most of that pain.