bsmither

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.

Not to nitpick, but the {foreach} and the <div> tags are not nested properly.

Try this: In dashboard.index.inc.php, near line 263, find: $GLOBALS['smarty']->assign('ORDERS', $orders); ABOVE that, add: if(($inventories = $GLOBALS['db']->select('CubeCart_order_inventory', '`cart_order_id`,`product_code`', array('cart_order_id' => $cart_order_ids))) !== false){ foreach($inventories as $inventory){ $order_inventory[$inventory['cart_order_id']]['inventory'][] = $inventory; } $orders = merge_array($orders,$order_inventory); } In the template dashboard.index.php, find near line 160: <td>{$order.date}</td> AFTER that, add: <td>{foreach $order.inventory as $prod}{$prod.product_code}{/foreach}</td> Find near line 137: <td>{$LANG.common.date}</td> AFTER that, add: <td>Inventory</td> You now have a column holding product codes for each respective order. I will leave it up to you to style the list of product codes in the table cell. (I was thinking about a drop-down list if more than one item in the order.)

Unless something has changed in the Database class, creating a JOIN query gets sort of tricky. The alternative is to iterate through the $unsettled_orders array and query for the inventory based on cart_order_id.

In /classes/cubecart.class.php, there is private function _receipt(). This gets the order data and populates the receipt template. The first test is to make sure the cart_order_id is included in the URL, as well as either the customer being logged in OR the customer's email address is included in the URL. The link does not include the email address, so we must assume CubeCart considers the customer is actually logged in. Is this the case? (Or, there is a bug in that CubeCart should be adding the ghost customer's email address to this link.) Should this test fail, the next code to execute is to bounce the visitor to the login page.

The way I see this is that if the file $ship_class does not exist, then create $delivery with an admin-supplied 'url'. If $ship_class does exist, then only if a tracking() method exists in the shipping class, will $delivery get created. So, there is a path where $delivery may not get created - the $ship_class exists but does not have a tracking() method. However, earlier, your experiments showed that formatDispatchDate() was getting called. That only happens when $delivery is getting created - whether $ship_class exists or not. That is, unless your added code is where formatDispatchDate() was getting called.

Somehow, between when you click the link to visit the storefront as the targeted customer - and be logged in - and when you last pulled up the list of customers in admin, (CubeCart makes some security checks for every page request) the "User Agent" string of your browser changes - specifically the browser version number. From: Safari 603.2.5 To: Safari 603.1.30 I am at a loss to explain how that can happen. If this 'session data' changes when associated against the established cookie, CubeCart thinks some sort of shenanigans is going on and kills the logged in status.

An unintended consequence, I believe, of your wanting to remove any login to print a receipt is that anyone can make repeated attempts at guessing an order number and get a result. (It may take a while, but still possible.)

What if condition?

So, these latest experiments now have calls to formatDispatchDate() being made. The line after having the call to formatDispatchDate() is a closing parenthesis and a semi-colon. Put the debug statement after the semi-colon and have it print the variable $delivery. This is just after $delivery is supposedly created with it's various keys and values.

