datakick

there is no information at all about the actual vulnerability, so we can't tell if tb is affected or not. All we know is that the ps16/ps17 is vulnerable to some attack if mysql smarty cache is enabled. Most stores are using filesystem cache

Thanks for confirming. This issue was caused by compatibility change in one of the core method. Product::getAttributesResume now returns empty array instead of false, when product has no combinations. In this case it causes problem, because of the incorrect check of return type. I believe the best is to fix this in the module. Still, as this is backwards compatibility change, we should track it. I will create github issue for it

It can't, if you made the change correctly. Make sure you are using some text editor that does not include special/invisible characters, and does not do some automatic replace. Some editors can replace ' with ", etc. The code posted above is 100% correct

It's possible. try to edit this line in module: https://github.com/dim00z/gshoppingflux/blob/8974d629216d7a4d451369a4c84676f28988d4d7/gshoppingflux/gshoppingflux.php#L2236 and change it from if (is_array($attributesResume) > 0 && $this->module_conf['export_attributes'] == 1) { to if ($attributesResume && $this->module_conf['export_attributes'] == 1) {

Unfortunately, that is expected behaviour. We have different builds for different php versions. The reason is that some third party libraries are not supported on all php versions tb supports. For example, smarty v4.1 runs only on php 7.1 and newer. There exists different version of that library - 3.1.45 - that runs on php7.0 but have issues on php8. Hence the different builds for different php versions. Unfortunately, libs designed for php8 contains syntax or languate features that are not available in php7. So downgrading php version is not a good idea. There is a workaround - in cire updater settings you can select php version, and core updater will install code for that particular php version. So, while on PHP8 you can update your store to code designed for PHP7.4, and then downgrade. However, weird side effects can happen.

any admin templates override installed?

Nope, just a couple of Deprecation warnings. Your module code contains some syntax that newer PHP does not like so much, but it still tolerates it.

What is the reason your current module stopped working? Did it use override?

Check blockcart.tpl in your theme. It probably uses some smarty variable that is not defined in core / module(s)

For product to be indexed, it must have visibility set to Search or Everywhere must be Enabled (in shop context) must be associated with given shop (in case of multistore)

Any javascript errors in console?

Have you tried blackhole for bad bots module? Might help. If you know the IP address upfront, you can also pre-populate the blacklist: INSERT INTO tb_blackholebots_blacklist(address, date_add, date_upd, cnt) VALUES('123.123.123.123', now(), now(), 1);

not related to thirty bees, it is server misconfiguration. Google error message.

Notice: Upcoming version 1.4.0 will no longer support import of Excel files, at least not out of the box. Why? Thirty bees uses third party library to read excel files. Currently used library is no longer maintained, and does not run properly on all supported version of PHP (specifically on PHP8). There are alternative libraries that we could use, but those does not run on older supported php versions (php 7.0 and php 7.1). Because there is not a library that we could use that supports all php versions thirty bees support, we had to remove excel import functionality from the core (together with current library). But don't worry. Import functionality was extended, and we have introduced ability to register custom importer via module. And we will release new module 'Excel Import Datasource' shortly. You will be able to install this module if you run on on PHP 7.2 and newer. With this module installed, the Excel import will be allowed. This extension also allows for different data source implementation, for example import from XML files, or from API. If you are running on php 7.0 or 7.1 -- you should consider updating your PHP version.

only you can decrypt the message - we dont know your encryption key. Go to Logs and use decryption tool

On php side this is governed by directives post_max_size upload_max_filesize If you have proxy in front of you php server, for example nginx, you should configure it as well.

Upcoming version should run on PHP8. But of course, there might be some modules (third party or even thirty bees) that are not compatible. At the moment, you can try update your store to bleeding edge using core updater, and then switch to PHP8, and test. That would definitely help

the quantity info is not stored inside tb_product table, the column exusts for backwards compatibility only. Look into tb_stock_available table.

The file is owned by different system user than your php server runs under

I believe you are correct. Back in the day we didn't remember exact revision that was being used, we only remembered version. In this case, it is 1.1.0-1.1.x. Problem is that this version pointed to different revision after every commit to the bleeding edge branch. Because we now do not know exact revision, core updater compares your code base with 'current' bleeding edge for branch 1.1.x. And it will find differences, and mark them as manual changes. These warnings can be ignored now. After update this will not happen again, because core updater will remember exact revision.

This is filesystem permission issues. Your php server does not have permissions to write to directories /cache/smarty/cache/ /cache/smarty/compile/ or any subdirectories / files inside these directories. Use ftp, and delete these directories completely, and then create them again. Ensure that the access permissions are valid, and that the owner is the same as the user your php server is running under.

Your current installation seems to be very broken. Try to go to Advanced Parameters > Performance, and enable Debug mode. If this is not possible (another 500 error code), then use FTP and edit file config/defines.inc.php, and change line define('_PS_MODE_DEV_', false); to define('_PS_MODE_DEV_', true); Then go to Admin > Advanced Parameters > Logs again. It should display error in plain text now.

Your ajax request that should return json responded with html error message. This can happen when there is some fatal exception very soon in the request handler, before the controller action. I have extracted the (encoded) error message from HTML response and saved it as .txt file: exception.txt Download it, and then go to your Admin > Advanced Parameters > Logs, and use DECRYPT AN EXCEPTION MESSAGE functionality to see what went wrong.

I suggest you first investigate reasons why core updater causes "flood of errors". If there is a bug in core updater, we are happy to fix it. It is quite stable now, however. If you send me access credentials to your store (and ftp access as well), I can check the errors for you.

That's great to hear. I have moved this to bleeding edge, will be part of 1.4.0 (to be released soon). Fingers crossed. 🙂