datakick

Well, it's definitely a blocker. When system tries to generate thumbnails for products (or other entities), it look into db for any image types assigned to image entity. If image entity is missing in DB, no image type will be returned, and no thumbnail will be generated. So, having image entity table populated, and having image types associated with image entities, is a prerequisite.

Image entity table should be initialized during update by core updater. Did you use core updater to update to version 1.6? Anyway, here what you could do: use core updater and check for database differences in core updater settings, enable Developer mode. Then open Developer tab, and run 'Initialize codebase' process. if nothing helps, you can manually add entries to db tables. Script: INSERT INTO `tb_image_entity` (`id_image_entity`, `name`, `classname`) VALUES (1, 'categories', 'Category'), (2, 'categoriesthumb', 'Category'), (3, 'manufacturers', 'Manufacturer'), (4, 'products', 'Product'), (5, 'scenes', 'Scene'), (6, 'scenesthumb', 'Scene'), (7, 'stores', 'Store'), (8, 'suppliers', 'Supplier'); INSERT INTO `tb_image_entity_lang` (`id_image_entity`, `id_lang`, `display_name`) VALUES (1, 1, 'Categories'), (2, 1, 'Categories Thumbnails'), (3, 1, 'Manufacturers'), (4, 1, 'Products'), (5, 1, 'Scenes'), (6, 1, 'Scenes Thumbnails'), (7, 1, 'Stores'), (8, 1, 'Suppliers'); INSERT INTO `tb_image_entity_lang`(id_image_entity, id_lang, display_name) SELECT iel.id_image_entity, l.id_lang, iel.display_name FROM `tb_image_entity_lang` iel JOIN `tb_lang` l WHERE l.id_lang != 1;

I don't want to spam this topic with off-topic, so just quickly -- there is a Purchases module that can quite nicely handle the purchase orders. It's intended to be used with (upcoming) warehouse management system, but can be used separately as well

Hi @30knees, it works as expected. Since I have access to your back office, I logged in, and tried to run the cron url -- it successfully deleted (merged) three scheduled customer accounts. My guess is you don't have the cron url for this module scheduled. Add it to your cron tasks list, to run at least daily.

You can look into log directory inside your tb installation, there will be human readable exception message.

This has been fixed. If anyone is interested what went on, here's s summary. Thirtybees contains vendor directory that have third party libraries that core depend on. We need smarty template engine to render templates, guzzle http client to send http requests to api server, tcpdf library to generate pdf, and others. These dependencies causes few problems some libraries have different implementaions for different PHP versions -- that's the reason why we have different PHP builds. We can do that as long as the library interface remains the same by having these libraries in the core vendor directory, they are autoloaded first. This can cause conflicts with modules In this particular case, we updated library mobiledetect/mobiledetectlib to latest version 4.8.09. That versions depends on yet another library psr/cache version 3.0. Previous versions of this library did not have this dependency. After update, core vendor directory contained psr/cache version 3. Unfortunately, a lot of modules (for example mollie) also uses this library, and have it in their respective vendor directory (modules/mollie/vendor). But because this library is already loaded by core, it will not be loaded from module vendor. If the module uses different version of library, than things can go bad very quickly. And that's what happened here - mollie requires psr/cache v1, but got psr/cache v3, and PHP raised exception. The fix was for us to remove the original library mobiledetect/mobiledetectlib from core -- it was replaced by library module tbdetectmobile. Now, this is not the complete fix, because there is still a compatibility problems between tbdetectmobile and mollie module -- both modules can't be installed at once. But at least it's not conflict between core and mollie module. We have released the tbdetectmobile module in different versions, that you can choose from very old version for PHP7.4 - https://github.com/thirtybees/tbdetectmobile/releases/tag/1.0.0 version for php8 that does not have dependency on psr/cache - https://github.com/thirtybees/tbdetectmobile/releases/tag/1.1.0 version for php8 that have dependency on psr/cache - https://github.com/thirtybees/tbdetectmobile/releases/tag/1.2.0 If you have a module that depends on psr/cache v1, you can't use tbdetectmobile v1.2, but you can use tbdetectmobile v1.1 It's a mess, I know, but it's the best solution I could found. In the future, we will release another version of tbdetectmobile that will change namespace of library dependencies, so it does not pollute global namespace. With that in place, the module will work correctly even if there is another module that have its own version of psr/cache library. Until that is done, you need to manually choose the correct version of the this module to use. It would be great if all modules did that -- but we can't really force that on third party modules. Side note: the mobile detection is used by core for two things only: to display mobile theme variant. As far as I know, almost none of the themes support this -- there needs to be a /mobile/ directory inside your theme that contains overrides for themes. If this directory exists, then thirty bees will use templates from this directory when request comes from mobile device. to disable some modules on mobiles/tables: Some third party modules might also depend on mobile detection. But, generally speaking, if you don't use these features, then you don't have a need for device detection, and you don't have to install the tbdetectmobile at all. Without this module, the response will be always identical for mobiles, tables, and desktop. With this module installed, the response can be different.

It's very hard to fix something that dev can't reproduce. At that point, it's just a guesswork. If anyone can provide a reprosteps, I'd be happy to device fix. I could try to come with fix blindly. But you know, it's not optimal. We could spend hours to refactor the way this module handles the response, which is a dangerous task. It could introduce new bugs or issues, and there is no guarantee that that work would fix the problem at hand. So the motivation is not really there.

yes, you should. At the moment it's not critical, this requirement is for future features. But it's better to be prepared

Since this is a bug in core, module update won't help. @jnsgioia this is fixed in bleeding edge. You can try to update your store, and retest

Hi, can you post the stacktrace from the error message? This does not look like a bug in module, but like a bug in the core.

That's weird. Your group 'Trusted Members' should have no quota for messenger: Maybe some cache issue, or something like that. I've flushed and regenerated members statistics, maybe that will help. If not, let me know, I'll raise an issue on forum software github.

Third party module issue - missing table. Either the module was not properly installed, or it's a bug in the module.

sorry, the lines range to delete is 98 - 104

As @the.rampage.rado wrote, you can install tb1.5 using custom target functionality. However, it doesn't make much sense to do that. There were a lot of bug fixes and security issues fixed since 1.5. Since you are already updating your store, you should migrate directly to newest version. There is no guarantee that you would not experienced similar 'compatibility' issues with modules on 1.5 as well. You will have to fixed them eventually, so why not now. Also, when you run older version of thirty bees, you will not be able to update some modules to newest versions. For example, custompayments v1.3.0 requires thirty bees 1.6.0, and there are other modules as well. You can still use older versions of those module, of course.

Delete lines 74 ... 104, and replace them with $this->_is_mobile = Context::getContext()->isMobile();