Keep adding that line at key points in the code. Find near line 2344: foreach ($GLOBALS['hooks']->load('class.cubecart.order_summary') as $hook) include $hook; Add the $GLOBALS['debug'] statement above and after that line. Add the debug statement just above each: $delivery = array( The output of the debug statement may be better viewed if you use this: $GLOBALS['debug']->debugMessage('<pre>The order data at line '.__LINE__.' is: '.print_r($order,true).'</pre>'); This adds <pre> and </pre> to the HTML which keeps line formatting.

What line is the [1] entry coming from?

Back in cubecart.class.php: Near line 2304, find: $template = 'templates/content.receipt.php'; $order = $orders[0]; On a new blank line after, add: $GLOBALS['debug']->debugMessage('The order data at line '.__LINE__.' is: '.print_r($order,true));

OK, line 2392 has a space after the line number, so we know that the value for $delivery['date'] is blank. That means either $order['ship_date'] is, in fact blank, or formatDispatchDate() is faulty. But there were no debug messages from formatDispatchDate() (unless edits to that file were not completed), so that means $order['ship_date'] is suspect.

We will assume that 'url' and 'tracking' are empty. (You didn't say.) So, make these edits in cubecart.class.php: Line numbers are for CC615 - should be nearby for you: Find near 2350: // Courier Tracking URLs if (!empty($order['ship_method'])) { // Load the module Change to: // Courier Tracking URLs if (!empty($order['ship_method'])) { $GLOBALS['debug']->debugMessage('The ship_method exists at line '.__LINE__); // Load the module Find near line 2379: 'date' => (!empty($order['ship_date']) && $order['ship_date']!=='0000-00-00') ? formatDispatchDate($order['ship_date']) : '' ); } if(empty($delivery['date']) && empty($delivery['url']) && empty($delivery['tracking'])) { $delivery = false; } } else { $delivery = false; Change to: 'date' => (!empty($order['ship_date']) && $order['ship_date']!=='0000-00-00') ? formatDispatchDate($order['ship_date']) : '' ); } $GLOBALS['debug']->debugMessage('The delivery date is at line '.__LINE__.' '.$delivery['date'].'.'); if(empty($delivery['date']) && empty($delivery['url']) && empty($delivery['tracking'])) { $delivery = false; } } else { $GLOBALS['debug']->debugMessage('The ship_method was not found at line '.__LINE__); $delivery = false; Then, in /includes/functions.inc.php; Find near line 409: function formatDispatchDate($date, $format = '%b %d %Y') { On the blank line after that, add: $GLOBALS['debug']->debugMessage('The date argument is at '.__LINE__.': '.$date); Then find: return strftime($format, $seconds); On the blank line ABOVE that, add: $GLOBALS['debug']->debugMessage('The format to use is at '.__LINE__.': '.$format); $GLOBALS['debug']->debugMessage('Returning from '.__FUNCTION__.' at '.__LINE__.' with: '.strftime($format, $seconds)); In admin, enable debugging and enter your IP address in the adjacent field (www.whatismyip.com). When you get the target order's details page (storefront, customer's orders list), at the bottom of the page will be a Debug Messages section.

You say there is a 'ship_method' for this order in the database. And that there is a 'ship_date' (probably looks like 2017-07-06). Even if there is no shipping class at /modules/shipping/UPS_Delivery/shipping.class.php, the code should fall to the } else { just after unset($ship_class). So, that leaves the first test that will result in a DELIVERY being false: the 'date' is empty AND the 'url' is empty AND the 'tracking' is empty. The 'url' and the 'tracking' could be empty, that just leaves the result of the formatDispatchDate() function as suspect.

Somewhere in admin, Store Settings, you are able to specify the format of your dispatch date. What is that format? We will need to add some diagnostic code to the file cubecart.class.php to find out why DELIVERY is being assigned false.

Please allow me to get something clear: is this data you are wanting to appear on the customer's Receipt screen, or the admin's Order Overview, General tab? If for the customer, remind us what skin you are using. At the bottom of the content.receipt.php template, add {debug} and save the change. (You may need to switch off CubeCart's caching for this test.) Ask for a receipt page. CubeCart will return a page with some popup javascript attached. Let the popup happen. You can remove the {debug} now. In the popup, scroll to the $DELIVERY variable and examine the value. I would ask that you use an external database utility, such as phpMyAdmin, to examine the table CubeCart_order_summary. Find the target order number and look in the 'ship_method' column. Is there anything strange here? I am asking to eliminate any possibility that a plugin is managing this data, and has not been coded to show the dispatch date on the customer's Receipt page.

In the file /classes/cubecart.class.php, in the private function _orders(), near line 2325 (CC618), there is a test to determine if the order has a 'ship_method'. If so, the "ship_date" is made available to the template via the DELIVERY array. If not, then DELIVERY is set to false (line 2360). There is no code that benefits a 'ghost' (unregistered) customer. So, please determine if this order has a shipping 'method' (the name of a shipping module), regardless of there being a shipping 'product' (First Class, Ground, etc).

CubeCart allows for a 'ghost' customer to check out. A ghost customer can add items to a shopping basket and checkout without creating a store account. At checkout, however, CubeCart will still require the customer provide an email address and physical address. (There are those attempting to circumvent the required physical address because the store has 100% digital inventory.) For this situation, a ghost customer has no account that CubeCart can validate against when making a query from the database based solely on the order number. But you are saying that you are logged in as a customer with a customer account (email/password). I think we are still at the place wanting to solve the disparity between what is seen on the page and the HTML source of that page. I understand that Chrome has a diagnostic feature, but alas, I do not use Chrome.

"How do I bypass the Login/Register page that the print invoice button launches?" That's not how CubeCart works. We need to suss out why CubeCart is behaving this way. "and yet it opens a login/register page!" CubeCart will always verify that there is a valid user that is represented by the cookie. If no cookie, no user, no user-based page, but will try to get the 'unknown visitor' to log in. You say cookies are enabled in Safari, but does Safari have a diagnostic panel where one can view the actual traffic in and out of the browser? I would ask that you observe the actual cookie that the browser is (or is not) sending to your store when the link to print the invoice is clicked on.

The first problem seems to be indicative of having lost the cookie that CubeCart uses to keep track of who you are. When you hover the mouse over the link to print that order's invoice, what does the browser say the URL is? If the URL is different than the domain of the cookie, then the browser will not send the appropriate cookie, if any cookie at all. Interesting about the second problem. I hear you say that, having asked the browser to show the source HTML of the page being displayed, the source seems to not be what is actually being displayed. In my experience with Firefox, certain browser settings will show the source from the page as it sits in the cache, and other settings will actually fetch a fresh page from the server and show the source HTML of what was returned. This result will be different if that request did not send the cookie. So, please verify that your browser is sending an appropriate cookie with all page requests, and that the URLs are all to the target store (as opposed to a test store).

When adding a product to a CubeCart shopping basket, the javascript sends an AJAX notice to the store, and the store code is suppose to return ONLY the HTML necessary to show an updated shopping basket. For whatever reason, your store is returning an entire frontpage. If you have made any edits to the core code, or have any plugins that may affect the shopping basket or storefront display, please let us know.

We are not aware of CubeCart being the entity of locking any part of the database. That being said, maybe the PHP 5.6.28 is configured (via the mysqli extension settings in the php.ini file) that performs table/row locking as a default action. We would ask that you consult with your hosting provider to determine if this is the case.

Please send me a PM with your email address. I will send you a PHP script used to make changes to the store's settings when one cannot get logged in to admin. Use this to switch off the SSL.