bsmither

I have no idea what the actual cause is, but (even though you attempted to obscure the links above) when I visit your main site, I get a Kurouto skin, followed by a standard Authentication Required lockout. Visiting the /cube/ sub-folder, I get nothing but the lockout. It seems the Homepage document has two images that are forced to be loaded from the /cube/ subdirectory. As an experiment, temporarily remove the basic authorization needed to access the /cube/ sub-folder.

In this case, a cat_id is not necessary. A 500-ISE suggests that PHP is crashing. The Warning you posted would not cause a 500-ISE. Allow me to suggest a closer look at the error_log. Or, make sure that the error_log is in fact getting new entries appended onto it. There is a remote chance that the crash is happening before PHP gets involved. If so, see if there is a web server error log. See if there may be something unusual in the .htaccess file. It is strange that you say both are 'group=2'. One of them should be 'group=1'. Even so, this strangeness won't cause a 500-ISE.

Yeah, the "Please try..." ended up being nothing more than adding a bit of sanity to the code structure. It's the "But the real problem is..." that dismissed the validity of the "Please try...". Since you will be editing a template, be sure to have CubeCart clear its cache (admin, Maintenance, Rebuild tab, Clear Cache).

I am an SEO atheist, but I would think Google cares not for SSL badges showing more than once. It certainly depends on what the javascript does, but, yes, I would say, unless the javascript tries to detect if it is already loaded, then it will be executed twice. Of the two solutions, which did you choose, if either?

I am not liking how the <script> is inside the <span> that is supposed to contain the badge. Please try: <span id="siteseal"></span> <script async type="text/javascript" src="https://seal.godaddy.com/getSeal?sealID=0lwpmB7U1ELUSpdGka8lmjf9eCvphf9xt56esxBvE7YRhLdmA"></script> But the real problem is that the skin template has two <div> blocks where the Copyright content is placed: one 'show-for-small-only' and one for 'show-for-medium-up'. The situation is that both instances of the fetched javascript code is getting executed. Hence, two badges. One solution is to edit the actual template (main.php and main.checkout.php). Place the <script> part along with all the other <script> tags at the bottom. Leave the <span> block in the Copyright content. Another solution is to create a code snippet that will then have the script URL loaded into the template for any skin you may want to use.

It is data redundancy, true, but I think the 'cat_id' column is kept for legacy purposes. CubeCart does now use the CubeCart_category_index table as a many-to-many relationship: many products can be assigned to the same category, and many categories can be assigned to one product (where one of those categories is designated as the 'primary' category). This "glue" table (it 'glues' the inventory and category relationships) only needs the id numbers. With a minimally complicated SQL query, you can make it easy to identify the product and category you wish to affect.

Please verify that you are entering this code when the editor is in Source mode. Is the site publicly viewable? If so, may we have a web address?

There is an issue posted in the github about this. A change in the code in the next release should undo this scenario. Please view the code changes here: https://github.com/cubecart/v6/issues/1759

Most modern browsers have a Diagnostic Suite. In Firefox, it was Firebug and is now the built-in Web Developer's Tools. Chrome has one, and Internet Explorer has something called F12 (I think). Anyway, please use this tool to view the Network activity. This panel will show you what the browser sends out and shows what the server sent back. For Firebug, you will need to enable 'Persist'. After the admin Add/Edit Product page loads, CubeCart will make two AJAX requests: for a list of images and a list of files. Depending on the Network tool you use, the line may say XHR (you may be able to filter for those lines), or simply show the URL as something like: admin.php?_g=xml&type=files&q=list&dir=%2F&group=1&product_id=1&cat_id= Look for those requests and what gets sent back, if anything.

I've discovered that CubeCart's behavior (perhaps not changed over any particular later version) is that an order can be made where options can be ignored if that option is not required. However, at a later time, that option can be made required, and it will indicate as such in the admin Order Summary, Inventory tab screen, which will be confusing if the admin does not realize when this option was made required versus when the order was made. But that does not sound like your situation.

Are the two images referencing the same order and inventory? I see the first image referring to Birthday Bash something, and the second image referring to Invitations. I've compared the admin code between CC618 and CC6112 that deals with product options and find no differences that would explain missing option data. So, maybe the frontside code has the problem, or the skin (or plugin) may have a problem with CC6112. I will keep experimenting.

