datakick

It's not commented out. If you beautify the result content, you will get this /* <![CDATA[ */ ;window.addEventListener('load', function () { if (typeof window.cookieconsent !== 'undefined') { window.cookieconsent.initialise({ "position": "bottom-right", "static": false, "theme": "edgeless", "palette": { "popup": {"background": "#004c99", "text": "#ffffff"}, "button": {"background": "#f1d600", "text": "#000000"} }, "geoip": false, "content": {"message": SOME MESSAGE FROM THE COOKIE MODULE} }); } }); ;window.dataLayer = window.dataLayer || []; function gtag() { dataLayer.push(arguments); } gtag('js', new Date()); gtag('config', 'G-R6CE3JK4G6'); ;(function () { function s() { var e = document.createElement('script'); e.type = 'text/javascript'; e.async = true; e.src = ('https:' === document.location.protocol ? 'https://' : 'http://') + 'cdn.fraudlabspro.com/s.js'; var s = document.getElementsByTagName('script')[0]; s.parentNode.insertBefore(e, s); } (window.attachEvent) ? window.attachEvent('onload', s) : window.addEventListener('load', s, false); })(); /* ]]> */ The all comments are closed. There is, however, syntax error in this javascript snippet, related to text SOME MESSAGE FROM THE COOKIE MODULE

Note: if you don't see core updater in the list of modules, you probably don't have tbupdater module installed. This module used to be used to download other thirty bees modules. Since 1.5, it is no longer needed. But on older tb version you still need it. You can easily install core updater from github repository - https://github.com/thirtybees/coreupdater/releases , and then update to 1.5.

I've already replied in the other thread you have created for this very same problem.

Unfortunately it's quite common that CSS or JS from one module impacts other modules. If you are using CCC, try to disable it -- sometimes that helps. If it won't help, then you look into your browser console, look for any errors or warnings.

This indeed looks like your hosting provided changed PHP version of your store. You are running on older version of thirty bees (error lines suggests version 1.1.0, or maybe older) that is not compatible with PHP 8, or even PHP7.4 You should either downgrade your PHP version back to what you were using before (my guess would be php7.2, but who knows), or update your store to newer version of thirty bees and take advantages of new PHP version.

What payment method did you try to set up?

Hello, could you please retry again? There was old inactive paypal subscription associated with your account that blocked the process.

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