datakick

You should use FPC, or Litespeed cache (or any other mechanism that cache generated html cache) only if you have very, very, very static store. Otherwise you will encounter a lot of weird issues and problems. Few examples: 1) you can have a module that gives your customers free shipping after for orders over $200. If your customer sees cached page generated for different visitor, they may or may not see this free shipping in their cart. What's worse, this information can change as they browse your site, as every page was cached in other context. 2) my revws module allows guest reviews, but still prevents creating multiple reviews by single visitor. On the product page, the module emits information if the current visitor is allowed to create review or not. Again, with cache enabled, this information will be for different visitor (when cache is hit). The javascript will allow the visitor to create review, but the backend will reject it later. Or, the javascript will block visitor from creating the review, claiming they already wrote one, even though they didn't. Of course, FPC allows you to specify that some hooks are dynamic, and force system to them to always re-populate portion of the html data. But it's very hard to set this up correctly, because nobody knows what hook depends on. To be sure, you would have to look into source code of every module. So, to have this set up properly requires a lot of testing, tweaking, and accepting that there will be corner cases when the system will just malfunction. I would never advice anyone to use these kind of caches. At least not before they exhaust other options (like smarty cache stored in redis or memcached)

That's actually already part of the module. You can choose if you want to display markup, margin, or both in config page.

You are probably using old tb version that contained a bug. If so, update to 1.5

I don't like google company much as well, but that's not a reason to not using *open* image format developed by them. Especially when it's as good as webp. I did a quick stats on my store for my product images. I don't have many images, and those that I have are mostly screenshots of module config pages. So the statistic is definitely biased. Nevertheless, the result are very nice: Total images: 576 Total size of jpg version: 6074191 total size of webp version: 3140802 That's roughly 50% less.

We have just released new premium module named Price Margin. This is very simple yet powerful module to add additional input fields Profit, Margin, and Markup to your product price tab. Using these fields, you can quickly see what your profit margin is, and adjust it accordingly. In module settings page you can choose which one of them you want to display In the future, this module may contain additional functionality list of all products displaying profit margin information mass update of products price If you have any other suggestions, let us know. Enjoy, and thanks for being thirty bees supporters!

I believe that you have wrong data in your orders table select concat('|', concat(module, '|')) from tb_orders where module like '% %'; the column module should not contain space. If the sql above returns some rows, you have data problem. If that's the case, you can probably fix it by update tb_orders set module = trim(module);

I can't reproduce this. Installation both via UI and via CLI works, and BO admin user has expected credentials.

I don't think this is caused by custom payments module. You either have some payment module named 'pay30days ' - with trailing space. Or you had such module installed in the past, and the name made it to orders table, column 'module'. Or maybe you have imported orders data?

thirty bees dashactivity module latest version is 1.4.1, not 6.0.2 -- that is probably not native module https://github.com/thirtybees/dashactivity/tags

This is probably caused by locks. During processing, every schedule is locked, so it is not picked for execution by different scheduler instances. In theory, the lock should be removed, because there is finally block in the code lock() try { processSchedule(); } finally { unlock(); } However, is some rare situations, PHP code is non-gracefully terminated, and finally block is never executed. For example, when php server is restarted, or when memory is exhausted. If that happen, the schedule is locked forever. You can execute this sql to fix it UPDATE tb_datakick_schedule SET processing = null; Upcoming version of datakick module comes with a fix for this situation.

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.