datakick

There seems to be a bug in tb core. The Webp compression settings is saved, but never used. Fixed in commit https://github.com/thirtybees/thirtybees/commit/86b570f23a08f877bdd8c078c09382224ac593c5

This problem happens when there are proxy servers in front of your store. These proxy servers usually act as a cache or a load balancer. When your visitors visit your server, the browser would send request to the proxy server. If proxy can't handle the request itself (usually because it's for dynamic php file), it will make it's own request to your php server. From the perspective of your php server the client IP address is address of proxy server, not IP address of actual visitor (request come from proxy server, not from browser). Now, as long as there is only one proxy server everything works fine, because the IP address of the client remains the same. However, if there are multiple, load balanced, proxy servers in front of your store, then each request to your php server can actually come from different proxy server with different IP address, and cookie the security enabled by 'Check the cookie's IP address' will take place. Thirtybees will block such requests, and that's correct behaviour.

This is common problem for those that use cloudflare. The solution is indeed to disable 'Check the cookie's IP address'.

This is browser telling you that it can't translate domain name to IP address. That is 100% not thirty bees issue. There could be some redirect in your store to non-existing domain, though. If that's the case, you should see it in your address bar.

When you log in to your back office, thirtybees will store your current IP address inside the cookie. On every request, the store will check that the IP address stored from the cookie matches the IP address of the request. If the request comes from different IP address, it will ignore the request, and close the session. When you are behind cloudflare proxy server, end user (browser) communicate with cloudflare proxy server instead of your site. When cloudflare can't handle the request from cache, it will contact your server to get retrieve content. This server->server communication is performed by one of the hundreds of cloudflare servers they have in their pool. Which one will be selected to do the job is entirely up to cloudflare. The end result is that every request to your site can, and usually will, come from different IP address belonging to cloudflare. And thats the reason why 'check ip address in cookie' feature does not work properly with cloudflare. As I wrote, there are two ways to fix this. You can either disable this check - yes, that will make your store slightly less secure, but if you are using https you should be pretty much fine. Alternative is to retrieve and use real end-user IP address that cloudflare sends in header. You can do this by modifying php code. I personally do this by putting another nginx server in front of my php server, this nginx do this translation automatically.

The project is going forward as planned. There should be 2 major releases per year, 1.3.0 will be released during the summer. While we also planned to release s few bugfix releases, there weren't that many injections and regressions in 1.2 release to actually do that. That would be a lot of work to release 2 bugfixes. I understand that it can look like not much is happening when you look at github repo(s), but a lot of work is done behind the scenes. Some is work on private repositories (thirtybees api server, data collection service, scheduler, etc). Some is work on public repositories that is not published yet (for example, there is an ongoing effort to make core and native modules php8 compatible, and this must be released as a big bang). Also, tb core repo is not the only one that receives some love. For example there's a big overhaul of core updater coming soon.

Yeah, that's common issue. Once you are behind network proxy like cloudflare, requests from the same browser can reach your site from different ip addresses (that belongs to cloudflare). The safety mechanism kicks in, and your back office session is closed. If you want to use cloudflare, you need to disable IP check in the cookies, or modify core to correctly determine real source IP address (cloudflare sends this one in http header, but thirtybees ignores it)

This is how selling virtual products worked for years, and thirtybees supports it correctly. Look at 'EU VAT For Virtual Products' tax rule. Once you hit 10k euro limit, you should set this rule (or its clone) to all your products, and it should work properly

This is mostly cache for the image import functionality, plus few others. It's safe to delete the asset directory. Just expect your import job will take a lot longer. This cache can reduce the import from hours to mere minutes.

What does the 500 error says?

This is related to server side cache. Make sure you choose file system, and it should work.

White pages usually mean some fatal error. You need to look into your server errors log to find out the root cause.

This was actually a bug in 1.2.0. It is fixed in bleeding edge (both main / 1.2.x)

Probably Dispatcher.php

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

Hi @ariom If you PM me access to your back office, and ideally ftp + mysql access, I can have a look at the issue

What does it mean? Any error message?

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

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

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.

Of course, I'll fix this.

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?

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

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.

The problem is that specific prices are not used only for price reductions. A lot of merchants are using them to have different prices for different group of customers (per customer group/countries/languages/currencies), but that does not mean that the product is considered 'on sale'. Example: my product cost 40 EUR, which equals to 1032 CZK. But I can use specific price and sell it for 1000 CZK in order to have a pretty rounded price. But I don't want thirty bees to automatically show 'on sale' label.