datakick

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

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

It's hard to do so. Thirtybees do installation check to verify environment requirements, but it can't test for everything. In this case, hosting provider severely crippled mysql functionality by setting max allowed index size. Thirtybees can't run properly in such environment.

Definitely not an 1.1.1 injections. Let's track this as an enhancement request: https://github.com/thirtybees/thirtybees/issues/1118.

I've filed an github issue to track this: https://github.com/thirtybees/thirtybees/issues/1117 Also, there's another existing bug issue directly related to this https://github.com/thirtybees/thirtybees/issues/1104

That was a different problem, with the similar result 🙂 And one of the reasons why the theme overhaul project was done for 1.1.0

I agree that the theme installation in 1.1.0 is not ideal, and *some* things should be improved or fixes. But let's start by explaining what is wrong, and why Every theme contains config.xml file that describes modules that should be installed / enabled modules to be disabled hooks positions The idea of this config file is that the theme will always look the same when you install it. Especially hook positions are important, because they allow theme developer to say what module hooks should be enabled. Not all content is required, for example some theme can decide that it doesn't want to display reviews in product miniatures order of module content -- for example, in left column display block categories first, then recent blog posts,... transplant module hooks -- when you install module, it is displayed as developer sees fits. But many times, module hooks can be transplanted to different location. For example, block categories can be displayed in right column instead of left column When the theme is installed, these steps are performed: all modules that are marked as disabled are disabled all modules that should be installed are installed all modules that should be enabled are enabled hooks for all enabled/installed modules are unhooked, and replaced by hook definitions from config.xml file The reason this discussion exists is the step #4. Prior version 1.1.0 there were few bugs. Module hooks were not unhooked correctly during theme installation, they were just somehow merged together. This resulted in non-deterministic result - every time the theme was installed it looked differently. Modules were ordered in wrong order. Some content was displayed multiple times, because theme transplanted hook to new location, but didn't remove the original hook. Some hooks that should not be displayed were displayed. Etc... So, this was fixed. Now the theme config.xml file is the only source of truth regarding displayable content. And it works nicely for niara / community theme, because these themes have correct config.xml files. Unfortunately, many (most) commercial themes don't. They are shipped with wrong config.xml files. Sometimes, they don't contain hook positions at all. Or the hook list is only a subset of what's really required. The result is crippled theme after installation. Hooks are unhooked by core, but they are not hooked back because the theme does not say so. I believe both thirty bees and theme developers are at fault here. Theme developers should have respected the api contract, and include all modules hooks into theme config.xml file. Then we wouldn't have these problems. But I'm not surprised theme developers didn't do that - because of the pre-existing bug I described above they weren't forced to. The theme always installed somehow, and that was good enough for them. Thirty bees, on the other hand, should not be so eager to enforce these API contracts. There should have been some transition period, for example, when big red warning would be displayed during theme installation, informing user that the theme config.xml is not correctly composed. This would (hopefully) force the theme developers to fix their products.

I've moved this discussion to the separate thread, as it has nothing to do with 1.1.1 release.

@lesley are you sure it's a bug in 1.1.x? I believe this was 1.1.0 bug that's already fixed in bleeding edge

Thanks for the zip file, however it did not fixed the issue you have reported. Even with your version, when I refunded only shipping, product tax breakdown was displayed. However, it pointed me towards the fix. It was deployed, you can use core updater and update to branch issue-1116 to test the fix. I did not include the negative/positive sign yet. I'd like to hear opinions of other people first before I commit such a change

The problem is that this presenter does not display (all) data from an existing order. It wants to display only data related to refunded products. In order to do so, it loads the original order, remove all non-refunded products from it, and adjust shipping costs. Then, of course, the totals must be recalculated as well. Because you removed this final step, the order object has become inconsistent - it now contains refunded products, while the totals still represent original/ordered products.