Jump to content

Welcome, Guest!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

datakick

Administrators
  • Content Count

    1,942
  • Joined

  • Last visited

  • Days Won

    243

datakick last won the day on May 25

datakick had the most liked content!

Community Reputation

1,428 Excellent

About datakick

  • Rank
    Petr Hučík

Information

Recent Profile Visitors

5,110 profile views
  1. This is related to server side cache. Make sure you choose file system, and it should work.
  2. datakick

    Matomo

    White pages usually mean some fatal error. You need to look into your server errors log to find out the root cause.
  3. This was actually a bug in 1.2.0. It is fixed in bleeding edge (both main / 1.2.x)
  4. Works fine for me. Please check your server error log, or /log directory in your thirtybees. There might be some clues about what is going wrong
  5. Hi @ariom If you PM me access to your back office, and ideally ftp + mysql access, I can have a look at the issue
  6. datakick

    Matomo

    What does it mean? Any error message?
  7. Yes, Sprint 5 will end tomorrow. Sprint 4 didn't really happen because I was quite ill. I will write some post to inform about the work done in sprint 5 soon
  8. I believe it's because you set 'Out of range behavior' to 'Apply the cost of the highest'. When the cost is $5, it's out of range of <9.98 ... 9999999>. Carrier is not disabled, but the highest cost is chosen. There is only one range, hence the $20 shipping fee
  9. In my opinion, when customer goes to checkout page, they need to be reassured first. They really want to know is what carrier they can use what payment method they can use the final price And chex tries hard to answer these questions. Customer is not required to log in or create an account before these questions are answered.
  10. Unfortunately I don't have a Samsung device to test this problem. But I don't really believe this is related to device, more likely it's a browser issue. What browser did you use? Can you access javascript console and look if there is any error?
  11. There are other things you can do to make it harder for bots. For example, you can try to change friendly urls for cart and order page, or change html id and class of submit button. Depending on the bot logic this could help (or not). You could also measure time it took to create cookie <--> add product to cart <--> and initiate checkout. If this all took only a few seconds then it's a good indication that it's a bot. This should be fairly easy to implement, using overrides for Cookie.php, Cart.php, and OrderController.php
  12. 34 fake accounts is not much, so I'm not really convinced this is a bot. I would need to see the logs to be more sure, but this could very easily be real people. If that's the case, there's not much you can do. How is this card testing works? Do you use some embedded cart form? If so, I would suggest to get rid of it. There's no real reason to have it, anyway. Customers are pretty accustomed with being redirected to payment gateway to complete the transaction. In fact, there are some customers (myself included) that would abandon transaction if store collects (or pretend to collect) the card information directly. If you already redirect your customer to payment gateway, and they are not able to stop it -- you should consider using different payment provider with better security radars.
×
×
  • Create New...