bsmither

After having experimented with the code edits, what is your opinion of the new functionality? Any thing else we can do? Otherwise, we can close out this conversation and make a suggestion to the programmers in the Github.

Certainly!

Probably. The seo 'path' that gets associated with product 22 shouldn't change at all, once created and databased. So, the query that uses this path to figure out the product ID value would naturally come from CubeCart's cache. However, I don't know what would have been cached that would have caused CubeCart to not find the proper product ID.

In /classes/cubecart.class.php, near line 2623 (CC652), begins a block of code that tests if the shipping method used has a shipping module. At lines 2636 and 2646, there is code that formats 'ship_date'. Additional statements can be added just above those two statements: Find in two locations: 'date' => (!empty($order['ship_date']) && $order['ship_date']!=='0000-00-00') ? formatDispatchDate($order['ship_date']) : '' Add above each location: 'alt_ship_date' => (!empty($order['alt_ship_date']) && $order['alt_ship_date']!=='0000-00-00') ? formatDispatchDate($order['alt_ship_date']) : '', 'venue_ship_product' => $order['venue_ship_product'], 'all_shipping_used' => $order['all_shipping_used'], Then, in the skin, add the necessary HTML to show these new elements of the $DELIVERY array.

So, there is 'all_ship_date', etc. as a columns in CubeCart_order_summary. Therefore, it should be real easy to incorporate those columns into the $DELIVERY array. I will look at the stock code to try to add new code to read those columns.

In the "Switching Power Supply" category, I found the 110V variant, but not the 220V variant, in the listing. On the 220V variant product's admin details, General tab, are you sure the product has its Status checkbox checked? Might there be something entered in the "List from" date entry field? Might it be out of stock and the store settings say to hide out of stock? Might it be assigned a primary category, other than Switching Power Supply", where that category is disabled? Well, scratch all that. I see the 220V variant just below the 110V variant in the listing - just with a wildly different Name. Please determine the product_ids (21 for the 110V variant) of these tow items. Then using an external database utility, look in the table CubeCart_seo_urls and find the rows for those item_id's of type prod. Compare the path with what you expect.

When the admin is updating an order, specifically when changing an order to Complete ('status' = 3), there is code in the admin /sources/ file orders.index.inc.php, near line 208, that tests for the presence of a manually entered 'ship_date'. If not present (or empty), then today's date will be used. I haven't checked if a query for an order's summary was fetched from the cache (I would assume so because, eventually, the order's details won't change over time) caused by the customer wanting to see their order history. Therefore, after Saving the order summary from admin, the admin would need to have CubeCart clear its internal cache, then the customer would need to refresh their view of the order's details. "I use a database called all_ship_date, venue_ship_product, and all_shipping_used." Where are these database tables located? In the same database as are all the other "CubeCart_abc" database tables? If so, then code could be added (likely through a code snippet) to JOIN that data into $Smarty's $DELIVERY array. If not, while not impossible, a much more complicated effort would be involved to fetch the relevant data.

In my opinion, those parenthesis should have caused a different problem, resulting in not showing that content at all. Very strange! Parentheses are used to force an "order-of-math-operations", or as a "container" of function arguments. But, since there was no function name preceding the function argument "container", PHP should have complained about something wrong with the statement syntax. However, this was inside braces - which are reserved for Smarty statements. Thus, Smarty will "parse" its statements, compiling them into real PHP statements. You can see the compiled result files in the /cache/skin/ folder. For myself, the process by which Smarty parses its statements, and how it deals with anomalies, is unknown. Therefore, why Smarty would use "stored/cached" contents of a variable, let alone where those contents could possibly be stored/cached -- I have no idea. I do plan to conduct my own experiments to try to replicate this situation.

The files that have been modified to show Best Products Sold in a given time frame, and Best Customers in a given time frame are ready for testing. I will try to attach the ZIP file to this post. But if the forum no longer allows it (I used to be able to do this), send me a PM with your email address and I will send them to you. Well, the message said the upload failed. So, if interested, ....

We know that editing the product's description (having put the code in Angel and Child) does show the changes on the storefront. Please show the custom template code (5 lines before and 5 lines after) where the Smarty variable $PRODUCT.related_used_with is located.

Please see if the order of the 'Use With' images for 'Tarantulas' changes on the storefront after you change the order in the editor. (And Clear Cache.)

Again, I assume you had CubeCart clear its internal cache after saving the edited data. That is necessary because the result from the query in the Catalogue class, function getProductData(), the database record will be pulled from CubeCart's internal cache - if it exists.

Other than a strange 'img' attribute on the third <img> tag, I do not see anything wrong. I will assume that the database record gets appropriately updated. You can find the respective database query in the list of Queries.

"Do I need to add the related_used_with and specs to the product description?" You shouldn't have to. The content of the 'related_used_with' editor, being databased in a new column of the CubeCart_inventory database table, then retrieved as an element of all data found in that record, should be part of Smarty's $PRODUCT array. (I assume you had CubeCart clear its internal cache after saving the edited data.)

I see that in admin, there is a dedicated editor for 'related_used_with' - and I assume there is a database column for it. Have CubeCart's debug mode enabled. Save the edit screen after making sure that the class="th" is part of the <img> tag as seen above. In the debug window, CubeCart will show what was received in the POST payload. Confirm the <img> tag has the class="th" attribute. If this attribute is not present, then we might think that the editor is stripping it away. Which is strange.