datakick

No, it's not possible. These sections are generated by javascript, so you can't just move things around in template. I don't think it is a good idea anyway. The flow is designed as it is to reduce friction and hide irrelevant information when possible (we don't want to scare customers with a lot of fields and information). The Cart block has also functional component -- you can edit items, add coupons, etc... It also shows current amount, which changes when you enter shipping / payment / VAT#. If you moved this Cart block to the bottom of the page, you would totally destroy UX experience and annoy your customers. Much better way to handle this idiotic german law would be to list product information inside 'Confirmation' section just above 'Pay now' button. The listed information would be somewhat redundant to Cart block. But it could also include additional information required by law, like attribute and feature values. That way, Cart section could remain simple and clean, and yet you would be compliant with the law. I think this is the easiest, and also the best solution to tackle this problem. Let me know if this would work for you

Most of my modules can be tested on my demo server: http://demo.getdatakick.com/admin561wkvz9k/index.php?controller=AdminChexBackend&token=daeb0760782c797b4c569212cd8744b1#/settings https://demo.getdatakick.com/en/

It does

Order of the listing? I still don't understand what you want to achieve. In what way does not my module meet the law criteria? Maybe the best way to explain this is if you create a screenshots and mark it directly there.

To tell the truth, this is the one of my worst selling module. The reason is probably that the target audience is tb (and possibly ps16, although I had no sale for this platform). My other modules that run on ps17 sells much better

Thought on what? I still don't understand what you are talking about. If you need the pay button to be the last one on the page, you can move the cart to the top, as I've already answered. If you need the button to say 'Buy now', then use translation. I don't see any other problem

You can disable floating cart and display it on top.

There is no 'Buy now' button, so I guess you mean final payment button? Well, it's already the last button in on the page, so I don't really understand what you want to achieve???

I did some investigation, and this area is pretty fuc*ed up. There is a column total_paid_real in order table that tracks how much money was actually paid. This column has been deprecated for a very long time, because this information is primarily stored inside tb_order_payment table. However, for backwards compatibility reasons, this column is still there, and thirtybees tries to keep it in sync with records in tb_order_payment table. Needless to say, it does this very poorly. The issue I've mentioned in my previous post is just one problem. There are others, for example currency issues. Some code expects this column to be in shop currency, other code expects it to be in order currency, and this can lead to totally wrong amounts (apples and oranges added together) We need to fix this. The first item is to remove all *read* usages of this column from core. Core code should always use data retrieved from tb_order_payment, and not use this deprecated column at all. Then, we should fix all *write* usages, so modules that depends on this column continues to work. Unfortunately, even with all of these, we will still have consistency issues, only not so frequently. It's just not really possible to keep things in sync. For this, we should have some scheduled task that automatically fix the data. https://github.com/thirtybees/thirtybees/issues/1161

I think this issue is directly related to the one fixed recently - https://github.com/thirtybees/thirtybees/issues/1153. You can forward to bleeding edge and test it. Note that the code change will NOT have any effect on already existing orders, as the data are already corrupted in the database. But new orders should display correct payments

Yes, it's possible. But dev experience is required

These kind of issues can be reproduces when you try to install zip file that is NOT a valid module. Sometimes, developers give you zip file that contains another zip file (actual module) + documentation, license keys, etc..... If you try to install this zip file, the content is unzipped into /modules directory, and result is that you have inner zip file inside your module directory instead of module directory. Another common problem is when you download zip from github repository. Github will give you zip that contains one directory named modname_master, instead of modname. Because there is no modname_master/modname_master.php file (there is only modname_master/modname.php file), thirtybees does not recognise this as a valid module, and completely ignores this directory. All these problems can be, and should be, detected during module installation process, and explained to merchants in some user friendly way. This is work in progress 🙂. The module installation process is being redesigned and unified (there will no longer be dependency on tbupdater module). During installation a lot of additional checks will be performed, and module installation will fail if any of these fail. And most importantly, if installation fails, there will be no residuals in /modules directory

