datakick

This is related to MAX_JOIN_SIZE configuration variable in mysql server. From documentations: If the max_join_size variable (also called sql_max_join_size) is set, then it will limit any SELECT statements that probably need to examine more than MAX_JOIN_SIZE rows. This means that database server (during preparation stage) will estimate how many rows it will need to process (based on table statistics). If the estimate is above threshold, it will refuse to execute the query. This is set on some shared hostings to achieve some kind of fair usage between all users. Sometimes we can indeed optimize the query, or create a new db indexes so the join space is not so huge. But sometimes its just not possible. I still maintain that this is stupid and dangerous practice by hosting providers. This can kill any sql query, and therefore cause a lot of 500 error pages. Ecommerce store should not run on such hosting.

There is a potential workaround here. You can set SQL_BIG_SELECTS variable for a database session. That should allow you to bypass the error (may or may not work, depending on your hosting configuration) Create a new override override/classes/db/Db.php with this content: <?php class Db extends DbCore { /** * This override allows complex queries to run on shared hosting */ public function connect() { $link = parent::connect(); $link->exec('SET SQL_BIG_SELECTS = 1'); return $link; } } Then clear cache in Advanced Parameters > Performance to reload the overrides

Well sure, you can remove old data, it will reduce the number of rows db have to examine. But still, the root cause of the issue is that your hosting is throttling your database. We send them valid sql request, and they may or may not return results. This is just stupid. Who knows what other sql queries they will kill randomly. This "fair usage mechanism" can cost you sales. But that's sharing hosting. You can always move to a dedicated hosting without such restrictions

This is your hosting restrictions. You are probably on a shared hosting, and they have enabled this restriction to ensure fair usage for all customers. Ask them if they can disable this.

Oh, I didn't even noticed this was ps16. Yeah, Alex, you should thoroughly test your store, because this will not be the only problem. If possible, downgrade your php version. Or even better, migrate to thirtybees.

Hi Alex, did you install some new module, or changed you PHP version recently? Anyway, this issue is caused by an override. You need to edit file /override/controllers/admin/AdminLoginController.php and replace code public function viewAccess() with public function viewAccess($disable = false) That should do the trick

I checked the code, and revws module only supports jpg files. Which was ok in the past, but now when you can have your product images in webp or other formats, it can cause troubles. If your store uses webp images, edit file modules/revws/controllers/front/EmailAction.php and change lines private function getImage(RevwsEmail $email) { $email->markOpened(); $imageId = (int)$this->getValueOrThrow('image-id'); $type = $this->getImageType(); $file = _PS_PROD_IMG_DIR_ . Image::getImgFolderStatic($imageId) . $imageId . $type . ".jpg"; if (!file_exists($file)) { $file = _PS_PROD_IMG_DIR_ . Image::getImgFolderStatic($imageId) . $imageId . ".jpg"; } to private function getImage(RevwsEmail $email) { $email->markOpened(); $imageId = (int)$this->getValueOrThrow('image-id'); $type = $this->getImageType(); $file = _PS_PROD_IMG_DIR_ . Image::getImgFolderStatic($imageId) . $imageId . $type . ".webp"; if (!file_exists($file)) { $file = _PS_PROD_IMG_DIR_ . Image::getImgFolderStatic($imageId) . $imageId . ".webp"; } I will fix this in next version of module

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.