datakick

It's done automatically. System will try to resolve urls without ID using product rewrite. So as long as your product rewrite remains the same, system will be able to perform 301 redirects automatically. For example. url domain.com/en/cat-1/cat-2/cat-3/product-rewrite will be redirected using 301 to domain.com/en/cat-3/cat-9/123/product-rewrite If you change product rewrite from 'product-rewrite' to 'whatever', then the link cease to exists, and original url will return 404. Note that there we are working on a new premium module 404 manager that will give you some tools to map 404 links

That's correct. Thirty bees is not remembering old rewrites. If you are not using id in your urls, then changing rewrite will cause 404. I recommend to always use id in url schema

Email subjects for order status emails are not translatable in the same way as other emails. Thirty bees collects information about email subject by parsing source code, and looking for pattern Mail::Send($languageId, 'email_template', Mail::l('Email Subject')) When it sees such code, it can associate email template 'email_template' with default subject 'Email Subject', and offer translation for it. The important think is that the email_template and Email Subject are literals - constant values. This works for static emails only, the one that are know at the time when developer writes code. For order status that's very different. You can specify which email template should be sent dynamically (edit order status). The code to send email looks like this (using variables) Mail::Send($languageId, $status->template, $status->name); The translation system can't work with that, so nothing is offered for translation. When sending emails for order statuses, order status name is always used as email subject. Bleeding edge (1.6) contains new enhancement that let you have explicit email subject for each order status.

yeah, absolutely. Thanks for bringing this to my attention.

Great that it works for you. If it indeed does, that is 🙂 The worst thing about these kind of caches is that, if something is not working, you might not even know. Because the wrong html data can be served only to a specific segment of your visitors, a segment that you are not part of. And of course, these problems can occur randomly and sporadically. Based on other visitors interactions with the cache.

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.