datakick

Older versions of thirty bees silently ignored errors raised by database. For example, when some module attempted to insert data into non-existing table (or column), the insert statement simply returned false. Most of the time, code didn't check return status, and happily continued. That in turn usually caused a lot of trouble later. And it was very hard to detect the root cause of those problems. Newer versions of thirty bees do not ignore those db errors by default. When module tries to insert data into non-existing table or column, the exception is thrown immediately -- store owner therefore knows what's wrong, and can fix it (ie. create missing columns, as @ukclearance did) You can disable this behaviour by enabling 'Ignore SQL errors', but I strongly advice against that. Fail fast is very good for you, in long term

Install collectlogs module. That should catch any error

This most likely blocks the subsequent database migrations -- maybe new db column signature is not created in tb_employee table. Try using the script @the.rampage.rado pointed to log in to your store. Then open core updater, and check database differences. Ensure that column signature exists in that table. Then change the password, that should populate this new column

This module allows you to have lists of something -- usually it's list of products, customers, or orders. These lists are meant for employees only, and are usually used as some kind of todo list or trello board. There are few different ways how items can be added to the list (my examples use list of products, but similarly you could work with other entity types) 1) manually -- employee can assign products with lists in back office product page: 2) mass addition -- all products, or all products that matches some criteria can be added in bulk 3) Entry conditions You can set up list entry conditions -- when product is created, or updated, and conditions are satisfied, the product will be added to list. Example use case: Let's say I'm adding new language FR to my store, and I want to have list of all products that needs translation. I create new list named FR translation completed I perform initial load of products -- assign products by condition (english name exists, FR name does not exists) Next, I will create exit conditions (in Set rules > Exist conditionS) -- remove product from this list when product is updated, and FR translation for Name field has changed and is not empty: Now every time I edit the product that is on this list and change Name fields in FR, the product will be removed from the list. I now have a TODO list of products that needs attention of my translator: There are many other use cases. For example, when product price changes, product can be added to 'Review price' list automatically. You can have a list of orders waiting for products on backorder, or whatever. You can also create list without any entry or exit conditions, and use it for intracompany communication. For example, your employees can use lists to flag some orders for managers attention, or manually mark products that are low on stock,...

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.