datakick

We will do the investigation to see how complicated it will be. If it's simple change, we can roll the update soon. Otherwise this will go to backlog, as there are other tasks with higher priority. Currently the module should continue to work, provided you have selected proper API version in your stripe dashboard.

class 'Attribute' in global namespace is reserved in php8. In order to make tb php8 ready, we had to rename the class Attribute to ProductAttribute. There will be a mechanism that fixes (patches) third party modules automatically, but this mechanism is not yet ready for production -- still lots of bugs. Meanwhile, you have to patch the module code yourself. Replace every reference of Attribute with ProductAttribute. In your case, line 85 should look like this: $att = new ProductAttribute($attribute['id_attribute']); Look for these syntax patterns in the module code: new Attribute(...) Attribute::someMethod() Attribute::$staticProperty

Never played with this one. But I assume cloudflare will modify these nginx headers, since it's caching layer. you can see diffs by requesting curl -I https://www.domain.com/.../file.woff vs curl -I 199.199.199.199/.../file.woff I get HTTP/2 200 date: Wed, 03 Aug 2022 14:32:20 GMT content-type: font/woff content-length: 90412 last-modified: Tue, 19 Feb 2019 13:44:42 GMT etag: "5c6c084a-1612c" cache-control: max-age=31536000 cf-cache-status: HIT age: 3 accept-ranges: bytes expect-ct: max-age=604800, report-uri="https://report-uri.cloudflare.com/cdn-cgi/beacon/expect-ct" report-to: {"endpoints":[{"url":"https:\/\/a.nel.cloudflare.com\/report\/v3?s=VUCoNPsUr2WZxf4%2Bsd0XJgcgwMq4y7hqrey0LQG1a9Y2Gtno7j07DYM01T3EeJ9OsEyZp%2BLMbH%2Bwqf03i%2BNN1etvVz6JZ6w61KX1O3G7WhXfPucFeYG9h3SC2Xxdam4%2BMNsowbvT8d0%3D"}],"group":"cf-nel","max_age":604800} nel: {"success_fraction":0,"report_to":"cf-nel","max_age":604800} server: cloudflare cf-ray: 734fc316f984b333-PRG alt-svc: h3=":443"; ma=86400, h3-29=":443"; ma=86400 vs HTTP/1.1 200 OK Server: nginx/1.15.8 Date: Wed, 03 Aug 2022 14:33:17 GMT Content-Type: font/woff Content-Length: 90412 Last-Modified: Tue, 19 Feb 2019 13:44:42 GMT Connection: keep-alive ETag: "5c6c084a-1612c" Accept-Ranges: bytes As you can see, cloudflare adds cache-control header itself.

No, I mean creating orders from back office, either directly by using existing cart, or by recovering abandoned carts

Hi @Herrosik, I have not encountered this kind of issue, but I'll double check in my code. Maybe these problematic orders were created from back office by converting abandoned carts, or using old carts?

Hi all, please note that Stripe has released new API version 2022-08-01, which is NOT COMPATIBLE with current stripe module. You can check what API version is selected for your account in stripe dashboard: https://dashboard.stripe.com/developers Native thirty bees module is compatible with API version 2020-08-27

The error message from stripe module suggested that you have started using new Stripe API version that was released on 2022-08-01. The new API is not compatible with current version of a module, hence the issue. I'm not sure if you have manually updated your api version in stripe dashboard, or if you crated your stripe account recently and you were assigned newest api version automatically -- you can check in your stripe dashboard which API version you are using: https://dashboard.stripe.com/developers Native thirty bees module is compatible with API version 2020-08-27

paypal? I see stripe error message, and stripe transactions... none of them is completed. How xan there be any dispute? Anyway, the error message is not complete, we need the actual exception message. And stacktrace.

If you look into Config.xml file for what it says about stmegamenu module: <hook module="stmegamenu" hook="Header" position="35"/> <hook module="stmegamenu" hook="actionCategoryAdd" position="3"/> <hook module="stmegamenu" hook="actionCategoryDelete" position="3"/> <hook module="stmegamenu" hook="actionCategoryUpdate" position="5"/> <hook module="stmegamenu" hook="actionObjectCategoryDeleteAfter" position="2"/> <hook module="stmegamenu" hook="actionObjectCategoryUpdateAfter" position="2"/> <hook module="stmegamenu" hook="actionObjectCmsDeleteAfter" position="3"/> <hook module="stmegamenu" hook="actionObjectCmsUpdateAfter" position="3"/> <hook module="stmegamenu" hook="actionObjectManufacturerDeleteAfter" position="3"/> <hook module="stmegamenu" hook="actionObjectProductUpdateAfter" position="3"/> <hook module="stmegamenu" hook="actionObjectSupplierDeleteAfter" position="3"/> <hook module="stmegamenu" hook="actionProductAdd" position="5"/> <hook module="stmegamenu" hook="actionProductDelete" position="5"/> <hook module="stmegamenu" hook="actionProductUpdate" position="5"/> <hook module="stmegamenu" hook="actionShopDataDuplication" position="5"/> <hook module="stmegamenu" hook="displayLeftColumn" position="15"/> <hook module="stmegamenu" hook="displayMainMenu" position="1"/> <hook module="stmegamenu" hook="displaySideBarRight" position="2"/> <hook module="stmegamenu" hook="hookActionObjectProductDeleteAfter" position="1"/> When we ignore non-displayable hooks that should (and are not) changed by theme installation, we have <hook module="stmegamenu" hook="Header" position="35"/> <hook module="stmegamenu" hook="displayLeftColumn" position="15"/> <hook module="stmegamenu" hook="displayMainMenu" position="1"/> <hook module="stmegamenu" hook="displaySideBarRight" position="2"/> proper name for 'Header' hook is 'displayHeader', so the alias functionality works. Also, hook names are case insensitive, so 'displayMainMenu' and 'displayMainmenu' are the same. Now compare this with your image that "doesn't work" -- the same set of displayable hooks were set up for this particular module. Thirty bees is doing exactly what theme config.xml file instructed it to do. It installed (or enabled) stmegamenu module, unhooked all its displayable hooks, and hooked those specified in xml file. If the result is not right, well,... it's the problem of theme config file.

Header is an alias for displayHeader, it exists for backwards compatibility reasons.

First of all, it does work, otherwise you would not be able to provide the screenshot 🙂 I haven't seen the theme config.xml file, so it's hard to tell what is wrong. In this config file, theme author can specify which modules should be enabled and installed. For these enabled modules, author should specify what (displayable) hooks should be registered == the hooks that are called by theme. These hooks will be enabled, all other displayable hooks not mentioned in the xml file will be disabled. If the xml file does not mention any displayable hooks for given module, no hooks of the module will be enabled or disabled. Thirty bees is doing only operations that are requested by config.xml file. You can always go to Modules, and reset various theme related modules to restore the module default hook list (not the list one specified by theme), or go to Positions and transplant one hook position to another. However, this operation should not be needed if the config.xml file is properly defined.

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.