Support

> I am blocked out of my administrator access and have to completely remove the entire site and database tables effectively by re-installing a recent Akeeba Backup

No, you absolutely don't. One of the suggestions in the email sent to you automatically when you apply the Setup Wizard will work.

The Setup Wizard will do AT MOST three things:

• Set up an administrator password protection. This is addressed by removing the .htaccess and .htpasswd files. See Administrator password protection issues
• Set up a .htaccess file. This can be addressed by deleting the .htaccess file and renaming the .htaccess.admintools file back to .htaccess. See Locked out of my site after applying a .htaccess using Admin Tools' .htaccess Maker.
• Set up the Web Application Firewall. The Rescue Mode does apply — but there's also the “traditional” method of disabling the plugin's files. See Admin Tools' Web Application Firewall (WAF) locked you out of your site.

I don't think there's any delay since you described getting locked out right away. If there was a delay it would apply to getting locked out, not just fixing your problem.

The most likely problem here is the default PHP version of your host is much older than 8.0, possibly even older than 7.2.5, the minimum PHP version supported by Joomla 4 itself. When you create a .htaccess file it replaces your existing one. The AddHandler / SetHandler lines in your .htaccess put there by your host to tell the web server to use PHP 8 are therefore removed.

In this case you need to go back to your hosting control panel and choose the correct PHP version for your site (8.0). Immediately afterwards, edit your .htaccess file and look towards the end of the file. There's a block with an AddHandler or SetHandler line which was not there before. Copy it, and paste it into the “Custom .htaccess rules at the bottom of the file” area of the .htaccess Maker configuration, see https://www.akeeba.com/documentation/admin-tools-joomla/custom-htaccess-rules.html This way, the next time you regenerate the .htaccess file with Admin Tools it will also output the special lines which your host is using to tell the web server to use the desired PHP version on your site.

To many redirects means that you have set up a $live_site in the configuration.php file (or in the Live Site box when restoring) which does not match the other settings you have set up in the .htaccess Maker. For example, if $live_site is set to http://www.example.com but you have set up a www to non-www redirection and HSTS the .htaccess is trying to redirect you to https://example.com instead. However, once you reach that URL then Joomla! is trying to redirect you back to http://www.example.com which causes the .htaccess to redirect you back to https://example.com… you get the idea.

To solve that, edit the configuration.php file and remove the $live_site contents, making the line look like this:

public $live_site = '';

> Also, it appears that the only .htaccess to contain an AddHandler or SetHandler statement is the one within the root directory the total content of which is as follows and appears to be correct?

Yep, that's correct, don't touch it! Your host is doing this right, by putting the .htaccess file with the AddHandler line one level above your site's root so it doesn't get overwritten when you modify your .htaccess file. As I said, this is good, don't touch it — and don't copy it into the .htaccess Maker settings, we don't need to do that in this particular use case.

>  does that make any sense to you?

Yes, and it does clear up a lot of the confusion in your past few support requests.

Your host is using its own caching / CDN in front of the site.

As a result, what you do is NOT immediately reflected on the site.

I would recommend reconsidering using a CDN, especially one which seems to be caching public pages with complete disregard to the HTTP headers Joomla sends asking proxies / CDN to NOT cache the generated pages.

I am also making a note that any further issues you report with this site are likely caused by the host's idiosyncratic implementation of a CDN rather than anything you do on the site itself.

It's the same thing in different words. Proof:

$ wget "https://bbs-joomla4.co.uk" -O /dev/null
--2023-01-24 20:07:17--  https://bbs-joomla4.co.uk/
Resolving bbs-joomla4.co.uk (bbs-joomla4.co.uk)... 185.151.30.176
Connecting to bbs-joomla4.co.uk (bbs-joomla4.co.uk)|185.151.30.176|:443... connected.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:18--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:18--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:18--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:18--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:18--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:18--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:18--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:18--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:18--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:18--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:18--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:18--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:18--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:19--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:19--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:19--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:19--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:19--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:19--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
--2023-01-24 20:07:19--  https://bbs-joomla4.co.uk/
Reusing existing connection to bbs-joomla4.co.uk:443.
HTTP request sent, awaiting response... 301 Moved Permanently
Location: https://bbs-joomla4.co.uk/ [following]
20 redirections exceeded.

Enabling the HSTS feature redirects from HTTP to HTTPS. This requires the server to correctly report when the site is being used under HTTPS. If this is not reported correctly, or at all, you will get a perpetual redirection. Exactly what we see above.

Why does the server NOT report correctly if it's being accessed over HTTPS? I will venture a guess. It appears to me that they have a setup of CDN --> SSL terminator --> web server. In this case the SSL terminator accesses the web server over plain old HTTP as it handles the "S" part of HTTPS itself. In this case the web server MUST be set up so that the HTTPS environment variable is always set to on, otherwise the software running on the web server does not (can not!!) know it's running under HTTPS.

By the way, I am not speaking out of my ass here. I have a private server running Expose and Matrix Synapse as their own, HTTP-only servers with NginX in front of them acting as the SSL terminator (and, yes, I know that NginX is a “poor man's” SSL terminator, but I had my reasons). If I put a CDN in front of it, e.g. CloudFlare (because I am a cheap bastard when it comes to an internal server), I'd basically have your setup. Key difference here? I make sure that NginX sets the HTTP header X-Forwarded-Proto https which is caught by a special plugin I've written for the sites served over Expose to let them know they are being accessed over HTTPS. That is to say, I am fully aware of the non-standard environment and have taken it into account in the way I deploy these sites. It's no longer a stock, off-the-shelf CMS, it's halfway into a bespoke application.

A general purpose host cannot reasonably assume that its clients will have this kind of deep understanding. They are going to be using stock, off-the-shelf, mass distributed application such as Joomla, WordPress, Drupal, PrestaShop, or Magento which have to run on a multitude of environments and cannot make assumptions about the environment — they have to get signals which tells them what the heck is going on. This host's setup assumes that whoever uses it will know how this kind of setup works (even if they have never explicitly said that they use this kind of non-standard setup!), how the off-the-shelf software works under the hood, and how to make these two work with each other using bespoke code OR they expect their clients to only use this hosting service to deploy bespoke Laravel- or Symfony-based applications where you can bake assumptions into the application's tailored code. The former is unrealistic. The latter only makes sense if you want to spend dozens of thousands of Pounds every year to host a bespoke application meant to serve hundreds of concurrent visitors.

Is it too late to switch hosts? It doesn't sound like the host you have matches your expectations or the reality of the site you are developing. 

I mean, if I get their setup right, it's a VERY good setup for large sites… just not the kind of setup you can work with an off-the-shelf CMS without a certain amount of knowledge and pain.

The last time I had seen a similar setup on a host it was optional and could be disabled. Maybe that's an option for your host, too.

Hello,

I'm taking this ticket since Nicholas is currently unavailable.

To fix your redirection loop, you have to disable HSTS inside the Htaccess Maker. Regenerate your .htaccess and try again, the issue should be gone.

You're welcome!