datakick

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.

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();

1) you have to check permissions for directory /modules/ and all it's subdirectories, recursively -- there may be some directory deep in the directory tree that doesn't have proper permissions 2) check ownership of the directories / files. Permission 755 means that only owner can write. Maybe some directory is owned by different user -- it needs to be owned by the user used by your php process.

I'm afraid this is won't work. You can create conditions for order object, not for order products. The condition would have to be something like 'Order contains products from manufacturer XXX', and that's too complicated to implement. But I believe you can achieve the desired outcome using build-in Cart Rules. leave cart rule 'Code' empty so it is applied automatically in condition, set product restriction like this and in action, use 'Send a free gift' Should work out of the box

Conditions are specific to used trigger. What trigger are you using, and what action do you want to perform?

This is not 100% completed functionality -- it can be used perfectly fine, and it is being used by core, but there is still a piece missing that can make this very useful. There are couple of main use cases for this workqueue system: execute some task in isolation, and potentially in different thread/process defer execution of task for some time execute some task on regular basis (cronjob replacement) There are a lot of tasks in the core/modules that we want to be executed, but we don't really care about the result, or even when exactly the task finishes. A few examples: generate image thumbnails for a product sending email Currently, when we call Mail::send() method, the system is trying to synchronously deliver an email to smtp server. This can take a lot of time, and delays page response time. Order confirmation page can take few seconds to display because of this. Work queue system can help with this. We can describe the 'Send email task', and pass it to work queue system to execute it later, and the original process can continue its work. The email will be eventually sent, depending on the workqueue executor implementation. Unfortunately, currently exists only one Work Queue Executor implementation -- immediate executor. This implementation executes the task immediately, synchronously -- so there is no real benefits. We have plans are to implement different executors stand alone executor - there would be a dedicated worker process(es) that run as a cli php application (maybe even on different servers). The task would be serialized, saved in some queue (db, redis,...), end workers would pick it up and execute them. This is most advanced, most complicated, but also provides the most benefits cron-based executor -- tasks would be serialized and saved somewhere (db, redis), and executed on periodical cron events (every minute or so, for example) end-of-process executor -- the task would be executed in the same process that it initialized, but at different time. Instead of execute the task immediately, it would be executed after the response has been sent to browser, just before script end It would be up to store owner to decide, and set up, which executor they want to use. I'm currently running a variant of stand-alone executor on my site. It's not a complete solution, just a proof of concept, but it works quite nicely. But back to your question. To use this system, you need to Implement WorkQueueTaskCallable class. The execute method accepts $parameters. It can be anything, but it's a good idea to somehow encapsulate the shape of that parameters. Example task that generates image thumbnails/types can look like this: class GeneratImageTypesForImageTask implements WorkQueueTaskCallable { static function createTask(Image $image): WorkQueueTask { $parameters = [ 'imageId' => (int)$image->id ]; return WorkQueueTask::createTask( GenerateImageForProductTask::class, $parameters, WorkQueueContext::fromContext(Context::getContext()) ); } public function execute(WorkQueueContext $context, array $parameters) { $image = new Image((int)$parameters['imageId']); // ... todo - generate all image types for this image } } To execute this task, somewhe in core/module you need to get instance of WorkQueueClient, and enqueue the task: //... $image = new Image((int)$parameters['imageId']); $workQueueClient = ServiceLocator::getInstance()->getWorkQueueClient(); $workQueueClient->enqueue(GeneratImageTypesForImageTask::createTask($image)); And that's it. If you want to schedule execution of the task, you can create a Scheduled Task and save it to database. $payload property of scheduled task is passed as $parameters to callable.

I don't really know, you will have to test and let us know 🙂 I never used APCu in production, only on dev site. I don't like the idea that cache is part of the php process, I prefer standalone caching solution (redis for me)

Did your server used all those 32M of the cache memory? It's possible that it will allocate another segment only when your are running out of the memory

This is correct behaviour. The cache is being enabled selectively only when the module requests this (by providing $cacheId parameter to isCached / display methods) If we were to enable caching globally, then it would basically do the full-page cache functionality. That's not what we want, because we don't have an option to invalidate the cache entries when something changes. Full Page Cache tries to solve this problem it tries to determine when to invalidate page cache entry depending on page entity id (when cached entity is changed, PageCache::invalidateEntity is called, flushing all related cache entires) it punches holes for dynamic hooks These both operations are not perfect, and do not work in 100% of cases. That's why it's not really recommended to use FPC on most sites. But it is still much better solution then to enable smarty cache globally for all templates. That would be an absolute disaster.

Note: immediately after the cache is cleared, I also get empty data. But after I load front office, the apcu_cache_info returns correct information.

I don't have that module installed, and it works