datakick

Also, if possible, please contact developer of the module and ask them to adjust their code

The order status is stored in configuration table under the name PAYBYPHONE_OS_CALL. It's likely this settings is exposed in this module configuration page. If not, you will have to change the info in db table directly

Module paybyphone calls core method with invalid order status ID - /modules/paybyphone/controllers/front/validation.php line 46.

you should delete all of those. Take PaymentModule.php file as an example. Thirtybees contain class with this name in /classes/module/PaymentModule.php. When any code want to use PaymentModule class, thirtybees autoloader will scan /classes/* directory and will look for a file named PaymentModule.php. You have two files with the same name - which one will be loaded is undefined. Maybe you will be lucky, and the correct one from /classes/module/PaymentModule will be loaded. In that case, everything is fine, and your system will work OK. But it's also possible that the /classes/PaymentModule.php will be loaded instead. This file probably contains some very old (prestashop 1.6) version of PaymentModule class. Maybe it will work with current tb, maybe not. I don't know. But it's a very dangerous situation. I don't know about cleantalk. I don't know this software, but I would stay clear from any that 'patches' thirtybees core. Thanks. Typical copy and paste issue 🙂

It's not "solved", because there is nothing to solve. I don't consider this to be an issue on module side. This is just the fact of life - different email clients displays emails differently. Some email clients support css, some of them support svg image format. Some of them support external images, some of them supports inline/base64 images. Some of them supports external css files. Some of them supports javascript. Some email clients strips html tags. It almost impossible to have email that contains some advanced functionality (like review starts with hover effect) and expect that this will be displayed in every email client consistently. It is just not possible. The email template that comes with revws module is a compromise. It shows nicely in many clients (for example apple email). But there are those (usually browser based) clients that displays the content stripped. But even here the email is usable, because the template have fallbacks. If you don't like default email template, you can of course edit it and change it to whatever you like.

You can't. It's just not possible to include reviews metadata if you don't have any reviews. Google search console is an idiot in this case. Simply ignore these warnings.

That's a strange number. Maximum length for single tag is 32 characters. There shouldn't be any limit on number of tags one can associate with a product.

I suggest you install my other module called Consistency. It can detect some weird stuff. This one would be detected. There is extra file DbMySQLi.php in classes/db directory. It shouldn't be there. Thirtybees autoload mechanism can load any php file in classes/* directory, and then anything can happen (but nothing good). Like this error here. I suggest you delete this file immediately In free version, you can define two rules. Premium version allows unlimited rules, obviously. Sure thing. You can login to my demo account and test it out. http://demo.getdatakick.com/admin561wkvz9k/ No, it's not error. I don't offer support / development packages at the moment, as I'm nearly 100% utilized. I might offer these services in the future when I'm done with current development project

If you imort email messages via IMAP and have 'Create new threads' option enabled, then support customer threads will be created for every email. That's obviously not wanted behavior for customer messages, as these are generated, and already tracked, in the system. To prevent these extra customer threads, thirtybees add this magic string to subject line. It's a lazy solution, but it works. So to summarize - if you don't use IMAP, or have 'Create new threads' option disabled, you can safely remove it. On a related note - it's not the best idea to edit the core files, or create overrides for them unless necessary. In this case, you can use my conseqs module and create rule that modifies email subject for 'contact' email.

That's why I suggested this solution. I would hate to display this 'essential product features' in the floating Cart block, as it would only distract users. If it really must be displayed, then this new 'Order summary' section would be the right place to do it.

It could look something like this. The format of 'Order summary' would be country specific

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: