Support

The only changes in 7.3.0 regarding the .htaccess Maker are the following:

1. # [HIGH] Empty “Force HTTPS for these URLs” will cause any HTTP access to redirect to the HTTPS site's root
2. # [HIGH] Quick Setup Wizard will apply the wrong site root path to the .htaccess Maker
3. # [LOW] .htaccess Maker accidentally prevented the use of Authorization HTTP headers with Joomla

Let's take them one at a time.

# [HIGH] Empty “Force HTTPS for these URLs” will cause any HTTP access to redirect to the HTTPS site's root

This doesn't really concern you. If you have an empty item in that list it would make all attempts to access the HTTP version of the site to redirect to the site's root instead of the corresponding HTTPS page. What I mean is that http://www.example.com/foobar would redirect to https://www.example.com (wrong) instead of https://www.example.com/foobar (correct).

# [HIGH] Quick Setup Wizard will apply the wrong site root path to the .htaccess Maker

If your site was installed in the root folder of the domain (e.g. https://www.example.com) the site root path was correctly detected as an empty string or a forward slash (both are functionally equivalent for the purpose of the .htaccess Maker). However, if your site was in a subdirectory, e.g. https://www.example.com/site then the site root path was detected as /administrator/site instead of /site.

Since you say that 7.2.3 worked for you it doesn't sound like this is the case for you. Your site is in the domain root. It would have helped knowing if this is the case and what the Quick Setup Wizard detected, though.

# [LOW] .htaccess Maker accidentally prevented the use of Authorization HTTP headers with Joomla

This was a simple transposition of a single line which should have preceded the redirection rules. It had been an error since Admin Tools 1.0.0 in 2010 but went undetected for so long because nobody had a use case for HTTP Basic Authentication being handled by PHP code on their site. Joomla 4 and its API application brought a use case which brought this mistake to light.

This is a transparent change. It does not change the way your server is handling requests. It simply passes along more information about the request to PHP by setting an environment variable.

Bottom line

The only change in the .htaccess Maker which could have an impact on how your server is handling requests is the second one, the detection of the site root.

If that happens to you again I need to know what are the HTTP domain, HTTPS domain, and site root path shown in the .htaccess Maker configuration page at the very bottom of the page. I have run this on several sites, live and local, without a problem. If there's something amiss I need to know, get access to the site in question, and see why it happens.

That said, the most likely cause of the symptoms you described is that your configuration.php has a non-empty $live_site. If that uses an http:// URL and you access your site from an https:// URL when running the Quick Setup Wizard you'll make it so that you get always redirected to the https:// version of your site's URLs but your site will be trying to load static resources from the insecure http:// URLs. This will prevent static files (like CSS and JavaScript) from loading hence "the backend displays as text". The same happens if your live_site has www in it and you enable the www to non-www redirection (or, conversely, if the live_site does not have www and you enable the non-www to www redirection). The browser will see that your site is trying to load static resource from a "different site" (as far as the browser is concerned, example.com and www.example.com are two different sites, one cannot trust the other).

Finally, if you are using Joomla's HTTP headers plugin it will add headers which can screw up loading of static resources.

That's off the top of my head. Without actually being able to access the affected site I can't tell you exactly what is going on, just that I cannot reproduce it on any of my development or live site (including the one we're having this discussion on). 

Last question -- since these happened with a new site and the Quick setup wizard, is it true that I shouldn't have problems updating to the new version of admin tools for sites it's currently installed on?

Absolutely correct.

This bug only affects the automatic detection of the Site Root when setting up Admin Tools for the first time using the Quick Setup wizard.

The good news is that after some tinkering I found a server under my control where I can reproduce the issue. I am going to fix that today and make a new release.