Support

 I had a discrepancy in my php settings, with the server set to php85 but the last stanza in my existing .htaccess set php to php83 and Joomla system information had the 8.3 version for php.  The .htaccess for AdminTools set the php to php85.

You should read the documentation: https://www.akeeba.com/documentation/admin-tools-joomla/custom-htaccess-rules.html You need to tell Admin Tools what is the custom code required by your server to have your server use a specific PHP version. This is very much server-specific.

Also note that if you change this code after creating a .htaccess with the .htaccess Maker, for example by choosing a different default PHP version in your hosting control panel, Admin Tools will discover it and ask you to automatically transcribe the corresponding AddHandler / SetHandler line from your current .htaccess file –as modified by your server– into the .htaccess Maker configuration.

In the installation I chose both a login code and an admin password. 

It is perfectly possible to use both at the same time. In fact, I recommend it when I am asked by people what to do, and do explain why (essentially, it helps deflect admin brute force attacks without using up too many server resources). The administrator password protection works by having the Apache or LightSpeed web server have your browser ask for a password; it is implemented at the web server level. The secret URL parameter is a check performed by the System - Admin Tools plugin and sets a Joomla session flag; it is implemented at the application level. One has nothing to do with the other, and both can be used concurrently.

Let's say that for administrator password protection you chose the username alice and password 1two#three, and let's say that for the secret URL parameter (which I presume is what you inaccurately refer to as a "login code", despite the fact no such label appears anywhere) you chose foobar. Let's also assume that your site is https://www.example.com.

What you would need to do is access your administrator login page as https://www.example.com/administrator/index.php?foobar. This is documented: https://www.akeeba.com/documentation/admin-tools-joomla/waf-configure.html#waf-configure-basic-protection  I would also ask you to carefully read this documentation in case you are using characters beyond ASCII lowercase and uppercase letters without accents (a-z, A-Z) and numbers 0-9. Other characters do work –therefore, we cannot block their use– but require you to URL-encode them. If it's still not obvious, this is also documented. You are also notified to only use a-z, A-Z, and 0-9.

Your server will then ask your browser to prompt you for a username a password. You will have to enter the username alice and password 1two#three you chose. This is documented in https://www.akeeba.com/documentation/admin-tools-joomla/admin-pw-protection.html 

 At the moment I have the provider-disable.php fix and I am able to log in to my website and do things, but if I click the link to change it back, I cannot access my website and get redirected to the home page, with a 404 error.

As per the documentation, you need to address the root cause of your issue. The last paragraph on that page tells you how to remove, or change, the Secret URL Parameter.

Should I redo the installation

Absolutely not. It's completely unnecessary. 

 If the login code and admin password are alternative choices, then the setup should be one or the other.

You are wrong in this assumption. They are NOT mutually exclusive.

When there are mutually exclusive options the user interface hides one option when the other is set to a value incompatible with it. Moreover, there are execution time interlocks so that mutually exclusive options do not take effect at the same time. You haven't noticed because it's done so well.

For example, URL rewrites are the "current site link" (not the "existing" link) and the link to be rewritten is the "old link." 

You are very wrong both in how these terms are perceived, and in the fact that not using those terms is not an accident. We know of the ambiguity, and explicitly chose not to use these ambiguous terms for the past 7 years or thereabouts.

Parsing the terms new / current link and old link depends on the way you frame URL redirection in your head.

One way to frame this is that I had an old site where the URL /foo.html was valid. In my new site this URL is no longer valid; the new URL for this is /bar.html. Therefore the old URL is /foo.html and the new URL is /bar.html.

Another way to frame it is that on my current site the URL /bar.html works. However, I see people trying to use /foo.html which does not work. Therefore, I need to create a new URL /foo.html which redirects to my old URL /bar.html. Ergo, the old URL is /bar.html and the new URL is /foo.html.

Neither way to frame this problem is wrong. They are simply two separate use cases using the same terminology, but semantically inverted. I was originally using these terms in 2010 within the context of the second way to frame the problem. Half of the users were confused and insisted that the terms are wrong. I then swapped the semantics of these terms in the UI. The other half of the users were confused and insisted that the terms are wrong.

At this point I realised that the problem is the terms, not the users or the way they frame these two use cases for URL redirection. That's why we are no using the terms "Visiting this" and "Takes you here". These terms are unambiguous. To make it even more clear that "visiting this" is a URL on your site, it is prefixed by your site's URL. In contrast, "takes you here" can be a URL on your or any other site which is why it is not prefixed with anything.

Going back to the ambiguous terms "current site link", "existing", or "old link" would be a regression. That kind of regression would be idiotic on my part. I am many things, good and bad, but an idiot I am not.

A friendly suggestion -- redo your installation instructions and field labels because they are confusing.  I was a math teacher and I learned that it is critical to have clear and consistent instructions, with no misuse of terms, no ambiguous references, no extraneous commentary, and be careful with assumptions that people know what you are talking about.  This can be as difficult as writing code.

My friendly suggestion is to heed the advice of ancient philosophers. Let me quote Socrates' Apology, as passed down to us by his student, and great philosopher on his own merit, Plato:

πρὸς ἐμαυτὸν δ᾽ οὖν ἀπιὼν ἐλογιζόμην ὅτι τούτου μὲν τοῦ ἀνθρώπου ἐγὼ σοφώτερός εἰμι· κινδυνεύει μὲν γὰρ ἡμῶν οὐδέτερος οὐδὲν καλὸν κἀγαθὸν εἰδέναι, ἀλλ᾽ οὗτος μὲν οἴεταί τι εἰδέναι οὐκ εἰδώς, ἐγὼ δέ, ὥσπερ οὖν οὐκ οἶδα, οὐδὲ οἴομαι· ἔοικα γοῦν τούτου γε σμικρῷ τινι αὐτῷ τούτῳ σοφώτερος εἶναι, ὅτι ἃ μὴ οἶδα οὐδὲ οἴομαι εἰδένα

Which translated to English reads:

So I, as I was leaving, I was telling myself that I am wiser from the man; for none of us knows nearly anything nice or kind; but he thought he knew something without knowing it, while I, since I do not know, I do not think I know either. Therefore, it seems to me that compared to him I am somewhat wiser, in that what I do not know I don't think I know it either.