datakick

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.

Report the issue to the developer and wait for a fixed version. Meanwhile, you can edit file /paygreen/bundles/PGDomain/Services/Managers/ButtonManager.php on line 128 And add null check. But be aware that, most likely, this will only hide some larger underlying problem.

This problem actually looks like an open and shut case. @Traumflug removed code that re-calculates totals in commit https://github.com/thirtybees/thirtybees/commit/e9e3f46ed0cc4ce083e5604595a96c6984f06856. He obviously thought this is redundant, as totals should be already calculated by Order class. That was a wrong assumption. Looks to me that revert of that commit rectifies the situation. Can somebody confirm? You can use core updater to update to branch issue-1116 Note that this does not remove the negative sign, for that one needs to modify the template. I'm not sure that's a bug, though -- in ps17 the amounts are printed as negative as well. But as I said -- I'm no expert in this domain area. So if you guys agree this is a bug, please file an issue for it

I've created an issue for this to not be forgotten https://github.com/thirtybees/thirtybees/issues/1116

I really don't understand this problematic much. I would have to spend few hours trying to understand this domain by reverse-engineering the code. The code that is already broken, evidently. That's not an easy task to do. And it does not guaranteed that I will grasp it correctly. By filing issue (complete with reprosteps, expected, and actual behavior) you would help immensely with this task. That doesn't mean I wouldn't have to reverse-engineer the code, or go back through git history to figure out when things went south. But it would give me some solid starting point And most importantly, forum is not for tracking issue. That's what github is for. If it is not tracked there, it *will be forgotten*

Oh, I'm. I'm supporting thirty bees out of my good heart and my good will. I'm not paid to fix bugs. If nobody is willing to put any effort to actually describe the issue in a way stupid developer like myself can understand it, I'm not going to waste my time to fix it.

I'd be happy to look into this issue, however I need to understand what's wrong first. I don't really know this domain area, so I need somebody to actually explain to me what this is supposed to do. @Occam your screenshots are nice and all, but I also need to know what the expected result are. If you could file an github issue with following: 1) reprosteps - what *exactly* one has to do to reproduce the problem. Ideally on vanilla installation with test data 2) expected results - what should the result look like 3) actual result - I guess your screenshots above should cover that Without an actual bug report there will be no fix

Can anyone point me to the github issue for this one?

I installed the override without any errors or issue, and export seems to work fine. What does not work for your?

Bump - only the last few days before the release

I don't understand. These issues were fixed in Niara, and they will be part of the next 1.1.1 release. Of course, the fix is not applied retroactively to 1.1.0

You will have to ask theme developer to fix it. Most themes (even commercial) are all derived from the same grandfather theme, so they often share the same set of bugs.

@Theo you wrote you hadn't had a problem on other servers. So, maybe, the problems is indeed in this server's configuration. These tests are there for a reason.

Not necessarily. SQL injection, for example, can do the trick as well.

When somebody hacks your site, then can do anything then want. On prestashop, the most common attack vector are badly written modules that allows users to upload some files, but does not check its type. For example, instead of uploading video, user can actaully upload php file, and thus gain complete access to your site. There are, of course, other vulnerabilities. Like sql injections, xss,... Again, they can be in core, or in modules. There is no silver bulet here. This is a catch-up game. That is not normal developement. You should never modify core files. Never ever. If you need modification, use tools designed to do that (overrides, modules, hooks).

I have encoutered similar issue once, but not on front office. When I created order manually in back offce, something went wrong and addresses belonging to two different customers were used. I'm sure at the time I hit save it showed correct address, though... So my question to you is: Are you sure that the order was already wrong at the creation time? Maybe you modified it in back office, and something went wrong from there...

Full Page Cache

I forgot to mention that this comparison tool does not actually report extra columns and tables (it can detect them, but it disregard these differences silently). It only tracks known database objects, anything extra is silently allowed... I have some problems with that as well, though. For example, extra column in core table can be a very serious problem if it is defined as a NOT NULL, and does not have any default value. Client of mine installed a module that created such column + added override for controller to ensure that some value is always passed. But then he disabled this module -- and his shop stopped working, because insert into this table throws mysql exception. Again, it would be best if these kind of modification were described in metadata layer, so core knows how to deal with it. Similarly, extra unique key can cause a lot of issues.

Yes, github is the best for this