datakick

check table tb_shop_url

@Rhapsody please file this enhancement requests on module github: https://github.com/thirtybees/tbphpmailer/issues

If you are on a bleeding edge, there is a new method Dispatcher::resolveController. We use it in tbshortcodes module for the similar purpose -- to translate internal links to shortcodes. Note that that method has side effects (which I will hopefully fix in the future if I have time) -- it modifies global $_POST and $_GET variables. So when using that method, you should save and restore it later. I'm using it like this: $savePost = $_POST; $saveGet = $_GET; try { $_GET = []; $_POST = []; $controller = strtolower((string)Dispatcher::getInstance()->resolveController($shopId, $requestUri)); $entityId = (int)($_GET['id_' . $controller] ?? 0); // $_GET and $_POST can contain other useful information extracted from request uri } finally { $_GET = $saveGet; $_POST = $savePost; }

Unfortunately there is none reliable method. Thirty bees / prestashop have no idea what database changes module performed, or where it stores its data. It's module responsibility to clean after themselves. And lot of them is doing poor job at that.

No

You can create conditions to restrict the dataset. In left panel click on Dataset, and then on Add Condition button. Set any condition you need. In the right panel you see all the products that match the condition (and that will be mass updated). You also see the preview of what mass update will perform (in the [new] column). In my example, I replaced text 'support' with 'premium support' using this expression replace(product.longDescription, 'support', 'premium support')

Of course. Thirty bees is regular PHP app, and as such it does not concern itself with multi-threading. It's responsibility of application servers (apache / php-fpm / litespeed) to provide multi-threading support, and of course they all do that properly.

Hi everyone, we have just released thirtybees 1.5.1. This is just bugfix release that addresses new bugs introduced in version 1.5.0. If you are running your store on stable 1.5.0 you are advised to update. If you are running your store on bleeding edge (1.6.0), no action is required. These bug fixes are already part of bleeding edge as well.

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.