I think the latest couple of versions have attempted to split the session between front and admin. I understand this attempt has now caused the inability for the admin to log in as the customer (from the admin's Log In As Customer link). This may have also affected the admin's overruling of the offline state of the store. Try to use the admin link in the upper right corner of the admin's breadcrumb bar, where it says "Storefront - Closed". CC6110 behaves correctly. I haven't tried with CC6112 as yet.

Since you asked, you must have some concerns. Your hosting control panel may have a tool to block IP ranges. CubeCart has a Security Suite and it has a tool to allow only certain IP addresses to access the admin.

Just to make sure, we would ask that you create the error log. In the folder /images/source/ and all sub-folders, make sure there is nothing but image files.

It could be the case that the new version has a slightly modified version of the javascript file that powers the product's Image Picker box, but has the same filename. In these cases, your browser has no idea that the file has changed and is using its internally cached copy. So, try forcing your browser to reload all the page resources. This is usually done with CTRL-F5.

So, I suggested an edit to sort tax rules? This edit had some new code added to this file, and the code calls the function MultiSort(). Then, I must have also made mention of where to put this function. Maybe in /includes/functions.inc.php. Can you point me to the conversation where we discussed this? Found it. The function was added to the end of the file. Please verify the settings.tax.inc.php file has the function at the end of the file.

We would ask that you create the error log. Your SIG says you are running PHP 5.2. We hope this has been upgraded past PHP 5.4. Also, there are certain PHP extensions that need to be enabled on the server (ZIPArchive, MBString) to work with recent versions of CubeCart.

When logging out (typically), Session->destroy() is called. In this function, among other things, if CubeCart has determined it should manage the sessions, expired session files are deleted. This is outside of (or in addition to) any PHP garbage collection efforts. And CubeCart considers an expired session file as being older (filemtime) than the timeout. And that's the key: CubeCart must determine if it should manage the session files: Session->_manage_session_files. This is initially false. It then gets set to true in Session->_start() only if: CubeCart's configuration does not specify a path, or it doesn't exist, and The actual current PHP session save path is not writable, and CC_INCLUDES_DIR.'/extra' is writable. If all of that is true, CubeCart uses CC_INCLUDES_DIR.'/extra' as the argument to PHP's session_save_path() function.

Please let us know the setting of Store Settings, Features tab, "Order status for admin email notifications". CubeCart should send an email to the store's general email address (Store Settings, Advanced tab, Sender's Email Address -- aka, Store's General Email), as well as any Admin's enabled email address if different than the Store's General Email, but only according to this setting. Then, also check if your Administrator Profile has "Receive order notifications?" enabled.

Dirty Butter said this: "There is a place in Store Settings where you can set the time frame for automatically changing a Pending order to Cancelled. That might explain your change to cancelled." In admin, Store Settings, Features tab, "Time (in seconds) before expiring pending orders". By "expire", this is accomplished in a routine that is called frequently: Order->tidyOrders(), which resets the inventory stock levels affected by automatically cancelled orders, and sends a database query that directly sets the status of these orders to Cancelled. This function does not go through the typically used function Order_>status() -- which would send an email to the customer -- but modifies the database record directly and does not log any event of this action anywhere. (I will submit a feature request in the Github to have it do so.)

Aha!

What is shown on the History tab? If the History tab does not show when it was cancelled, I would want to look into the actual database record to verify - working on the premise that the order_status code (an integer) is somehow being misrepresented (integer index to language phrases). But you say that the Orders page did show the order was at Pending at one time?

I had noticed something in a recent version, but had not looked into it at the time. The file global.inc.php-dist suggests that the session file repository can be specified. If it is specified, it will be used. This implementation is not complete. But if you use (the equivalent of) CC_INCLUDES_DIR.'/extra, then CubeCart can manage its own session files.

An order goes to Processing when the gateway determines that payment has been successful. (Or the admin manually moves it to a particular status.) The customer does not get an email when the order goes to Pending (except the POF module), and neither will the admin if set to send an email at Processing. There is a conversation on the forums that discuss a code edit that will have a gateway module move an order to Processing regardless whether it has been paid for or not. You ask about "another place". What is it exactly that you feel would make whatever you are doing easier?

In admin, Orders, view the order that went to Cancelled. The Order History tab should show when the order moved through the various statuses. The Transaction Logs tab will show what the payment gateway did.