KirkM

Don't think so. All other logins work on all browsers. WordPress, Webassist, my own authentication system, everything on my server except CubeCart works fine on all browsers and all platforms. Plus, this issue is only on IE, Safari and Opera - win & mac and only on CubeCart. Even if it were a server setting, wouldn't it affect all browsers and not just these three?

Just FYI - This was happening in 5.2.7 this morning BEFORE I upgraded to 5.2.9 to see if that would help. 5.2.7 was working fine in all browsers until I patched OpenSSL late yesterday and updated php to the latest Atomic version. Don't know if it could be the OpenSSL fix or a problem with the new php version. CC doesn't like something that changed between the two.

There is no activity. But, as I said, this is the case with IE, Safari and Opera (win & mac). No problems with Firefox and Chrome on both win & mac. This is the case on ALL systems from various ISP's in different locations. All of my CC store clients report this in different parts of the country. Something isn't playing nice with these browser engines in the CC login.

After updating my server to the latest OpenSSL to patch the Heartbleed vulnerability (and yum update everything else), all works fine EXCEPT the CC admin login doesn't work on IE, Opera (win and mac) and Safari. Works fine in Chrome and Firefox. I updated to 5.2.9 and that didn't help. (php 5.4.27) The affected browsers don't throw any error, they just clear the input text fields when the login button is pushed and nothing happens. This just started today and I did the server updates yesterday so I am wondering what correlation there may be here. No other login interfaces that I have for clients have been affected, only CubeCart's admin login and only in IE, Opera and Safari. My own admin program logins work and so does WordPress. Any ideas about what this may be or if it is related to the OpenSSL patch? I do have the site secured with a valid certificate. Thanks

That did the trick. Thanks very much for the quick confirmation. Don't forget to add it to 5.2.5!

One of my clients on CC5 (upgraded from CC4) is getting AUTH_CAPTURE's on all transactions even though the store is set for AUTH_ONLY. It is using SIM method. I base64 decoded the setting in the database table and the setting is saving correctly. I then contacted Authorize.net to verify that SIM supported AUTH_ONLY, which it does. I then went and looked at the code in the gateway module class for Authorize.net and don't see the x_type being set in the SIM block. It IS assigned in the AIM code block. Is this an accidental omission or am I missing where it is assigned? I am wondering if I can just add the assignment to the $hidden array there and have it work. Anybody else have this issue? Thanks

I had a pretty good understanding of the files in CC4, but I am really not very familiar with CC5 since it is a total rewrite. You might want to re-upload the smarty folder at /includes/lib/smarty and then check the permissions of the files. Also do the /classes/cubecart.class.php. I am just guessing on these since I haven't had time or opportunity to learn the new CC5 code structure. On Linux, folders for these should be 755 and files should be 644. Don't know if this will help. You can also just re-upload all the files in small batches so there are no timeout errors and see if that helps. I am assuming this is a fresh install and not an upgrade from an earlier version of CC. Upgrades do work (I have done 2 from CC4), but the chances of something getting broken are certainly there, depending upon your mods and configuration in the CC4 version. Hope you get this sorted. Kirk

@salvador21 - I believe the native coupon system in CC5 does work, aside from the lack of certain features. You may want to check your installation, it sounds like you might have a corrupt file or some file permission / other issue that is preventing the coupon system from working correctly. Many times stalls in the long ftp upload can mess up a file or two. I have had it happen over the years a few times. Most of the time, re-uploading in small batches works to clear it up. I have also had mysterious permissions errors on files that were ftp'd to my server. I have had permissions incorrectly set at 0, which doesn't allow the file to be accessed at all and will cause problems with the functionality that particular file provides. Just some suggestions, FWIW.

I have had a few communications with Daren at Semper Fi Web Services about adding this feature to his existing CC5 coupon enhancements plugin. He seems very interested in doing it and I am hoping he will want to follow through and produce this upgrade. I think the more demand he feels there is, the more motivated he will be to do it, so if you or your clients would buy it, let him know.

@SimChris - I have multiple clients in exactly that position. All are waiting to upgrade to V5 but this coupon deficiency is the only hangup left now that Devellion bought Estelle's shipping plugin. The lack of adequate shipping functionality on CC5 was a deal breaker until that happened - I lost two clients to Shopify because of it and failed to land two other potential clients because of the lack of some really basic functionality in CC5, ESPECIALLY the shipping and coupons. Now that we have the shipping issue resolved, the only real stumbling block is the coupons. CC5 is definitely a great improvement, but some basics are still missing. I'm surprised no dev has stepped into this void. The coupon system in CC5 is just plain awful, as it was in CC4, only now we don't have Estelle to fill the void. Devellion may not understand that a robust coupon feature deserves serious attention since it is a major and common way to drive sales. Therefore, it is an extremely important component for the end user to have in their store. I have a query in to SemperFi about modifying his coupon enhancements plugin to add this feature. I figure if he already has a plugin for coupons written, it may be less of a task and shorter time frame for him to add a feature than for someone to create a plugin from scratch. I think he will sell quite a few more licenses if he has this feature. It might not hurt if anyone who needs this feature shot him an email and let him know there is a market out there for it. I'm keeping my fingers crossed...

And I fixed it. I just changed skins to one of the included ones and then back again to my custom skin and it all came back. Not sure what the hangup is, but it has to do with the skin. If you have this problem, just try changing the skin to a different one and see if it works. If so, change it back to the one you use and it should work also.

