datakick

That's not how hook works, there is nothing to migrate. Hooks records are created on the fly, either explicitly (definition in theme, programatically from module) or implicitly when module register hook handler using $this->registerHook('whatever'). PHP code can call any hook (even if it does not exists) by executing Hook::exec('hookname',...). The same applies to templates, where you can call hook by {h name='hookname'} syntax. If hook record does not exists, or exists but no module installs handler, this call is a noop.

You can safely ignore these for now. There are multiple thirty bees packages for every PHP version. When you download thirtybees 1.3.0 for different PHP version than you have on your store, this nonsense comparison error will appear. This will not happen in thirty bees 1.4.0 release package

Another php8 compatibility issue. This will take some time before all of these hidden gems are discovered a resolved. I have filed github issue here: https://github.com/thirtybees/thirtybees/issues/1482 Next time please report bugs directly on github. If reported here they will be forgotten.

tb native google analytics module works just fine, if configured properly. If you don't see any hits, you might have some adblock / browser extension installed that is blocking data from being send to google. Look into your pages code to see if there is ga tag in there.

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?