datakick

You can look into your database here: select * from tb_attachment; and here select * from tb_product_download; to see what files should exists. You can (probably) delete any files that are not listed there -- unless some module is using the same directory to store its own assets.

Directory that contains Attachments and/or Downloadable products.

@Herrosik there is implemented address-sharing during checkout phase. If you look into database for addresses 5701 you will probably see that this is dummy address that does not actually contains any (customer) relevant information other than country / state. The reason behind this is, well, the stupidity of prestashop/thirty bees price calculation. In order to determine final price for cart, we have to have an address. That's the reason why (most/all) checkout flows require you to first create an account, then create address, and then select carrier and payment option. Chex, on the other hand, allows you to select carrier and payment first, so you can quickly see final price. To do that, it created few dummy addresses, and use these to calculate the cart price. Once you progress in your checkout flow, and create account / login, then the actual address will be used instead. There is a hope that the final price will not change with this step (but it might. For example, if you use module that assign different delivery zone for zipcode ranges) TLDR: this is expected behaviour. Look into database for addresses with id 5701 / 5702 / 5703 and you should see that these are, in fact, dummy addresses.

It is used not only for statistics, but as a peristent identifier of your annonymous visitors. Every time your visitors acces your site (with the same cookie), the session will be assigned with the same Guest record. This can be used for various pusposes. For example, my revws module uses this functionality to allow annonymous visitors to edit their own reviews. If you truncate this table, your visitors will receive brand new Guest record on the next visit, and the (persistent) identity is lost.

It can be emptied. You might experience some strange behaviour with existing orders / abandoned carts / stats, but nothing serious.

These warnings exists to inform user that the theme tries to hook / unhook nondisplayable hook. Take hook actionFeatureSave from module blocklayered as an example. This module use this hook to react on a situation when feature is saved to database in order to rebuild its cache. Why should installation of a new theme disable or enable this functionality, which has absolutely nothing to do with theme? The reason why your theme looks 'weird' after installation is that it did not provide valid set of displayable hooks that should be hooked/unhooked via its xml file. Thirty bees did not know what to do, and therefore did nothing.

The proposed fix is in the bleeding edge, as a quick solution to this very serious issue. Note #1: there is a significant performance overhead of encryption + base64 encoding / base64 decoding + decryption, which may render this cache totally useless. I did not make any performance tests yet, but plan to do so. If the test shows that the performance overhead is too big, we will drop this functionality completely. Tracked here: https://github.com/thirtybees/thirtybees/issues/1476 If you are using mysql smarty cache, please test yourself, and decide if different cache should be used instead. Note #2: thirty bees already supports various server side caches (redis, apc, memcached), but this SSC is used only for Full Page Cache functionality. We should reuse this for smarty cache as well, which could give us quite a big performance boost. Tracked here https://github.com/thirtybees/thirtybees/issues/1477 Note #3: I would like to reiterate. This Smarty MySQL Cache vulnerability can be exploited if, and only if, your store already contains some SQL injection vulnerability. And if that is the case, you already have a huge problem. We don't know about any SQL injection vulnerability in thirty bees core or any native modules, but there may be some somewhere. But any third party module can have such vulnerability.

yep, depending on a benchmark test results this functionality could be dropped completely. It is likely that added overhead of db query + decryption will erase any perfomance gains this cache has to offer

Not necessarily. TB supports multiple encryption methods, so php encryption key might not be defined. Use Encryptor::getInstance() instead. Encryption and decryption of cache entries might be performance killer, though. I believe signature will be a better alternative here. Will do some benchmark testing.

I did a little more investigation. Thisbis a chained exploit. In order for this to be dangerous, you first have to have sql injection vulnerability present in your store. As far as we know, there is no such vulnerability in core. But there may be, of course. And any native or third party modules can have sql injection vulnerability in their code as well. If your store is vulnerable to sql injection it is already huge issue. Attacker can update, delete, and possibly read any data in your database. They can change passwords, delete orders, or whatnot. But if you have enabled mysql smarty cache, this problem is elevated to the stars. Attacker can insert data inside smarty cache table, and smarty library will evaluate this data as php code. Which means that attacker can run arbitrary php code in your store. That's fuc*ing scary The fix will be quite simle. We will sign any data stored inside this table with secret that is know to php only, not stored in db. Attacker don't know the secret, so they will not be able to insert correctly signed data into the database. Until the fix is designed, pleas go to Performance settings and ensure you are using filesystem smarty cache implementation. Do not edit core files as suggested above, please.

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