datakick

Do you have latest module versions?

You need coreupdater module installed to be able to update your store. You don't need tbupdater module anymore, though.

What you mean by "maybe by email address" ? If the importer order has some sort of 'amazon' email address, you could use my conseqs module to block sending emails. You can use Before email is sent trigger + conditions + Prevent sending email action. Condition can be based on email type + recipient email address

This will be in some module. Most likely in hookHeader function. Look for code like this $controller->addJS('https://unpkg.com/sweetalert/dist/sweetalert.min.js'); Context::getContext()->controller->addJS('https://unpkg.com/sweetalert/dist/sweetalert.min.js'); $this->context->controller->addJS('https://unpkg.com/sweetalert/dist/sweetalert.min.js'); If you have ssh access to your server, you can use find/grep to quickly find the code. If you have only ftp access, you will have to check every module one by one.

Hi, the first thing is easy. You can use if(<cond>, <truth>, <false>) expression to only emit content of sale_price when it's different to base price. Something like this if(productPrice(combination.productId, combination.id, false) != (combination.productBasePrice + combination.priceImpact), toString(productPrice(combination.productId, combination.id, false)), '') This will display empty string if the both prices are the same. You can then check "Omit empty" checkbox on <g:sale_price> to hide it if empty. The second problem is not possible to solve with datakick module, I'm afraid. There is no function that would calculate base price for specific price for given country.

