James Ellerman

For the sake of others reading this thread, we disabled the database cache through the admin web interface and the problem has not occurred since (see settings - store settings - advanced tab, under performance set "enable caching" to disabled.

Sent you a PM with my email details, thanks.

Yes, we are definitely running 6.0.6. Any ideas on how to troubleshoot this further? I can send you database dumps if that helps. I can't see anything immediately obvious with the accounts that have the issue, looking at the underlying database. I have manually reset the password through the admin interface on one account that had the problem, and I can log in as the user. I note that the user has no address book entries, but I'm not sure if this is significant.

I believe I'm running 6.0.6 code, and if I understand correctly, this fix was included in 6.0.6? By the way, how do I check the Cubecart version from the admin console to confirm the version I'm running?

This is still an issue for me. Roughly 1/4 of users who create an account on the site are getting this error. Many of them are having to use an alternate email address to create another account, but some are just not bothering to order, which is costing us hundreds of dollars at a time. I'd really appreciate some advice on where this problem may be coming from. Is this a hosting issue? Perhaps there are some timing problems/delays writing to a database caused by a shared hosting solution? Would upgrading the hosting package to a faster/dedicated server make any difference?

Just tried to reproduce it again with trailing spaces and cannot reproduce the issue now, so I've got no idea what is going on now. I thought I had nailed it down. The problem with intermittent issues is not knowing how to reproduce them. Anyone have any ideas?

No bulk import. All users are created by the users themselves. The users that create themselves with a space at the end of a field end up with corrupt accounts. Even removing the spaces and saving the accounts doesn't seem to fix it. The only fix is to delete the account and recreate it from scratch. Only accounts created with the trailing space seem to have the problem, others that do not have the trailing space are fine.

I think I've reproduced this issue. If I create a user account with a space after the title (eg: "Mrs " with a space at the end of the word Mrs), the account does some strange things. I can create the account just fine as a user, I can set all the user details and save the account, but when I try and log in to the website to place an order, it sends me into an endless loop, and doesn't actually log me in. Rather than giving me an "invalid name or password" error, it just refreshes the same page as if I haven't even logged in, asking for my username and password again, and not logging me in. I haven't tested other combinations of spaces before and after the titles, names, passwords, etc, but it would appear that there needs to be more checking of the field data before it does into the database. EDIT: It may also be happening with addresses too, if there is a space at the end of any field, like a street name.

I'm seeing the same issue on 6.0.6, error 726. Users are reporting strange behaviour, but I can't narrow down exactly what is going on. The symptom is that users cannot change passwords, or create an account they cannot log into, and are unable to reset the password. Surely someone else has seen this? It doesn't seem to happen for everyone who creates an account, but I can't for the life of me work out the common thread here that is causing the issue for some people and not others. Error is something like this (exact details changed to protect the innocent): File: [user.class.php] Line: [726] "INSERT INTO `pok_CubeCart_customer` (`title`,`first_name`,`last_name`,`email`,`phone`,`mobile`,`password`,`salt`,`registered`,`ip_address`) VALUES ('Mr','Firstname','Surname','[email protected]','phone_num','mobile_num','700d01880c3d112d125d728ed98db7cf6ee583a2b599732ab22a1894dd1ff9cd664cc24a14815b69b340e4cf3cafac511982d3f5e2941f5ac07eda0884df0940','0ae0ad80','1439778466','ip_address');" - Duplicate entry '[email protected]' for key 'email'

For the information of those reading this post, my further testing showed that the URLs that are automatically embedded into the emails sent to customers end up all messed up when information is merged into the return URL (they have /modules/gateway/payflow added to them. Fortunately, Payflow Link has the option to ignore the 200 OK return code from Cubecart, but the information above allowed me to correct a problem with the version 1.0.0 of the module to allow the payment module to update the status of the order correctly if the Payflow transaction failed. I did this by having a separate function to process the order, and another to silently update the status using a silent POST within Payflow to update the status. That way, we simply return to the index.php code with either cmd=process or cmd=call used, depending on whether we are updating the order status (silent post) or returning the user to the store site (post). Instructions for use are with the plugin in the plugin marketplace.

I think that's done it. There is some strange behaviour on the Payflow side that makes users get stuck in the Payflow page when a transaction is declined. Rather than presenting them with a button to return back to the store, it only gives them a back button to re-enter their credit card details. As such, their store cart is not cleared, but on the plus side, a silent URL return sets the status on the order to DECLINED, which is good. I'll need to work out if there is a way to fix the Payflow side of things. I will update the Payflow module to 1.0.1, and post it on to the plugins store. Instructions on how to set the Payflow URL will be included in that file. Thanks again

On further testing, it would appear there is some more work that I need to do to complete this module. Currently, for Payflow Link to correctly process a failed transaction, it needs to be able to send the HTTP POST to the Cubecart website, and receive a "200 OK" reply from Cubecart. There appears to be a problem with Payflow Link receiving this OK message back from Cubecart. Presently, the Payflow Link return message is sending a POST to /index.php?_g=rm&type=gateway&cmd=process&module=Payflow along with numerous other fields, including &DESCRIPTION=$cart_order_id, and &RESULT=$result, which I use in the payment gateway module to link the original order. Because Payflow must be configured to do a silent POST message and receive a 200 OK message in return, when it does not receive this, it voids the credit card transaction, but sets the status of the Cubecart order to PROCESSING. Is the missing 200 OK return code something that needs to be added to the payment processing module, or is this something that Cubecart needs to do but does not (or requires a configuration change to be able to do)? How do I get Cubecart to send an OK message in reply to the Payflow POST message?

Don't worry, Al sent me a link to post the module on the CubeCart site. The module is now added to the list for anyone who wants to use it. Thanks again bsmither

Done. Thanks for the info!

FYI, I have successfully created my own plugin for Payflow Link payment gateway. Please feel free to use this, verify the code, and/or post on the site as you see fit. Use at your own risk, etc, but it seems to work fine in my testing.