datakick

The exception says it all - the module contains method printForm that expects 3 input parameters. However, module calls this method with 2 arguments, resulting in php error. Previous versions of php were more lenient, and such call triggered only warnings / notices. But in php7 it's no longer permitted. You should modify the module, and change signature of printForm method from public function printForm($vip_add, $vip_end, $vip_cards) { ... } to public function printForm($vip_add, $vip_end, $vip_cards=null) { ... } This will explicitly mark third parameter as optional, making php happy

Bleeding edge? If so, then it's in object model metadata

Anyone reading this might want a lazy version of Zen's solution. It works on Chrome desktop and I guess on most browsers. It is a bit of style sheet to add from the back office, over-riding the styles that need changing rather than editing them. Back > modules and services > custom code | add css /* Niara 1.1 patch to make radio buttons work */ input[type="checkbox"] input[type="radio"] .attribute_radio .attribute_list { cursor:pointer; opacity:0; position:absolute; width:auto!important; float:none!important; margin:auto; right:auto; left:auto; } Another solution is to download latest version of niara theme from github. This (and many more issues) are already fixed there

That's correct, the $.each rebinds this to the current item. Please file a github issue for this bug

The module does not really work on php7, unfortunately. That's because of some regular expression incompatibilities. I've managed to fix it locally, and will release it soon. But even with this fix there are other bugs, for example js code that generates elastic query can generate invalid expression...

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.

It's not easy to answer. Probably not, as this looks like a blind fishing expedition. The bot was just testing the waters to see if anything sticks. But note that ps / tb codebase is very prone to this kind of attacks. That's because there isn't any real database abstraction layer, and it's common practice to create database query by concatenating strings. There are hundreds / thousands such queries in the codebase (both core and modules). I'm sure few of them is badly written, when developer forgot to sanitize input values

This is some (blind) automated script that tries to find sql injection vulnerabilities in the system. This kind of attack is possible when developer forgets to sanitize input values for sql queries. For example, php script like this is vulnerable: $id_product = $_GET['id_product']; $sql = "SELECT name FROM tb_product WHERE id_product = " . $id_product; Db::getInstance()->executeS($sql); Php script expects $id_product to be number. But attacker can send anything, for example string like this: "'non-existing' UNION SELECT password FROM tb_employee" Which results in sql query SELECT name FROM tb_product WHERE id_product = 'non-existing' UNION ALL SELECT password FROM tb_employee This query returns employee password, instead of product name. PHP script will use this value and probably print it somewhere in the page. And attacker now knows (hashed) password of employee. That's just an example. There are a lot more attacker can do, including gaining admin access to your store.

Advanced parameters > Logs You can there also adjust log level that should trigger email notification

Before you can choose template you need to create them first, and save them in /themes/<theme>/templates/product/<name>.tpl The easiest way is to copy content of file /themes/<theme>/product.tpl, and make changes you want

Oh, it can happen anywhere. It really depends on employment contract. They usually contain clause like The Employee hereby assigns to the Company all rights, including, without limitation, copyrights, patents, trade secret rights, and other intellectual property rights associated with any ideas, concepts, techniques, inventions, processes, works of authorship, Confidential Information or trade secrets developed or created by the Employee during the course of performing work for or on behalf of the Company that the Employee conceives, develops, discovers or makes in whole or in part during or after the Employee’s employment by the Company that are made through the use of any of the equipment, facilities, supplies, trade secrets or time of the Company that the Employee develops, discovers or makes in whole or in part during the Employee’s employment by the Company that relate to the business of the Company, or the research, or development of the Company Which means that if he wrote even a single line *during* work hours (when he was being paid) the company owns the code. Even if he was on home office. If he used company issued computer for nginx development, then the company owns the code. Or if the company core business is related the the code developed (for example if they offer their own server software) they have valid claim as well. Ultimately it is up to the court to decide.