Al Brookbanks

It's recommended but lower versions should be ok so long as the client supports utf8mb4.

We are please to announce the release of CubeCart 6.5.4. This is a maintenance release with a number of minor new features. Important Release Notes This version converts the database encoding to utf8mb4. Please make sure that your installation of MySQL or MariaDB supports this character set. * Download: CubeCart-6.5.4 The table below shows the new features added to this release. All 95 closed issues can be found on GitHub. Issue New Feature #3543 List view aded to filemanager. #3544 Sorter added to filemanager for name, date added and filesize (see screenshot above). #3536 reCaptcha added to password recovery tool. #3532 Customer comments icon with link added to dashboard orders (unsettled orders) list. #3525 Bulk action to add/remove orders from dashboard (unsettled orders). #3488 Use of hooks to manipulate dashboard (unsettled orders) bulk actions. #3487 Order list to have new "Last Updated" column with sorter. #3447 Preview icon on category and document list to view on front end. #3427 Switch to allow for product and category descriptions to be parsed via Smarty (for dynamic contnt). #3425 Improved character set support utf8mb3 to utf8mb4 #3424 Exchange rate "buffer" with percentage adjustment. #3418 Order summary to show both custom order ID (if available) and traditional order ID. #3413 Filemanager last location memory for product option images #3392 Adjust product sales report by date. #3385 Switch off order email whilst in PayPal Sandbox mode (PayPal Commerce 1.9.5+ required). #3420 Rich Text Editor - Emoji Picker Plugin * It is possible to list available UTF8 character sets with the MySQL command: SHOW CHARACTER SET LIKE 'utf8%';

Great!!

A lot of hosts block out going SMTP connections. Just FYI. You can check with them.

You can go to the store settings then the advanced tab and try a different method to send email e.g. SMTP

Show them that error message. Then they will point the finger straight back as us no doubt which is typical. An undefined function normally points to missing PHP libraries.

It's funny. This is the first time I've ever seen this error. It's failing on the function escapeshellcmd() It's a hosting compatibility issues. Can you ask your hosting company?

Can you check the request log for any errors? One of two things are happening. A missing PHP extension causing a 500 server error or possibly an error sending the confirmation email.

Good luck! Please use the Downloads section under the file manager area of the back office to add your files first.

Yes this is totally possible. It's quite simple. If a product has a digital file linked to it via the "Digital" tab of the Add/Edit product page it will act as a digital product and if not it doesn't.

I haven't been able to reproduce that. It sounds more like a session problem.

The disable button on your store seemed to be working already so I wonder if the issue is different on your store. It would be worth fixing the JS error on your checkout however. See attached.

@jasehead I totally agree about a work around being a win but I don't think we need to. @Debyink I've solved this on your store. The JavaScript to disable the pay now button wasn't working due to the order of certain elements in your skin. I will release a new version of the PayPal commerce extension that fixes this by delaying the PayPal JS code.

Sounds like a possible work around but not actually a fix. Probably not a bad feature to have anyway. I just cannot get PayPal sandbox to play ball today. Infuriating on an already horribly complex situation.

Stock handling could indeed come into this. If you have stock to reduce on processing this shouldn't cause a stock level problem.

I wonder if it's something silly. In the file modules/plugins/paypal_commerce/hooks/class.cubecart.display_basket.alternate.php find: $("#checkout_proceed").attr("disabled", true); I think better code that may be more reliable across browsers would be: $("#checkout_proceed").prop("disabled", true);

Reading back it really sounds like the pay now button is being clicked twice still. On first click if it takes too long but the button doesn't get disabled and they click it again this will happen. The five seconds apart orders confirms this in my mind. How long does a customer wait before clicking the button again if the server is too slow processing the payment. Five seconds should about the right amount of time to lose patience. I've got Debys site cloned but infuriatingly PayPal sandbox isn't working right now. Ill try again later.

Ok I will. I need to try and find a whole day to look deep into this.

What is the confusion? The PayPal button says "Continue" and not "Buy Now". If the issue comes over confusion then is the confusion the above, something else and do you have any suggestions to improve it? PayPal moved away from being the final part of the checkout process to a middle part.

No I don't think so. We had a small number of merchants facing this issue. Since that patch only yourself and debyink are still reporting problems. I've cloned Debys store which I hope to test this afternoon. The patch relies on the skin accepting the new javascript to disable the pay now button on first click. I'll be looking at that first.

Sorry. My mistake. I'd lost track of versions!

The old version 1.9.3 didn't have the new code to prevent this issue.

So this must be a safari issue. Can I clone your store and test it in Sandbox mode? This issues doesn't seem to happen anymore to other merchants that did have the issue. So frustrating for you.

Are you still on 6.0.8? I'd really recommend upgrading if so.

How long ago did you purchase this? I'm sure Ian will get back to you soon. @havenswift-hosting You can contact here https://www.havenswift-hosting.co.uk/clients/contact.php