bsmither

Let's just make sure that 'date_added' is, in fact, a column in the CubeCart_inventory table for this store.

Using an external utility, view CubeCart_history table Note if any version has been skipped. The 'date_added' column is present in CC611 (which is as far back as my current situation allows to explore).

Unknown column 'date_added'. It seems the upgrade process failed to modify the CubeCart_inventory table when the step to have added the 'date_added' column would have happened. The 'date_added' column was added to make a distinction between when an item was added vs 'last_modified' (which, in previous versions of CubeCart, 'last_modified' put an item in Latest Products when it certainly wasn't a latest product).

In admin, Store Settings, Features tab, verify that for "Number of 'Latest Products' to display' there is a numeric value (using only digits) greater than zero. The error in the log suggests that the database query is returning something true-like, but it is not an array, and cannot be used as an argument for the foreach() statement. The first place to test is the number of records to return from config. You can also enable CubeCart's debug mode and provide your IP address in the adjacent field (www.whatismyip.com). Then, when viewing the Latest Products, the debug section will show any queries that the database engine had a problem with.

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.