Problem Updating Store In Subdirectory

I'm trying to update my store from v4.3.6 to 4.7.2.
My 436 store is at the root of a shared FastComet domain public_html.
I copied the site and database locally, added a subdirectory and used Store Import to upgrade to 472. It works fine locally. Using wamp64 on a Windows machine.
After copying the subdirectory to the live site, the front end works fine but the admin page won't load. It seems to try to load but the progress circle thingy next to the url in chrome seem to go into an erratic infinite loop until it times out. By that, I mean it doesn't just go round and round a a normal page that take a long time to load does. It starts to do that but then starts over and over again.
I changed the storefront and secure_storefront urls in the cscart_companies table to ''
I've deleted the /var/cache directory,
The php log file is empty.
When I cancel reloading and view source, this all that appear:
In config.local.php, I changed the settings at the bottom of the file to:
//if (PRODUCT_STATUS != '' && !defined('DEVELOPMENT')) {
ini_set('display_errors', 'on');
ini_set('display_startup_errors', true);
define('DEVELOPMENT', true);
And the endless loop stops and this is the page source:
Continuehttp-equiv="Refresh" content="10;URL=" />
I added to .htaccess:
RewriteBase /cscart472
No change.
I disabled the seo addon by setting seo status = 'D'
No change.
I tried php versions 70 and 56
php memory_limit is set to 512m
I'm stumped. Got any ideas what else I could try?

Never mind. I'm back in business!

The problem was that,

  1. .htaccess instructed apache to rewrite all HTTP requests as HTTPS and csc sees the HTTPS request.
  2. But csc was not configured to use HTTPS in the settings_objects table.
  3. Around line 359 in app/functions/fn_control in the fn_dispatch() function is code that was redirecting admin.php back to admin.php, resulting in an endless loop.
  4. It was working fine locally because .htaccess wasn't rewriting the url to use HTTPS.

So, the fix was to simply set secure_admin to 'Y' in the settings_objects table.

I suppose this endless loop situation might be avoided if fn_dispatch() raises an exception when it's about to redirect to the request uri.