datakick

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

But I agree with you and Markus that it's not necessary to throw these warnings in front of merchants so aggressively. So I've modified the solution and hide all these warnings behind a Show button:

Or course I'm serious. After all, the fact that the theme is maintained by thirtybees does not make it flawless or bug-free 🙂 And as you see, even native theme has these issues. Without these warnings, nobody would ever discovered them, or fixed them. And it wasn't that hard, let me tell you. The fix took the whole 3 minutes of my time. And the result is correct -- for example, the beesblogcategories module now actually shows the categories in left column, as it should. These warnings are there to nudge theme developers into doing their work properly, and to nudge merchants to verify that modules mentioned in warning sections works correctly

You are probably right here, it's not necessary to frighten users. I'll try to come up with a little less hardcore messages

Paging @lesley

It does. It behaves exactly as I described above -- if the theme *mentions* some module hook in config.xml, then this config is used. Otherwise, hooks are not touched for this module (but warning is emitted). For themes with correct config file, the result is the same. For themes with incorrect config file, the the result is still functioning theme + couple of warnings. In 1.1.0, the result was non-functioning theme. That's a difference Of course, we could just hide these warnings. Merchants would be happy that *it's all goooood*. But the truth is, it's not. Merchants should verify that the mentioned modules were installed correctly. And theme developer should fix their theme. Again, it's about correctness. We know that the theme contains errors, is non-deterministic, not-specific. We can still try to install it, and the result will *most likely* be ok. But the problem is that it might not be ok. And that's not the situation we want to officially support. When you have theme that is not correctly written, then you can either have a system that installs the theme, says everything is ok and green, even though you can clearly see it's not. This is how prestashop do it or you can have a system that at least warns you something is wrong, and points you to the problematic parts

Ok, branch issue-1104 contains proposed fix for this issue. Anyone who can, please test and let me know how it works for you. Simply use core updater to forward to this branch.

There is PaymentModule class in tb. However, the proposed fix is not very good. It was actually rejected by prestashop. Doing this check in validateOrder is way too late -- payment is already processed, and money are on the way to the merchant. That means that order should really be created, even if stock will go to negative numbers. There is no easy solution for this problem, as there can always be some time that your customer spent off-site. The only way to solve this is to implement some stock-blocking mechanism, complete with automatic release

We didn't implement these changes because of the beauty of code, but for correctness. That's very different

Of course, it's not possible to verify correctness of the config.xml file. But it's possible to detect *missing* sections. My battle plan is this: For every module mentioned in theme config file, find all displayable hooks this module implements (displayLeftColumn, Header, displayProductFooter). If no such hook exists, then the module does not have impact on theme/front end at all, and should not be mentioned in theme config file in the first place. If module implement any displayable hook, then we need to look into <hooks> section of the config file. If there are any entries for this module, we should consider this module to be fully managed by theme, and don't intervene. Simply replace all displayable hooks with hook list defined in config file, like we are already doing now. And hope that theme developer defined it correctly. However, it there are no hooks defined in the <hooks> section for this module, then something is very fishy. Theme says to install module, but does not specify how it should integrate into theme. This is the situation that causes the problems. Fortunately, we can detect this situation, and report it as a warning. And we can also react to it. We can consider these modules as not-managed by theme, and don't do anything extra. Don't uninstall module's hooks, don't change hook exceptions, don't adjust position... because theme does not instruct us how to do it I think this is a win-win solution. It allows us to gradually harden the rules, and yet maintain support with current themes. I have a proof-of-concept of this ready for testing, and will submit it soon. I hope you can review the changes