datakick

Warnings and notices are not important. Look for errors. If your store throws 500 error page, there must be something there.

We do have such mechanism -- error handler collects 500 errors and saves them inside /log/ directory. As @wakabayashi wrote -- it is usually very easy to fix php8 issues. If the module is not maintained anymore, you can try fix it yourself or hire external help. Any developer should be able to fix these kind of issues in few hours, or even couple of minutes. We offer such services as well, by the way.

Look into your php server error logs

Not possible

I just want to point out that the auto-fix mechanism we are talking here about is only for Attribute class rename. This is indeed backwards compatibility issue caused by tb 1.4.0, albeit forced upon us by PHP8 reserving this name in global space. We have prepared mechanism that parses the module code using PHP parser. That way, we can detect any references to Attribute in global space, and replace it by ProductAttribute. Unfortunately, this parsing is a very slow process, and it can easily time-out. And even if it does not timed-out, it makes module uploading process look very slow and sluggish. We need to work a little bit more on this mechanism to make it usable in real world. There are few things that we need to do -- for example caching of already parsed classes, do not parse files in module 'vendor' directory as it it very unlikely that any composer library is using prestashop/thirtybees Attribute class, test files if they are using Attribute text using string functions, and parse only those that do, etc. We can fix this particular BC problem. But there will be other problems related to PHP8 that can cause serious issues. PHP8 is much more strict than was PHP5 for which those modules were originally written.

New module tbspreadsheetdatasource was just released. This module reintroduces removed functionality to import excel files. You need to install this module only if you are running on bleeding edge (on soon in 1.4.0) and if you need import from excel files. Import from CSV is still supported natively. Note that this module required PHP 7.2 and higher. If you are on PHP 7.0 - 7.1, you are out of luck. You could theoretically create similar module that uses phpoffice/phpexcel library underneath. We will not implement such module, since we are already planning phasing out php 7.0 and php 7.1 support in core anyway.

For live site, PHP 7.4 is optimal (if you are on 1.3.0 / bleeding edge) For test site, please use bleeding edge and PHP8.1

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.