datakick

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.

It would, but that functionality is not implemented on purpose - this db migration thingy is still in an early phases, and there can be some bugs. It's much safer to simply not allow 'Fix all', or even 'Automatic fixes' right now

This is a bug in the module that was always there. It would reproduce on prestashop 1.6 as well if you run it on php7. You should ask the developer to fix it -- make it php7.2 compliant. You can also fix it yourself by changing the signature of the method to public static function insertTagM($public=false)

You don't need to store them. As long as you have card detail input fields on your site, you are processing and transfering credit card data. And you need to be PCI compliant for that. But I think we have highjacked this discussion. It's about jquery update, not about PCI compliance.

That is exactly what makes you PCI compliant. And let me tell you, there's nothing wrong with leaving your site. In fact, it might help your sales. When some website ask for card details directly, I become very nervous. And unless the website belongs to a well-known company, I leave without completing the purchase. I'm just too scared to send my card details to anyone

There's a native paypal thirtybees module that works fairly well. And of course there's stripe. I would love to use it myself, unfortunately striped does not support my country yet.

Any merchant that wants to process, store or transmit credit card data is required to be PCI compliant. The solution is simple - don't do that. You can choose a payment provider which complies with the PCI, and which can process, store or transmit card data, so you can avoid the whole struggle with PCI. This means that the payment company you work with processes the payments itself, so your website doesn't touch customer's cards details. They take all the PCI burden themselves. Now, if some payment provider have requirements on stores they integrate with is a completely different topic. It's not PCI, it's a vendor-specific requirement. Braintree, of course, can have any criteria for their partners. But that doesn't mean you are in breach of PCI.

Thanks @musicmaster for your reports. But to be frank, I don't really believe these have much to do with 1.1.x did this module actually ever worked correctly? In my experience, when you ask customers to evaluate some feature / new version, they tend to bring up persistent issues... because they want them fixed, and they frustrate them. I believe this is on of this case. If not, please let us know what exactly does not work in 1.1.x, but work in 1.1.0 Very vague. Usually when customer can't complete the order, the problem is not technical (bug in code), but it's usually misconfiguration. Disabled country, bad carrier zone definition, carrier-payment association missing,... You know what I'm talking about. If there indeed was some bug in 1.1.x that prevents completing order it would be a showstopper, of course. I personally haven't encountered it - and I'm running my own store on 1.1.x, and already migrated few of my customers to bleeding edge as well. So excuse me, but I'll disregard this report as well, at least until you or somebody else can provide some reprosteps / context when this happens. Layout, really? Very unlikely 1.1.x broke theme layout. Core has no way to impact how theme outputs its content. When there are theme-related compatibility issues, they are always caused by controllers providing wrong / different datasets to view layer. But these problems does not change layout, etc... they result in incorrect data being displayed. And again I need to ask - is this new issue in 1.1.x? If you rollback to 1.1.0, does the theme displays the layout correctly? I really don't think so At the moment, tb does not have any long-term plan regarding new features - no new feature development are really on the planning board. Current efforts are aimed to stabilize the system. That means mostly bug fixing. Problem is that when we fix a bug, very often somebody claims it's a compatibility issue (you too, by the way). That's because some module / theme / modification worked around this bug. It expects the bug to exists, and when it's fixed, the module stops working. Now, tell me, should we really resign on bug fixing, because what if some solution depended on it? If you really think so, then let's close this project. Because it will die anyway in a slow and painful death. What standards did we broke? We know that there there is a compatibility issue on 1.1.0 regarding themes. This is actually talked about in the other thread, and is already (somewhat) fixed. Now, you might consider it frightening that the 1.1 compatible theme was released. I look at it a little differently - as an acknowledgement of the existing issues in the theme by its author. It's a regular fix. Of course, I don't expect *all* theme developers to do that. Hence the effort to increase the theme backwards-compatibility again, see code in issue-1104 branch. I haven't as well. But posts like this really take its toll