Yeah, I was surprised as well. There's no real benefits, only plenty of potential bugs and issues. We should get rid of this 'feature'

@Sigi asked me how to change delimiters in feature value field exported by my datakick module. I've prepared a short video that shows how to do this:

Well, there is no switch for this. You can only remove the invoice from 'Order status change' emails, not from the 'Order confirmation' email. You can submit enhancement request for this on github.

@Chandra you are mixing two things. The settings on Order Statuses has impact on 'Order Status Changed' email only (ie. Awaiting bank wire email) What you are talking about is the 'Order confirmation' email, and that has nothing to do with order status. This email is always sent, and it contains all current information available. I guess we could change the current semantics, and attach invoice to 'Order confirmation' email only if current order status has the send invoice checkbox enabled. However, I'm sure there would be plenty of merchants that would not want this behaviour by default.

You should also install Override Check module to see what overrides are installed on your system

@toplakd the fix for this issue is committed in branch issue-1153. Could you please verify that it works? Simply use core updater and update to this branch

The problem is that total_paid_real column is not adjusted when the order is switched to the order status that 'Pays' the order (generate payment + invoice). Tracked here https://github.com/thirtybees/thirtybees/issues/1153

This directory should always exist -- it's part of thirtybees installation, and it's also part of ps16 installation. If it was missing on your system, you must have deleted this directory somehow. Either manually, or maybe some module did this for you, who knows. There is no code in thirtybees itself that deletes this directory, there is only code that empties its content. Therefore, I don't think this issue was related to your 1.1.x update. It's more likely it was just discovered during the verification process.

@rubben1985 gave me access to his back office, so I had a look at the issue. Indeed there was some weird stuff going on. For example, cache was not flushed when you clicked on Clear cache in Performance tab. My investigation showed that this problem was caused by missing /cache/smarty/cache directory. Recreating this directory using ftp seems to fix the issue (pending confirmation from @rubben1985) Thirtybees codebase never checked existence of this directory, so this issue is hardly 1.1.x injection. But it's an issue nevertheless -- the system should recover from this situation. The fix is already committed in bleeding edge

When shop data are changed there is NO automatic cache flush. Every module must handle this individually -- some of them subscribes to 'actionAfterUpdate*' hooks and use this callback to flush cache. Other modules invalidates cache on time basis - these can display stale information. I don't know how Advances search modules handles cache invalidation. I don't even know what 'Advanced search' module you are referring to, as there are multiple with this same name 🙂 Did you check your smarty cache settings in *all* shop context, as I suggested in my previous post?

Also, since you are using multistore -- ensure your cache settings is consistent across all your shop context, otherwise weird stuff can happen

It's very hard to do this kind of investigation on a live site. Debugging issues locally is very easy and straightforward - I can connect debugger, step through the code, immediately see content of any variables, evaluate test expressions, etc... the whole investigation process can be done in like 5 minutes. And it's safe. Debugging on a live site is completely different beast. I can't connect debugger. The only way I can do is actually edit source code and upload it via ftp. I have to be 100% sure I didn't screw anything before uploading modified files - it's pretty easy to bring down complete website this way. Also, since I don't have access to any variables, I have to print them to the page somehow. Of course, I don't want your regular visitors to see these, so I have to make this debug printing conditional to my session only. And there are the thing about encoding php values to string for debugging purposes. This tedious process can take hours, and is extremely dangerous. I would love to help, but I don't have hours to spend on this. Also, you are the only one who complained about this so far. So it can be something specific to your store only. I'm not going to invest any more time investigating this issue. Not until someone can reproduce this problem on vanilla thirtybees, and provide reprosteps.

Oh, but there were no demands on third party developers. I'm just saying that I've exhausted all resources - I've tested extensively, and failed to reproduce this issue. Unless somebody provides reprosteps there is nothing I can do further.