Leaderboard

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,...

There is a vendor dependency psr/cache that some other modules may also rely on. Updating crashes the site if you have modules that also rely on it and that have their own versions. datakick is seeing whether he can remove the dependency from the core.

Post the solution here. Most of the time production shops have issues and need a solution fast.

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.

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.

I put my money on that inside stripe's module there is a image folder where you can swap this with something sized and optimized for this place. 🙂 In this case it's /views/img/stripebtnlogo.png But keep in mind that this will be overwritten on every update.

Will this solve the issue with non regeneration of thumbnails?

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;

Here is my configuration that works for Warehouse theme. Your theme should be similar (sizes are dependent on your theme so no need to change them as they should be left as the theme configured them when you updated to 1.6, only fix the entities). But I can't remember if this will fix your issue - the entities are used to show the already generated images I think in front office. Nevertheless it should be configured so go ahead and test, hopefully datakick can join with master suggestion for this issue.

Don't use any PS plugins related to images on TB 1.6. This section was totally rewritten and the plugins are 99.9% not compatible. In order to debug the issue - first check if there are any overrides remaining related to images when you remove the modules. Are there any errors, do you see any popup messages when regenerating? Do you have your Image Entities column configured (this is needed so the system know where to show what).

The yellow background is for products with the depends_on_stock flag set. It puzzles me a bit why someone would depend on a background color to see that a product is out of stock. A search for products with quantity lower than 1 would seem much easier. But I can add it as an option if you want.

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

Try this script. After you login and change your admin pass DON'T forget to remove this script from the site as everybody can use it to access your BO.

I had the choice of buying a module from mypresta.eu or from another provider. After some research I decided to go with the other provider. It seems that Vekia is hardly reachable for some time now, and they don't even respond to simple queries. There is a solution for security-related problems in the modules, but sometimes that takes several weeks/months, see Friends-Of-Presta Security Advisories. It was suspected that he was not well or something similar, but he could and should communicate that with a neutral note. If you don't know anything about it and don't get any answer, that's never good.

Those are one tool. I'd be careful in trusting the results of so called SEO Audits. It takes years to find a few ranking signals not being published, and you find also published SEO signals which are not.

That is what I am doing.

Note:

If a merchant is trying to be serious about their shop I don't see any other alternative rather to hire the best person they can find to work on their shop. In our case it's very easy as we know him. 🙂

Hello, that's exactly what we're going to do. I'm still doing some tests, as mentioned in another topic. Datakick suggested that it could be done in 1-2 hours of work. That's money well spent. Of course you want to try things out yourself and if you're successful with small changes to the code, that's great. For other things, however, we're at the point where we'll outsource it, which includes the final adaptation for PHP 8.x.

As somebody said - most of those 'issues' are fixed very quickly as they are trivial syntax change. Of course for me this is not the case as I'm a code noob. If you also don't feel secure you can hire a php developer and they will help you out. I even know a very very good one - datakick. As a bonus - you will work with the project's mantainer, currently there is nobody more experienced with thirty bees' code and inner workings. And of course by hiring a developer fixing your shop they can find some bug and help develop the platform for everybody else! 😉

That's true, but after payment completed, the module still needs to process the payment. Payment providers usually maintain some php library that can be used to access and process data from their API. And those libraries are not PHP 7.4 compatible. PHP 7.4 is dead. If you are still using it, you will face more and more problems in the future. For example, you won't be able to use to new versions of stripe or paypal module, and ultimately the old versions will stop working after the api endpoints are closes. If everything works properly on PHP7.4 now, it's the ideal time to slowly fix PHP8 issues on your store, and prepare for update.

Has this module been tested with ThirtyBees version 1.4.0 ? This version is not shown on the compatibility list. Does it function for the United Kingdom? The UK is not shown on the demo. Best wishes, Ian