I wrote:
I think you would agree that it would be better to have that message NOT appear UNLESS there IS a problem with the secret url parameter and that it should clearly indicate what is wrong with the secret url param if there is something wrong with it - too short, too long, beings with dash or underline, contains invalid chars, etc.
And you wrote in reply:
No, this is an important piece of information and we need to grab your attention to it. The message reads "The Administrator Secret URL Parameter can only consist of lowercase and uppercase latin letters without accents or diacritics (a-z and A-Z), numbers 0-9, dashes, and underscores. The first character cannot be a dash or underscore. It must be 4 to 64 characters long". Giving the password requirements to a user entering a password is a courtesy.
Which made me think that there was a failure of communication. I was referring to that yellow box with the very helpful information about the requirements for "The Administrator Secret URL Parameter" (" TASUP", in brief) appearing in the Admin Tools backend. It doesn't (at least on my sites) appear when a user is entering a password (which your last sentence seems to at least imply).
It ALWAYS appears in the WAF configuration Basic Settings tab directly beneath the TASUP field regardless of whether or not the current TASUP meets the requirements. The fact that it does ALWAYS appear makes it more likely to not be noticed when it should be noticed. I can understand that adding a bit of code to explicitly describe why an entered TASUP fails to meet the requirements may not be the sexiest piece of code to write, but I am willing to predict that you will have more inquiries and complaints about this over the next year or so if you do not add code to do that than if you do add code that informs the administrator that their TASUP is shorter than the required 4 characters, longer than the allowed 64 chars, contains chars "other than A-Z, a-z, 0-9, or _ or -" - or even better which disallowed characters it contains.
It would also have been very helpful to know that the reason the parameters "could not be saved" (even though the parameter I was modifying ("Suspicious Core Parameter") and upon which I was focused was just fine (I'd changed it from "disabled" to "enabled") and was apparently saved as I'd set it because it showed up as enabled when I re-opened the Basic Settings tab later - that there was a problem specifically with the TASUP parameter due to the change in the requirements of the length and content of the TASUP. The yellow box would then have appeared more relevant to me - even though it didn't clearly specify exactly what was "wrong" with the TASUP value that the site has used for almost five years. Interestingly, the code's failure to clarify the issue of the 'bad' TASUP left the old (bad) TASUP in place in the database. Miraculaously, the three character TASUP we'd been using continued to work despite it not meeting the changed requirements for at least four characters.
I know this is a small issue - and other than my wasting some of my time, that could have been spent much more productively, no serious harm was done by this suboptimal bit of user interface. I hesitate to suggest that you add my suggestions above to your wish list for future versions of Admin Tools as your depth and breadth of knowledge about Joomla and its in and outs is remarkable and probably matched by very very few if any other developers of either the Joomla core or other extensions - and my expertise (such as it is) can probably best be described as 'hanging on as well as I can as the environment in which I do my work keeps changing somewhat - to me - mysteriously". I'm not afraid to dive into some PHP code or on occasion JavaScript (we don't have to call it ECMA anymore do we?) but as things become more 'object oriented' it becomes more and more difficult to follow the flow of any Joomla request - at least without a much more in-depth understanding of what does what, when in the core vs. in an extension and what does what in the helper code (of which their seems to have been an explosion since Joomla 4).
I'm not a Joomla developer nor a Joomla extension developer, but after almost 15 years of working on a few Joomla sites, it seems to me that as the flexibility and reliability of the CMS has increased dramatically, the promise that Joomla (and the extensions) "take care of everything" and a site administrator " doesn't need coding skills") has become somewhat less true. The learning curve for an administrator to create a 'useful' site seems to me to have become considerably steeper - maybe "flexibility" just requires that to be the case.
The point is that somebody who is focused primarily upon the content and to some extent, upon the esthetics (usually a 'mamager" but sometimes a "manager" also working with or even as an "administrator" , has their hands full with such things, leaving very little if any energy left to carefully read every word of every extension's documentation, some of which is often not up to date (not yours), but changes in the documentation and operation of the extension (and the core) are not highlighted to attract the attention of those who need that information.
Admin Tools and Akeeba Backup are both outstanding in terms of their capabilities and - I cannot imagine how any Joomla site would dare to go live without using both of them. Howver, as their functions increase, without clear descriptions of user (admin) errors committed during the configuration process, it will become more and more difficult for people to configure them properly to use the features that they want to use
Sorry for the tirade. Please keep doing the right things.
Dave Ascher
PS - I have heard from my son in Chicago and my daughter about 10 miles from my home that the problem that they had previously encountered (the useless alert and the failure of the form to continue processing) has been fixed - at least for now.
I don't suppose you and Tuan of Event Management could discuss the root issue that might have caused this problem originally? I mean that whole business of it working just fine for me when I was at home, using either WiFi or Cellular, and that it failed for me only if I used the Opera VPN OR if I used WiFi or Cellular from the coffeeshop - and for anybody who'd used it outside my home. Very weird. I will ask him about whether Event Booking uses location services - but I'd be very surprised if it did.
