bsmither

Links to all page resources are not hard-coded. That is to say, CubeCart figures out the address used to get to it, and uses that to construct a full URL for the page's resources. However, unless changed in CC618 (I have not yet checked), CubeCart creates a complete menu navigation in HTML and caches it. Thus, when accessing Site-A using a different URL, the menu still has the prior links. But, CubeCart's templates have relative image links - requiring the browser to re-use the domain address of the page that is requesting those images.

Unless you have given a utility permission and credentials to scan the file system of your hosted site, there is no way for anyone to know of the existence of those files. And, as you say, those files are for CC3, not CC6. CC6 would not be executing those files. There may be yet something unusual happening with that site.

Download CC618. Unzip the file on your local workstation to some folder. Using an FTP program, simply upload the contents of that folder having the FTP program to overwrite everything. The database will not be molested. Then, make sure the name of the admin folder and admin.php file are the same as the values in the file /includes/global.inc.php (which should not have been overwritten as this file is only created on installation and is not included in the distribution package).

If your copy of maintenance.index.inc.php, starting near line 933, does not have a $compress statement, then you are not at CC618. I have a suspicion that the file /includes/functions.inc.php is also not at CC618. It may be the case that your installation of CubeCart may be a mix of two or more versions.

When you say "control panel", are you referring to your hosting account's control panel (cPanel or Plesk), or are you referring to CubeCart's admin?

During an upgrade or re-install, the setup process will (should) ask if you want to keep your database or if you want to start a new database. Keeping the database will retain all the products, documents, categories, options, settings, etc. During an upgrade or re-install, all the code gets over-written, including the Foundation skin folder. So, rename that folder to something else, so that afterward, you can rename it back. You can have your hosting account make a backup of everything. A tool in the control panel - phpMyAdmin - can back up the database. CubeCart can also do this, but because it is a PHP script, there may be limits on the amount of memory and time the PHP script gets to run.

The commas at the end of the lines are there to separate the elements of an array, so they are necessary. Your edit looks good.

If no one uses Safari, then the next question is - is that your IP address in the messages? (www.whatismyip.com)

I think not this exactly. In the code above, I think simply: Find everything that looks like this: .$filename.'#backup' Change to: .$filename Leaving everything before and after on the statement line exactly the same. Four locations. Once CubeCart is finished with the job, the bounce will be to #backup - which means having it in the URL at these locations is superfluous and may be causing the problem.

Ok: nginx as a 'buffer', Apache as the real worker. As a test, have your hosting account not use nginx. Also, you are using the acronym SSI (Server-Side Includes) which is not SSL (Secure Sockets Layer - security certificate). I am wondering if your hosting provider has enabled something other than SSL.

The %23 is the bad part. That is the code for the hash mark. Continuing to look at the code. Thank you for this info.

A 'fix' regarding the User Agent string changing in mid-session? Is there anything weird about your Safari? Any strange add-ons? If this "loss of session" happens on a regular basis and it is because CubeCart detected a change in the browser's User Agent string between a visit to the admin side followed by a visit to the storefront side, then I think the problem may lie outside of CubeCart.

If 'they' updated the .htaccess, then they must be using nginx in some other manner, and actually using Apache as the true web server. Otherwise, making changes to the .htaccess file makes no sense. Please consult with your hosting provider and ask how they are using nginx, and what is actually using the .htaccess file.

I have been tracing the code for CC618 and have not found a specific cause. I have found where a problem might occur but only if the URL is bad. CubeCart sends a message to the browser to make a page request (a 302 redirect) after deleting the file. Are you able to discern what that URL is? It should be visible in the browser's address bar. It should be something like: admin_xXxYyY.php?_g=maintenance&node=index#backup

Just to clarify - these two screen grabs are what pages, specifically?

Having upgraded to CC618 from a prior version several versions back, you may be experiencing a disconnect involving a new approach to obfuscating the admin directory. Please confirm that your installation has only one folder named /admin_aBcXyZ/ and that there is no folder present that is simply /admin/ (where aBcXyZ is a sequence of random letters). Also, examine the contents of /includes/global.inc.php to discern that the value for the ['adminFolder'] variable matches the name of the admin folder. However, if this proves to be the cause, then probably much more about CubeCart would fail to operate.

The construction of that file path is bad. We will look into why that is. I am confident that no damage is being done to your store.

Your Users Online tab may show times set to your store's timezone. The error log shows UTC. You may need to add or subtract a number of hours (minutes will be equal) to match up the two lists.

CubeCart does throw a 302 for several reasons. I agree that this could be streamlined quite a bit.

I would like to have you log what CubeCart gets with respect to the URL. But before we get to the point where we need to do that... What I see is that your web server is "nginx". I researched whether or not nginx can or will use the .htaccess file (for Apache 2). Initial research results suggest that nginx does not support the use of .htaccess files. (https://stackoverflow.com/questions/35766676/how-can-i-use-htaccess-file-in-nginx) Which then begs the question - how is CubeCart functioning at all on your hosting account? Has the hosting manager already created the appropriate directives in whatever file nginx actually uses?

I am visiting your site now, and am looking at the traffic in and out of my browser. I recommend not re-installing just yet.

Other than the ErrorDocument directive - which sends a document from /storetest/ in the case of a 404 situation - all else looks fine.

These "look" like the parts of info passed via cookie. The question is, what outside entity is sending these corrupted cookies. You may be able to determine that by looking at CubeCart's admin, Statistics, Users Online tab. If not, then examining the web site's access logs in your hosting control panel should reveal the IP address. Then find out who owns that IP address. We would need to add some diagnostic code to show what exactly the cookie contains.

Please let us know if there are any redirect/rewrite directives in the .htaccess file that the web server may be executing - other than those specific to CubeCart. Also, likewise, see if your hosting control panel has a tool to create/manage redirects/rewrites such that a directive may be interfering with the URL that is the AJAX request.

Your conclusion is most likely correct: fetching a page that offers real or estimated shipping charges requires that CubeCart contact the respective courier website calculators. To verify - if this is an option for you - disable all shipping modules that use an external calculator (UPS, USPS, Canada Post, etc). Compare page response times.