bsmither

What you re saying is that the Cart Order Number starts with 1603XX- ?

I also found that the file 'cubecart.green.css' was not getting found. CubeCart is setting the domain for the cookie as: domain=.66.147.244.143 This is not correct. Note the leading period. The browser will not send back this cookie because it does not match the domain (actually, an IP address). Adding the statements to the global.inc.php file will fix this.

For the moment, until your domain name points to this hosting account, make an edit to /includes/global.inc.php: Add these statements just above the very last line: $glob['storeURL'] = 'http://66.147.244.143/~lifegrai/cubecart'; $glob['standard_url'] = 'http://66.147.244.143/~lifegrai/cubecart'; $glob['ssl_url'] = 'https://66.147.244.143/~lifegrai/cubecart'; $glob['cookie_domain'] = '66.147.244.143'; $glob['rootRel'] = '/~lifegrai/cubecart/'; This will overrule what CubeCart thinks where it is at, which, with IP addresses, may not be accurate. Plus, edit the .htaccess file so that references to the site say the IP address, and RewriteBase is /~lifegrai/cubecart/.

If the file 'error_log' is not present, then that means the web server (this is what starts CubeCart running) has found a problem outside of what CubeCart could cause. You may need to get your hosting provider to assist.

Visit a page using a mobile device (or ask a friend). When you get the 500 error, download the file 'error_log' and examine its contents. Reply here with the error messages.

Some of what you describe could be caused by your browser not sending back the cookie. A related cause could be that PHP is not keeping a "session" alive for visitors. Some other cause may be related to your hosting provider having an overly aggressive server-level caching mechanism. May we have a web address to see this situation?

Please see this page: https://forums.cubecart.com/topic/51550-how-to-create-the-error-log/

We would ask that you create the error_log.

If the upgrade was from CC610 (or there-abouts), we ask that you force your browser to reload the page's resources (images, javascript and css files). This is sometimes done by the keyboard shortcut CTRL-F5. This effect is usually caused by the browser running an older, incompatible version of a javascript file from its internal cache.

The act=verb looks like a CC3/4 style request. It may be a link located on someone's very out-dated blog. You can scan the site's web access log for the same date/time and maybe discover the 'referrer' site.

The Catalogue Import function mostly loads up the CubeCart_inventory database table. The inventory can hold values for the Retail, Sales, and Cost prices. A wholesale price, or any other price structure, is held in a separate database table and is associated to a Customer Membership designation. Customers can also be assigned to a Membership designation. Thus, for a "Wholesale" designation, a wholesale customer will see wholesale prices. Again, all this happens in a separate database tables that the Catalogue Import feature does not disturb. Through the use of 'hooks' in CubeCart's code, one can possibly augment the Importer to deal with this. (I am unable to assist with this at the present time.)

The OP said this failed on a fresh domain. I have not known a browser to use cached files from a foreign domain.

I think the solution has been to make sure to use https if you have SSL switched on. The admin login page perhaps has a padlock icon - click on it to make it appear closed (locked).

If an image does not appear in the file picker, aside from something else going wrong, the main reason for this is that somehow the value for the 'path' column in the CubeCart_filemanager database table row for this image is a zero-length string. The value must be either null or the name of an existing subfolder in the /images/source/ folder.

Some things should not get logged. If the new logger logs everything, then the particular code that send the ajax request to the logger should prep the logger to ignore it. The ajax request is made when viewing the Product page. There is the initial request, then another request is made after each change in choosing options. The return is a properly formatted JSON string that contains the currency symbol (unicode value) and price of the product having those options.

That was the solution I was going to recommend. An admin not having permission to see stats would not see those parts on the dashboard, nor those pages that are devoted to showing stats. The next question is, how often do you need to see the stats? If not often, then you, yourself, should log in as an admin with no permission to see stats. Thus, nobody sees the stats. When you specifically do want to see them, open a new browser private window (Firefox can do this - do not know about other browsers) and log in as the super-user admin. The private window may have its own cookie repository that will not interfere with the login at the first window. View the stats, then log out.

I am convinced the problem is with the new code added to 3.cubecart.validate.js in the Foundation skin.

I can't tell when it was successful. I was trying to use Firebug's javascript debugger and couldn't understand how to work it. So, I gave up for the day. I won't be able to do much troubleshooting for a number of weeks.

You are not missing something. This issue has been identified before. I am trying to find what was done to fix it. This has been fixed in a later version. See: https://github.com/cubecart/v6/issues/1533

I cannot reproduce the backend behavior on CubeCart's "Demo" store.

I will add this to the issue in the Github.

So, if something is crashing, then we can create the error_log and maybe find out what.

There seems to be some new code regarding this "Mailing List" text field. Testing the demo store results in crashing the javascript when clicking the "Subscribe" button. I will submit an issue into the Github. Sorry, but I currently am unable to troubleshoot for the exact cause. Edit: after a second test, for which I forced my browser to reload all the page's resources (specifically, 3.cubecart.validate.js), this functionality is working correctly. If this is your own observation, then force your browser to reload page resources (usually by CTRL-F5), and try again. If you have visitors complaining, then we may need to make an edit to the template that will require the browser to load this file for each page request, thus ensuring the most recent version is always being used.

Is this the admin, Mailing List, Import Subscribers tab? If so, I see no difference in the code that would now stop CubeCart from adding comma-delimited emails to the database. (I am currently not able to trace out the code execution, so cannot determine what may be happening.)

How do we know that Smarty is the one complaining? If it is Smarty, Smarty should tell us explicitly what file or string is the trouble-maker.