datakick

This error message is a stop-gag measure to prevent leaking information between accounts. Information can leak when you have some sort of cache (can be anything - caching module, build in thirty bees FPC, litespeed server cache,... ) that is incorrectly configured. When customer B request the same page, the cache can return html content originally rendered for customer A -- this html can contain personal information about customer A, including his address. There are other possible reasons for this message to appear. For example, if you have some shipping module that is using the same addresses to calculate shipping costs.

Do you have any full page cache enabled? Looks to me like your server is displaying HTML content that was generated for different user.

Yes, that will be most likely the problem. Most payment modules implement both approaches -- displayPayment and displayPaymentEU. The first one is the older approach, and simply emits HTML code with all payment functionality into a page. And the expectation is that the page to be standard checkout page. This is very easy and convenient for developers, but it's very "hardcoded". It works on standard (or slightly modified) checkout page only. The displayPaymentEU approach is a declarative approach. Instead of emitting HTML, the module describe what is needed to do in order to process payment. And it's responsibility of checkout page to display the HTML and call the payment functions when needed. This makes it very easy to switch between checkout pages. Seems like your modules implemented the old approach only

you look not only for errors, but also for serious warnings. These warnings can raise errors on higher versions of PHP. Look at the fix for this issue in niara theme, and adapt it to your theme: https://github.com/thirtybees/niara/commit/1f9629157606620748b3b5e769d621d9ccdfc751

Your theme is not php8 compatible. You should downgrade to php7.4, install collectlogs module, and fix all (serious) warnings it detects. Only then it is safe to update your store to php8

The migration was probably not complete, some files were not updated to thirty bees version. This could happen, for example, because of invalid file permissions (not writable). Or the migration failed prematurely? The AdminController file should look like this in thirty bees 1.0.8: https://github.com/thirtybees/thirtybees/blob/3880cede3367177640e1ffbe0e7a7f8ffd8d5396/classes/controller/AdminController.php There is no mention of CACHE_FILE_DEFAULT_COUNTRY_MODULES_LIST at all. I suggest you download zip file of thirty bees 1.0.8 and use it to overwrite your installation (ignore install directory, and make sure you upload admin directory to proper location)

I currently run my store on mariadb 11.1.3. It runs smoothly. I updated recently from mariadb 10.6. I haven't seen any performance or other benefits after update to 11, though.

The revws module does not care about how the order was created. It just looks into database to check if the consent was given or not. Note that consent is not per order, but per customer. In this case, your customer probably gave consent when they registered, or during one of their purchase. The only thing that comes to mind is to use dedicated order status for back office orders

Do you mean like infinite scroll ? I'm sure there are couple of modules for ps16 that implements this functionality.

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