Jump to content


  • Posts

  • Joined

  • Last visited

Profile Information

  • First Name
  • Last Name

Recent Profile Visitors

128 profile views

r00tb33r's Achievements


Newbie (1/14)



  1. Solved it for me. So what causes this module to break and misbehave like this? It was working until yesterday.
  2. Per suggestion in another post, gamification module is the culprit. Since I the back office is not working and I can't get in there to disable the module, renaming the module directory did the trick. I then reinstalled the module and disabled it properly without ill effects. This needs further investigation.
  3. Today I started having a weird problem. I can't load the admin (back office) login page, and if I clear cookies I can load the page but the login with credentials will time out. Since I haven't made any platform or content changes to my store in months I contacted the hosting company to see if there is a problem on their end. They have identified that the SQL query during login runs for 60 seconds and then times out. Normally this shouldn't happen, it takes 3-4 seconds to login usually. What might be the cause of this? I run PS with default theme, PHP 7.0, and MariaDB 10.0.36, LiteSpeed V7.1 I get the following at the admin login page: What can I do to resolve this? I can't do anything with my store if I can't get into the back office.
  4. And I do think that it's the issue with this specific user, as this user and this user alone was triggering multiple submits for both orders and messages. I have not had it like that with any other user. I'm pretty sure it's something with their input device but nevertheless the sales platform should filter out those order submits. I deal with a special kind of customer, these are the sort of people who tend not to be computer literate. Comes with the territory unfortunately. They are the sort of people who loathe shopping online, always ask to speak to me on the phone, and always beg me to process orders by phone (which I can't). But that's what happened. And with one specific user. I have not had it exactly like that with other users. No, I'm still on PHP 5.4 on nginx and MySQL 5.5.51, on real hardware, not VM. Been running like this for over a year. I'm using the default config provided by HostGator. My store is not fast but it's tolerable. PrestaShop is not known for being fast from what I've seen.
  5. The bug is the logic error where the duplicate checkout request returns the same transaction ID instead of failing and returning unsuccessful payment, because PayPal does refuse to charge twice. I forgot about it too until this person exploded into my inbox. I don't think hosting had anything to do with it this time. Actually the particular person in question has a faulty mouse I think because their contact messages through my fast WordPress site also had duplicate submissions. In my case I have nothing to refund to them because PayPal doesn't take their money the second time, which is even more confusing to the customers when they get two orders and two receipts and think I took their money more than once. Also the message on the checkout page, as well as any messages I send to the customer don't really do much to reinforce customer's faith in reliability of my site. Half of them don't even understand the difference between giving their financial information to me or to PayPal. Unfortunately the audience of my store is predominately not computer literate. For example most of them don't have a PayPal account and instead use guest checkout on PayPal. I need these dummies to have confidence in my store and my business. The store platform should keep the user from doing something they're not supposed to be able to do. Elegant solution is when the store platform filters out duplicates or invalid orders. I consider a duplicate of a PrestaShop order with the same PayPal transaction ID to be invalid. I thought about creating a band-aid fix for this problem. Disabling or hiding the submit button using JavaScript once it's clicked. One problem though, what happens if two click events fired off before event handler runs the code to hide the button? That's why I call it a bug, it does trip PayPal, it prevents a duplicate payment, but PrestaShop thinks the payment was successful, even though no new PayPal charge was performed for 2nd and 3rd request, and so on. The question is, do I file this under PrestaShop checkout bug or under PayPal module?
  6. Beats me. But it has happened before, I had a few doubles, but this is the first triple. I think that's the key issue, all duplicate orders in PrestaShop have the same PayPal transaction ID, so this would imply that repeat payment submissions are not returned as unsuccessful even though no new PayPal charges are generated. So it seems that PrestaShop or the PayPal module considers it a "successful" transaction. Looks like a bug (logic error) in PrestaShop or the payment module. I use the official PayPal module that everyone else uses I believe it's best known as "PayPal Europe". The checkout mode for PayPal is "Express". Default. Whatever is the default in PrestaShop and/or the official PayPal module. Thanks for trying. At least it brought us to a useful fact, the fact that duplicates get the same PayPal transaction ID and therefore were not considered "failed". Not sure what I hope for more, me screwing up configuring something or that there is a bug in PrestaShop and/or payment module.
  7. Anyone? This is basically a need to filter out multiple submit requests in one checkout session. As I stated for some users more than one order (duplicates) are generated. There has to be a way to handle this.
  8. I'd like to get some user recommendations for an abandoned cart recovery service/module compatible with PrestaShop. Primarily focusing on users who did not register in my store (no contact information like email address). Basically a service that will pester the visitor with targeted ad banners on other sites (like Facebook for example). I would prefer to get insight from users with personal experience with these services. The product category (if it matters) of my store is specialized apparel like gowns and athletic wear. Suggest please. Thank you!
  9. Hey all, I've got a problem with a hyperactive "rapid fire" customer who managed to generate three (3) orders in one go. In traffic analysis this customer only visited the checkout page only once, and all three orders were generated in the same moment. I use PayPal Europe payment module to process the payment and finalize order, and use multi-page checkout (not single page). Of course the customer only meant to place one order and immediately freaked out and started flooding me with messages. Interestingly the messages were also coming in with duplicates (through WordPress contact form). I was able to recreate this scenario by rapidly pushing submit button multiple times. I think the problem is a faulty mouse, faulty touchscreen or a faulty user who drank too many caffeinated beverages. The user in question was using Microsoft Edge browser. Now, my PayPal merchant account is configured to reject duplicate payments so this customer was charged only once, but nevertheless there were duplicate store orders generated. Is there a way in PrestaShop to prevent duplicate orders from the same user in a short span of time? Perhaps like a 10-second timeout or something, to prevent the multi-click scenario? My PrestaShop store is version Insight and suggestions are appreciated.
  10. PrestaShop default-bootstrap 1.0 "Single Page Checkout" Countries: United States, Canada Both require zip code and state, both have a zip code format set, both contain states. Not a configuration problem. They are set up in default configuration, I didn't change anything there. On the checkout page, if customer clicks "Guest checkout", the form opens. Section "Delivery Address" is missing zip code and state fields. Changing between countries does not fix. If customer tries to submit the form the following errors are displayed: So PrestaShop does require the state and zip code, but where are the fields??!!! THEY ARE NOT SHOWN! (style="display: none;" and state select element is not populated) If I click "Please use another address for invoice" checkbox the "Invoice Address" section opens. Invoice Address state and zip are shown! Invoice Address states are populated. So why are delivery address state and zip not shown, but work for invoice address??? I received complaints from customers that they are unable to do checkout because of this problem!!! Looks like a bug (theme bug?) to me. Help is appreciated. Thanks in advance! PS Yes, I understand that some PrestaShop users disagree with guest checkout feature. This topic is not for the argument for/against the guest checkout feature. [EDIT] I noticed that this problem is also present when Guest checkout is disabled, and "New Customer" section is missing state and zip code fields on the single page checkout. I think it's more a single page checkout bug.
  11. Looks like the bulk of the code is in \classes\Carriers.php... The bug is probably somewhere in the function calls or type conversions. "Disable carrier out of range" is too buggy to use so I implemented a hack to make it work without it. I implemented a poison value for ranges where I want to disable a carrier.
  12. PrestaShop v1.6.1.4 default-bootstrap v1.0 There's a bug in "Billing - According to total price." for shipping carriers when "Out-of-range behavior - Disable carrier" is set. Testing: Test 1 Ranges: $0 to $250 is $10 $250 to $500 is $20 Settings: Billing - According to total price. Out-of-range behavior - Apply the cost of the highest defined range Input: Cart total = $240 Output: Shipping rate = $10 - CORRECT Test 2 Ranges: $0 to $250 is $10 $250 to $500 is $20 Settings: Billing - According to total price. Out-of-range behavior - Apply the cost of the highest defined range Input: Cart total = $280 Output: Shipping rate = $20 - CORRECT Test 3 Ranges: $0 to $250 is $10 $250 to $500 is $20 Settings: Billing - According to total price. Out-of-range behavior - Disable carrier Input: Cart total = $240 Output: Shipping rate = NO CARRIER - FAIL! BUG!!! Why fail? Because $0 < $240 < $250. Test 4 Ranges: $0 to $250 is $10 $250 to $500 is $20 Settings: Billing - According to total price. Out-of-range behavior - Disable carrier Input: Cart total = $280 Output: Shipping rate = NO CARRIER - FAIL! BUG!!! Why fail? Because $250 < $280 < $500. ------------------------------------------------- Please tell me where the code for this logic is so I could fix the bug. I need this functionality working correctly to implement a second carrier that is only enabled for a certain $ range. Thanks in advance!
  13. I have now confirmed that there is a defect in the PayPal USA, Canada module. Sandbox is working with my sandbox credentials in the PayPal Europe module. There was no problem with my credentials like PayPal USA, Canada module says.
  14. I have verified. The input is correct. No spaces or other stray characters. Yes, I did click the radio button "Test (Sandbox)". My normal credentials are working for "Live", but the sandbox business facilitator account created on developer.paypal.com (sandbox email address, API username, API password, signature) are not accepted. I did not make a mistake. There is something wrong with the module. I really need the sandbox working now, I need to test the tax rate table before I launch the shop.
  • Create New...

Important Information

Cookies ensure the smooth running of our services. Using these, you accept the use of cookies. Learn More