datakick

Maybe you are using nginx with incorrect rewrite?

Of course you can disable the email. There are many ways to do this: disable / uninstall module edit module and comment Mail::Send command delete email template install conseqs module and set up rule to block this particular email and more... I personally think it's not very good idea to do this, though. You should always verify that the trap didn't catch some valid bots / users. It shouldn't be such a big deal - with properly set up robots.txt, you should catch only a few bots per month. I personally receive the email maybe once every two months

CoreUpdater will fix code in core only, it will not touch your module. But, in this case, you won't have to do anything. This issue will just be fixed 'twice' 🙂

oi, there's a new bug in core 🙂 When NoCaptchaRecaptcha module is installed, the call to Module::isEnabled('NoCaptchaRecaptcha') returns false, while call Module::isEnabled('nocaptcharecaptcha') returns expected true. I'll fix this in the core. Until then, you edit override file (\override\controllers\front\ContactController.php) and replace all occurrence of Module::isEnabled('NoCaptchaRecaptcha') with Module::isEnabled('nocaptcharecaptcha')

Can you check if the module's overrides are installed correctly?

TB version? Url?

Every merchant has their own needs. Some of them sell worldwide and would like to see country/state. Others only sell locally. Some merchants absolutely have to see postcodes, others don't (yeah, there are countries with optional postcodes). Many EU merchants can't live without seeing VAT numbers, US merchants couldn't care less. What about business name? For b2b store it's also a huge requirement, for b2c not so much... It's not possible to include all these information by default. The list would take too much space, and it would contain so much information that nobody could find anything, really. So, the decisions were made. The list contains those information that 80% of merchants needs the most. Of course, it sucks to be in the remaining 20%. But hey, customize it. That's why it's called open source.

Why should there be a thread like this in the first place? I'd say this is quite personal. I don't know exactly what medical treatment Lesley is going through, but I'm sure he's not thrilled to "write blogs about it".

You answered yourself. Disable check cookie IP feature, and you are good to go. What is the problem: The IP address the HTTP request arrived from to your server was different than the IP address for which original cookie was issued. Thirtybees detected this situation, and reacted accordingly -- disregard the request, and logged you out. The Cookie IP address check feature is very outdated, and in my opinion it should be removed from the code. The original reason to have this was to prevent 'highjack cookie' attack. For example, if you were on a WIFI in the coffee shop, and logged-in to your store (without SSL), then anyone in the coffee shop could intercept the HTTP request, extract the cookie, and use it to gain access to your back office. The IP address check mechanism can prevent this because the new request comes from the different address... That's the theory. In practice, the attacker would share the IP address with you, because the coffee shop WIFI is behind some router with single public IP address. And so this IP check would not work at all here... The only correct way to prevent this attack is to always use SSL (https) connection. Note that there are many reasons why IP address changes. You ISP provider can have multiple gateways and load-balancing request between them. Or you can have your server behind cloudflare,... and many more.

The problem is with module MultiBlockAtoh You need to delete it from /modules/multiblockatoh or modify it -- change signature of method unregisterHook so it looks something like this: public function unregisterHook($hookId, $shopList = null) { ... }

I guess you can solve this with a little javascript that would unselect all attributes Display only first attribute (Color), and hide others (in your case Size) When customer selects color, then filter all sizes according to color selection, and display Size selector This kind of modification would take like 10-20 lines of js code.

We consider thirtybees core to be very feature rich. There's no good reasons why another features should be added into the mix, as it works for 80% of the merchants out of the box. What we want to achieve is the stable, and easily extendable, system. That's the reason why most of the development was aimed into these areas. Fixing bugs, improving error reporting, overhauls of the most buggy code areas, adding more checks etc... With all this, we can finally have a system that can be deployed to production with confidence, and it will work even if left unattended. That's not something you can say about the competition (yeah, I'm looking at you 1.7) The problems with this kind of development is that, well,... there is not much you can say to the community. There is not big roadmap with flashy milestones. It's a boring, chore-like work. That's one of the reasons why nobody writes about that, here or in some blogposts.... I know it can be frustrating for you guys that don't understand code and don't look into the github... that's why this kind of thread flames every now and then

Of course, you can edit your theme template and add the code to appropriate place.

Maybe tb store github integration is down, or there's some problem with it. I can't do much about it. Anyway you can download it either from my store, or directly from github.

This could be implemented transparently. For example, there could be some ImmediateTaskExecutor that would execute tasks arriving into the queue synchronously, in the same thread / process. This way everything would continue to work *in the same manner* as it does now. No cron / external services would be required, and emails would still block / slow down the process execution. This would still work for most of the merchants. But there would be an option to set up external task executor and push the these expensive tasks to background, for those merchants that need that.