I always use the manual update and went from 5.1.5 to 5.2.2 and have this exact issue. The update seems to have gone fine and the store says it is 5.2.2 but nothing shows up on the category pages. The products are all there and assigned to the proper categories but they don't show up when you click the category menu links. I have cleared the caches, repaired the tables and even tried to do the upgrade again with no luck. I cross-checked the database tables and the categories, category index and inventory tables all are intact and tracking correctly. And this is reflected in the store admin in the category and product sections. This appears to be some sort of issue with the current version upgrade scripts. Is there a bad file that carries a critical function for this? Any info on where to go to check this? This is kind of urgent since the store is a client's production store.

Solved by CC support. It was on my end. With all versions through CC4, I had the orders.class.php script put a prefix in front of the order number for some clients who had multiple stores but used the same Authorize.net account. This enabled them to differentiate between the stores when pulling and auditing accounting information from Authorize.net. This always worked just fine. That was the only tweak I made on this store. It turns out that in CC5, the security is much tighter and the order number has to strictly conform to the native formatting. Adding the prefix broke all kinds of things, including the admin and customer emails, plus the print order form gateway. My bad. Al Brookbanks was very quick to spot it and educate me on this requirement. He was also very helpful in offering a modification suggestion to achieve what I need without breaking the store. Very impressive customer service, I must say. So far, the CC5 store is tesing out perfectly now. If I could just get Estelle to push out her shipping mod for CC5, I would be very, very happy. Thanks again for the help here on the forum. Sorry for the runaround!

That issue appears to be about printing order details by the customer and was resolved in 5.1.0, which is the version I have clean-installed. My problem is with the Print_Order_Form gateway fatally erroring. Thanks for that very through answer. It is a very interesting and insightful hypothesis. If true, that would appear to be a bug in 5.1.0. I am wondering i anyone else is experiencing this or not. If a bug, there should be many, if not everyone. If not, it must be something wrong with my settings or installation. I think I will use some support credits to get CC devs to see for themselves and fix the issue. This way, they will see first hand if it is a bug to fix or just some error on my end. Thanks for the replies!

I have a fresh install of CC 5.1.0. No modifications except to the skin css. The print order gateway in Firefox Mac shows a blank page (indicating a fatal php script error). Chrome on Mac shows this error message: Server error HTTP Error 500 (Internal Server Error): An unexpected condition was encountered while the server was attempting to fulfill the request. I emptied all caches, reloaded the files, checked the forums and bug tracker and it just doesn't work. Any suggestions to get this to happen?

Anybody? No one has this issue?

I could really use this too. Anyone?

My client is using UPS and USPS for shipping. In California, you must charge tax on shipping if it isn't an actual pass-through cost to the customer. In other words, if you add a handling fee, the whole thing is considered a service charge and is taxable. In the UPS module, you have the option to tax the UPS methods using the standard tax from the drop-down menu. In USPS, the handling fee box is there, but not the choice of the tax-ability of that shipping method. So it is not taxing the USPS shipping. Am I missing something?

One of my store customers just reported the same thing. I have many stores with CC 4 and started way back in the early CC3 days. This thing is getting really buggy - I have all kinds of different problems with every store. Time to just give up and switch?

My store clients want to allow purchases of out of stock items and then show backorder on items when they do partial shipments. I haven't dealt with this and haven't been able to find a good way to do it. Anyone have a method for this that they like and would share? Thanks much.

Got it figured out. My server won't correctly use mail() and localhost for sending that registration email (although it is fine for bulk email and order status ???). When I switched to SMTP and the actual mailserver with authentication it worked.

For some reason, the new registration emails have stopped being sent. All other email functions of the store are fine - order confirmations, order status changes, forgot password, bulk email customers, etc. All of them work. Just the registration emails don't go. I did an upgrade to 4.2.3 from 4.2.2 to see if that would fix it, but it didn't. Anybody else have this issue and, hopefully, a solution? Thanks.

OK, I found a mistake on my end for the skipping part but now it says the Authorize.net ID or Password are not valid and I know they are. That gateway was one of the updated files. Somehow the module info isn't getting to the Authorize_AIM output. When I look at it in debug, it shows blanks for the send info and also shows auth_capture when the AIM module is set for auth_only. So it is apparently not seeing the info. So it appears that in 4.2.3, test mode does not work from the store to Authorize.net. If I go live in the store and turn on test mode at Authorize.net, it works. If you try test mode from the store, Authorize.net does not accept the login ID. Looks like an issue I need to put in Bug Tracker.

OK, I found a mistake on my end for the skipping part but now it says the Authorize.net ID or Password are not valid and I know they are. That gateway was one of the updated files. Somehow the module info isn't getting to the Authorize_AIM output. When I look at it in debug, it shows blanks for the send info and also shows auth_capture when the AIM module is set for auth_only. So it is apparently not seeing the info.

After going from 4.2.2 to 4.2.3, if you buy something at the store and try to checkout, it goes from the view of your basket right to the confirmation screen and skips all payment options. Nothing goes to the gateway (Authorize AIM) but the order is registered in the store as successfully processed when it isn't. I have gone over and over the updated files listed and can't find the issue. I do have some mods in the store but have very carefully checked the code in the changed 4.2.3 files and it seems OK. Any help here would be appreciated.