datakick

with a busy store that's quite hard to do, though. We have an installation with average of 1M daily requests, that's hard to comb though manually. You can install some software to detect anomalies, but that's it. When you find an infection on your store, you know from the file modification date when it happen (unless the script changed it, but in my experience they rarely do), so that can help a lot. You just need to detect it and still have access logs

Yes, if this code exists in your tpl files, it means your store is already infected. But the fact that it isn't present doesn't mean your store is not vulnerable to this attack. We don't know about any vulnerability in the core that would allow attacker to modify/write to tpl files. We regularly check CVE database for prestashop vulnerabilities, and look for those that are relevant to ps16 codebase (so they are relevant to us, most likely). Again, that doesn't mean that they don't exists, we just don't know about any at the moment. But there were some that we have fixed in the past - running very old thirty bees versions is not encouraged. Most of the time the culprits are third party modules, usually those that allow uploading files (images usually) and do not properly sanitise inputs. That may allow attacker to upload php files instead of image, and then they have complete access to your entire store. Thankfully, you can use core updater module to check if any of the core files have been modified. If your store is infected, you will see it there as well. If your store is infected, it's not enough to just remove the infection. You need to find out the back door that was used to install the infection. That can be quite hard. Your server access logs can help a lot, so keep a few months of them if you can.

They didn't disclose attack vector - we don't know how those shops were infected with this malware. Without that information we can't really say if thirty bees is affected or not.

No need to fix anything, this is merely a notice for developers to investigate the surrounding logic. And we did that 🙂 With or without the fix, the end result is the same - nothing actually happens when the object (cart) is not already saved in the database.

You can safely ignore this. This was already fixed in bleeding edge, see comit https://github.com/thirtybees/thirtybees/commit/3c8447874a71825a1561fb2edb5371ee8249375b

Column `minute` was added to the module in version 2.1.0, see upgrade script for that version: https://github.com/thirtybees/cronjobs/blob/master/upgrade/upgrade-2.1.0.php Most likely the upgrade script was not correctly applied when you upgraded the module -- your cronjobs module is not working properly right now. You need to either apply the upgrade script manually, or uninstall and install it again

That's not error from datakick module, but from cronjob module. Looks like you didn't updated that module correctly - column 'minute' is missing from ps_cronjobs table. I suggest you re-install that module to fix this problem, or manually add the column to db table. Then reinstall datakick module again

There is no redirect. Javascript code simply changes the url (removing ?combination=xxx and replacing it with # hash parameters), but the page is not actually reloaded.

Parameters behind # are for client use only. Request to the server never contains those parameters, server never sees them and can't react to them. When you open urls https://www.example.com/en/products/84/sample-product#/72-size-large or https://www.example.com/en/products/84/sample-product#/whatever your server receive the very same request - https://www.example.com/en/products/84/sample-product It does not know what combination you are requesting. Javascript will later parse the hash parameters, and will modify the product page to display the wanted combination if it's found. This also means that initial page render shows different combination, and only a few milliseconds later the page is 'adjusted' When you provide ?combination=xxx parameter, server knows upfront what you want to display, and can returns page with combination already selected (if your theme supports this, of course). The page already contains correct pricing information, product name, reference code etc -- this is important for web crawlers. This means that you need to provide urls with standard query parameters (after ?) to google

What geolocation module are you using?

Yeah, it's a bug in core. You can reproduce it even without clicking on Cron link, simply by updating currency rates in single shop context. I've created an issue on github: https://github.com/thirtybees/thirtybees/issues/2073

Don't think so, they are mostly the same, just few minor styling changes between them

I was mistaken, niara do not hide images not associated with selected combination. It only shows combination cover image. However, it's not complicated to implement this. You need to modify file themes/niara/js/product.js - search for function refreshProductImages and add hiding/showing logic for images

What theme do you use? This is, ultimately, theme responsibility. Core only provides information about images and their associations with combinations to theme. What theme decides to do with those informations is up to theme. I believe that standard thirty bees themes do implement this image hiding. But only if the combination have at least one image associated

this is a known issue with switftmailer - on some php versions it do not work properly. Install tbphpmailer module and use it as you mail transport