Yes, that means our security fix works properly and as designed. For security reasons, thirty bees 1.5 makes HMAC-SHA256 signature of employee security-critical fields (Employee ID, Permission profile ID, Email, Password) and stores this signature inside new column database signature. If somebody changes any of these fields externally, without re-calculating signature, the employee record will be invalid. The reason behind this change is to prevent elevation of (possible) SQL injections vulnerabilities into absolute access to the system. Imagine your system contains some SQL Injection vulnerability (we don't know about any in core or native modules, but we know about lot in third party modules). Attacker could use such vulnerability to change password and email of any employee, or even insert a new super-admin employee into database. Then, attacker can simply login to back office with full access privileges. SQL Injection vulnerability itself is absolutely critical problem, of course. But giving attacker back office admin access is much worse - because attacker is able to install custom module, and therefore execute arbitrary PHP scripts. This employee signature block this. You should create employees account them in standard way (back office or via webservice).

For <g:price> use base product base price + combination impact. Datakick expression for this is (if your combination table has combination alias) combination.productBasePrice + combination.priceImpact for <g:sale_price> use function productPrice(productId, combinationId). Expression is: productPrice(combination.productId, combination.id, false) Function productPrice calculates final price for given target audience (customer group, currency, country), and it does take into account all discounts and specific prices. In my test, I've created shop-wide specific price rule that gives 10% discount, result is this: Here is attached template in json format, you can import it to your datakick installation for testing test-prices.json

You can edit module code and provide %total% placeholder as non-formatted amount instead of formatted with currency symbol. Change Tools::displayPrice($cart->getOrderTotal(true, Cart::BOTH)) with $cart->getOrderTotal(true, Cart::BOTH) in file /modules/custompayments/custompayments.php There are two places in the file where you should make the changes: https://github.com/thirtybees/custompayments/blob/b281c5178a9869be3c13b228281715dd6e38ec6b/custompayments.php#L310 https://github.com/thirtybees/custompayments/blob/b281c5178a9869be3c13b228281715dd6e38ec6b/custompayments.php#L456

Happy to help. There is a feature in backlog for coreupdater module to detect expected database differences, and automatically migrate these during update. Hopefully soon.

These can be safely removed - remnants of core functionality that is no longer used. No idea, probably some module columns. Try to search in modules and overrides directory for these column names. If nothing comes up, you can probably safe to remove them. If these columns have some default value, then it's also safe to keep them in the database table. If they don't have default value, then they can cause troubles during data insertion. You can check for by looking at tb structure: show create table tb_orders; outputs something like CREATE TABLE `tb_orders` ( `id_order` int unsigned NOT NULL AUTO_INCREMENT, `reference` varchar(9) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL, `id_shop_group` int unsigned NOT NULL DEFAULT '1', `id_shop` int unsigned NOT NULL DEFAULT '1', `id_carrier` int unsigned NOT NULL, `id_lang` int unsigned NOT NULL, `id_customer` int unsigned NOT NULL, `id_cart` int unsigned NOT NULL, `id_currency` int unsigned NOT NULL, `id_address_delivery` int unsigned NOT NULL, `id_address_invoice` int unsigned NOT NULL, `current_state` int unsigned NOT NULL, `secure_key` varchar(32) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL DEFAULT '-1', `payment` varchar(255) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL, `conversion_rate` decimal(13,6) NOT NULL DEFAULT '1.000000', `module` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL, `recyclable` tinyint unsigned NOT NULL DEFAULT '0', `gift` tinyint unsigned NOT NULL DEFAULT '0', `gift_message` text CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci, `mobile_theme` tinyint(1) NOT NULL DEFAULT '0', `shipping_number` varchar(64) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci DEFAULT NULL, `total_discounts` decimal(20,6) NOT NULL DEFAULT '0.000000', `total_discounts_tax_incl` decimal(20,6) NOT NULL DEFAULT '0.000000', `total_discounts_tax_excl` decimal(20,6) NOT NULL DEFAULT '0.000000', `total_paid` decimal(20,6) NOT NULL DEFAULT '0.000000', `total_paid_tax_incl` decimal(20,6) NOT NULL DEFAULT '0.000000', `total_paid_tax_excl` decimal(20,6) NOT NULL DEFAULT '0.000000', `total_paid_real` decimal(20,6) NOT NULL DEFAULT '0.000000', `total_products` decimal(20,6) NOT NULL DEFAULT '0.000000', `total_products_wt` decimal(20,6) NOT NULL DEFAULT '0.000000', `total_shipping` decimal(20,6) NOT NULL DEFAULT '0.000000', `total_shipping_tax_incl` decimal(20,6) NOT NULL DEFAULT '0.000000', `total_shipping_tax_excl` decimal(20,6) NOT NULL DEFAULT '0.000000', `carrier_tax_rate` decimal(10,3) NOT NULL DEFAULT '0.000', `total_wrapping` decimal(20,6) NOT NULL DEFAULT '0.000000', `total_wrapping_tax_incl` decimal(20,6) NOT NULL DEFAULT '0.000000', `total_wrapping_tax_excl` decimal(20,6) NOT NULL DEFAULT '0.000000', `round_mode` tinyint(1) NOT NULL DEFAULT '2', `round_type` tinyint(1) NOT NULL DEFAULT '1', `invoice_number` int unsigned NOT NULL DEFAULT '0', `delivery_number` int unsigned NOT NULL DEFAULT '0', `invoice_date` datetime NOT NULL, `delivery_date` datetime NOT NULL, `valid` int unsigned NOT NULL DEFAULT '0', `date_add` datetime NOT NULL, `date_upd` datetime NOT NULL, PRIMARY KEY (`id_order`), KEY `current_state` (`current_state`), KEY `date_add` (`date_add`), KEY `id_address_delivery` (`id_address_delivery`), KEY `id_address_invoice` (`id_address_invoice`), KEY `id_carrier` (`id_carrier`), KEY `id_cart` (`id_cart`), KEY `id_currency` (`id_currency`), KEY `id_customer` (`id_customer`), KEY `id_lang` (`id_lang`), KEY `id_shop` (`id_shop`), KEY `id_shop_group` (`id_shop_group`), KEY `invoice_number` (`invoice_number`), KEY `reference` (`reference`) ) ENGINE=InnoDB AUTO_INCREMENT=7 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci As long as there is DEFAULT at the column definition, it's fine.

MariaDB 5.5 is old, support ended 3.5 years ago: https://endoflife.date/mariadb. I suggest you update to MariaDB 10

There were a lot of security fixes in 1.5 that closed a lot of holes in the system. A lot of those are relevant for both ps16 and thirty bees, some are thirty bees specific. Some were in modules, some were in back office only, and some were in front office. Commits in github are kind of a disclosure. Anybody can look and see what was fixed. And anybody can use this information to attack sites running older versions. I don't know about your experience, but my store is hammered daily by hacking scripts looking for vulnerabilities. Some of those scripts are blind, some of them are not.

This is funny. How does this "Premium stuff" affect you? Is your OCD acting up because there is a new button in bottom right corner, in a place that was unused before? Well, add 3 line of CSS to your admin override css file to hide it. Are you mad that there is a new "Premium modules" section in modules overview? Is it so hard to ignore it? Do the other uninstalled, but free, modules in the list trigger you in the same way? If this bother you, kindly create PR request that adds setting option to hide these extra modules. I promise you we will merge it. I just won't waste my time implementing something like that because I don't need it, and I have a lot more pressing issues on hand. On both 1.4 and 1.5 you have access to the same list of free native modules. Updating to 1.5 will not hinder your options at all. Yet it will give you a lot of bugfixes, performance improvements, security fixes, and couple of new features for free. And if you opt to become supporter, you will get access to a lot of interesting modules as well. This is strictly optional, nobody is forcing you to do anything. If you stay on 1.4 you should be fine for now. Just don't update your PHP versions. And be prepared that over the time you will loose access to free modules updates, as the new versions will be using functionality from the core not available in 1.4. And I strongly suggest you at least cherry pick all the security related commits from the 1.5 version. Or you store will be hacked.

It really depends on what kind of bot that is. It can indeed be some regular bot - if that's the case, then update to 1.5 may help a little. This version contains up-to-date database of know bots (https://github.com/JayBizzle/Crawler-Detect) and ignores request from them. More likely though, this is some sort of hacking attempt.

They are basically the same themes, the difference being mostly in CSS (and some small html tweaks). The same commits can be applied (usually) to both themes, so there is not much overhead in maintaining both of them.

Both are supported. All fixes are pushed to both themes

What mysql server version are you using? It will probably be quite outdated

PM me access to your back office, I can investigate

No, you can connect multiple installations to your account, and you can use premium modules on all of them.

If you want to import product supplier information, and if you are on tb1.5, you can use my free module https://store.getdatakick.com/en/free-stuff/import-product-supplier This module does not perform the import itself. It simply registers new CSV import entity Product Supplier. Standard thirty bees CSV Import will see this entity type and can work with it. New version of the module also supports two new fields Supplier Product Name and Additional comments.

This functionality is now in bleeding edge. You can now set custom email subjects for your order statuses

You need to look into error logs (collectlogs module) to find out if there is any error. It may be caused by override, module, or whatnot. I personally can't reproduce this issue, and I do sell virtual products.

This is new bug in 1.5 (the customizable one) -- tracked here https://github.com/thirtybees/thirtybees/issues/1730 Thanks for reporting it. I've fixed it already, and will push the fix to bleeding edbe and 1.5.x branch

This is very common problem with a lot of older modules. When you see this error (on PHP8) or warning (on PHP7), then replace key_exists($key, $this) array_key_exists($key, $this) with property_exists($this, $key) The first two functions can be used with array only. If object is passed instead, older versions of PHP converted this object to array automatically (silently, or with warning). PHP8 do not do this automatic conversion, and fails instead.

I looked into logs, and it looks like your site isn't reachable from our accounts server. Your site renders some sort of captcha/challenge, which blocks integration.