datakick

I've re-tested with your numbers and it works fine for me. I guess this is either theme issue, or you are using old thirtybees version.

data inconsistency in database. You can download my consistency check module, that might help you fix it

I can't reproduce this issue. Could you please provide some screenshots, both from the admin and frontend? Note that this might be theme issue

The module might appeared to work on ps16, but only because you probably run on lower version of php. But the problem was always there. New php versions are just more strict and complain louder. Anyway, this is not critical issue. The code still works, php just complains. You can disable debug mode and it will be 'fixed'. Alternatively, you can search for all occurrences of $currency->sign % 2 in this module *.tpl files, and replace them with $currency->sign

I've seen this one. This module have some very strange code in its templates. For example: {if $currency->sign % 2}...{/if} The modulo (%) operator returns the remainder after division operation. If the 'sign' variable contained integer number, it would be ok. The result would always be either 0 or 1. However, the 'sign' variable in currency object does not contains number, it contains currency symbol. Such as € or $. Now, I'm not mathematician, but I guess expressions like € % 2 are not really valid. Thus the error code. Contact the module developer and ask them to fix it.

also check position of 'displayPaymentEU' hook

ps_carrier table has nothing to do with your issue

This module is not compatible with new versions of *Smarty*, and in extension with thirtybees 1.1.0. You need to ask its developer for help.

The reason is clear - database table ps_module_carrier is missing. You need to recreate it, and then associate your payment modules with carriers. CREATE TABLE `ps_module_carrier` ( `id_module` int(11) unsigned NOT NULL, `id_shop` int(11) unsigned NOT NULL DEFAULT '1', `id_reference` int(11) NOT NULL ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; I wonder how you managed to delete this table in the first place. Also -- if possible, update to 1.1.x. Core updater would detect this critical issue and fixed it automatically for you during update.

what do you mean "validate" ?

Well, it's both bug in the module and compatibility issue. After order is created, mollie updates its price to include fee: $order->total_paid_tax_excl = $orderFeeNumber->plus( new Number((string) $order->total_paid_tax_excl)); $order->total_paid_tax_incl = $orderFeeNumber->plus( new Number((string) $order->total_paid_tax_incl)); The result of this operation is not a number, but object of type \PrestaShop\Decimal\Number When $order is saved, thirtybees calls standard php function round: round($value, _TB_PRICE_DATABASE_PRECISION_); Because the $value is object and not the number, this function return 1. Don't ask me why, it just does. PHP. In prestashop 1.6 there was different code: (float) str_replace(',', '.', $value); Because str_replace expects $value to be string, it calls $value->__toString() internally, which results in converting object to string. And thats the reason why the module works on prestashop. Pure luck. The fix should be done on both sides, I guess. In module, the lines should be replaced with $order->total_paid_tax_excl = (string) $orderFeeNumber->plus( new Number((string) $order->total_paid_tax_excl)); $order->total_paid_tax_incl = (string) $orderFeeNumber->plus( new Number((string) $order->total_paid_tax_incl)); Note the cast to string. This cast to string is enough to fix the issue. I have created a pull request for this change: https://github.com/mollie/PrestaShop/pull/232 Thirtybees core should be modified as well. Method ObjectModel::formatValue should check value and perform conversion if input it's not number or string

Where is such field?

look into server error logs look into thirtybees logs in /logs directory also, what curl version do you have?

Works for me. For example https://demo.getdatakick.com/en/module/revws/EmailAction?id=202&action=review&product-id=3&rating=5&secret=701dd91582bb679d998cc19d402653e6

Default values for fields are not supported at the moment, they will be in the next version. Also - if you have visitors from EU then your site have to be GDPR compliant. The fact that you are from non-eu country does not absolve you from the responsibility. Granted, you will probably never be sued or fined, but you could be.

It's not an error, it's notice. Already fixed, upgrade to 1.1.x

No

There are many things that could be wrong. You need to look into the code, follow the flow, and print debug messages along the way. That will lead you to the root cause Yes. Datakick contains xml import functionality that can be used for that purpose

Than do the same with this override file as well: override/classes/pdf/PDF.php Module gwadvancedinvoice installed a couple of overrides. These overrides should be automatically removed when you uninstall the module. I guess you just deleted the module instead of uninstallation. Or the uninstallation process failed. Anyway, your system is now in pretty inconsistent state. You can use 'overridecheck' module to find overrides not associated with any modules, and delete them. You can also install my 'consistency check' module, that will probably detect few issues and help you get rid of them.

Looks like the database migration completed properly. That's a good thing. You can download thirtybees zip and unzip it to your store. Don't forget to remove install directory, and rename admin directory. That should put you into working state. Then install core updater module, and perform clean update to 1.1.0 (or preferably to 1.1.x).

- migration modules is not complaining about owner/group, but about permissions. Check these files, and make them writeable. - zip - your php server is missing zip extension. https://anto.online/code/how-to-enable-ziparchive-for-php/

You should put debug in various place to figure out what's wrong. I would start by changing copyFromPost, and adding something like this ... d(['ext_warehouse' => Tools::getValue('ext_warehouse')]); $object->ext_warehouse = (int) Tools::getValue( 'ext_warehouse' ); ... i

Works fine for me. I've tested on 1.1.x. Looks like you have something extra on your prod store. You'll need to debug

Transferring site is not only about copying files, it's also about database changes. In this case, I believe that you don't have installed/enabled module statsdata that is responsible for data collection.

You need to call parent constructor in your override file. It should look something like this class Product extends ProductCore { public $ext_warehouse = false; function __construct( $id_product = null, $full = false, $id_lang = null, $id_shop = null, Context $context = null ) { static::$definition['fields']['ext_warehouse'] = array('type' => self::TYPE_BOOL, 'lang' => false, 'validate' => 'isBool'); parent::__construct($id_product, $full, $id_lang, $id_shop, $context); } } Also, you need to create the field in database table, but I guess you already did that.