datakick

I did some testing, and... released a new version of paypal module, and I strongly recommend everybody to update 🙂 There was a serious bug in module. When creating an order, paypal module provided current cart value instead of amount that was actually paid. This should be always the same, unless it isn't. For example, if you can do this: clicks on payment button that opens paypal checkout page open your store in different tab, and amend the cart (add/remove products, change carrier,...) switch back to paypal tab, and conclude the payment Normally, the order would be created with Payment Error state. But because of the bug in paypal module, the order would be created in Payment validated state, everything marked as fully paid. Neat.

https://www.php.net/manual/en/migration74.deprecated.php

That's not really relevant to this thread. Feel free to create a dedicated topic to discuss that

There are a lot of use cases, but I guess it depends on what needs you have. For example, we have recently used this feature to find all products within certain profit margin range.

For future reference, it's pointless to attach encrypted error messages. You are the only one who can decrypt it -- you need to log in to your back office, go to Logs, and there you can upload this encrypted file. It will show you the error message.

For developers here: you can test adding your own filter fields by modifying Admin***Controller classes, using new property filters_list. This property accepts the fields in the same format as property fields_list (which is used to define list columns) Example from AdminOrdersController: This is all that is needed to support filtering on customer email and names: https://github.com/thirtybees/thirtybees/blob/f59054511624de2131f86e4373604f827362468e/controllers/admin/AdminOrdersController.php#L214-L230 $this->filters_list = [ 'customer_email' => [ 'title' => $this->l('Customer - Email'), 'type' => 'text', 'filter_key' => 'c!email' ], 'customer_first_name' => [ 'title' => $this->l('Customer - First Name'), 'type' => 'text', 'filter_key' => 'c!firstname' ], 'customer_last_name' => [ 'title' => $this->l('Customer - Last Name'), 'type' => 'text', 'filter_key' => 'c!lastname' ], ];

Hello everyone, I'd like to announce new upcoming feature, and as always ask for testing and reporting any and all issues, problems, and enhancement requests. This new functionality is names List Filters. You can test it by upgrading your store to list-filters branch (using core updater in custom targets) What this new functionality do? On every (filterable) lists in back office you will find a new icon in upper right corner: When you click on it, new section will appear. Here, you can define additional filters that will be applied to the list. The new filters are applied together with the standard filters from list header. But these new filters are slightly more powerful, because you can select operator - not, contains, starts with, between, any of Also, developers can define additional filters in AdminControllers that do not depend on list columns. For example, I have added new filter fields for Order list controller - (Customer - Email, Customer - First Name, Customer - Last Name). So you can filter order list by customer email, even though customer email is non one of list columns! We will be slowly adding more and more filter fields based on your suggestions. Let us know what you need!. This functionality is not 100% completed, but it's quite stable. I've been using it on few production servers without any issues for a few weeks now, so it should be safe for you to test it as well. We already have a few enhancement we want to implement. One of them is support for filter presets -- you will be able to save your filter settings, and easily switch between different presets. Now it's your turn. Please test and give feedback. I'm sure there is a lot to improve here. I'm very excited about this new feature, as I wanted to do have this for a few years now. And finally it's coming 🙂

Thank you for this. I've commented on your PR and requested some changes. Could you look into that?

It doesn't make much sense to me either. There is a checkbox in UI for merchants to decide if they want to restock or not. Code should no make some auto-magical decisions and ignore the user-selected settings. Let's remove this.

The Edit button on that page is "special" 🙂 When you click on it, it simply changes the content of New Tax Rule form. If you are way down the list of countries, you may not notice this.

Hi everyone, I'd like to ask you for a help with testing upcoming new feature - Packs with Combinations. As you may know, it is currently not possible to have combinations for Pack products. This new feature add supports for that. What is it good for? For example, let say you are selling sport equipment. You want to create a bundle for soccer players containing soccer ball, socks, and cleats. Every one of those products in pack can have different variants (ball can have size 1-2-4-5, socks can have different colors and sizes,...). Because thirty bees does not support packs with combinations, you would have to create a dedicated Pack Product for every combination of products that you want to sell. That's not very user friendly, and it's very hard to maintain. That's why we have this new feature. How it works: 1) When you are adding a product with combinations to your pack, you can now select a special item variant named virtual attribute. (It's stupid name, I know. I'm open for better name suggestions 🙂 ) 2) when you add this special variant to the pack, and save the product, thirty bees will automatically generate a matching Attribute containing all combinations of that product. This is a special Attribute that can be only used by Pack products that contains the virtual attribute item. System will make keep the attribute values in sync with existing combinations. You can rename the attribute name, and also rename the attribute values. 3) In pack product, you can use this new attribute to create/generate combinations: 4) On front office, you now have an option to select specific combination of a pack: This approach is not the nicest. I personally don't like the need for dedicated Attribute that is kept in synch with specific product combinations. But by doing it this way, we have achieved backwards compatibility. Every modules that work with combinations/attributes can work with that. There are a lot of corner cases that I'd like your help with testing. If you are willing to help, you can use core updater. In module settings, select 'custom target' as your distribution channel, and then update to branch pack-combinations: Thank you for your help!

That was one of the reasons why we moved this functionality from core to the module -- so that developers could create different modules that provide the same functionality (maybe faster, more performant, more configurable...) Unfortunately we don't have enough free capacity to create a new module based on this library.

The code to minify html can be called using Tools::minifyHTML method, but core does not use this method to post process html code generated by templates. Some modules can still call it directly, though. I'm not sure how useful it is to minify dynamic html content. With CSS and JS we are minifying (mostly) static assets, and generated minified js/css files are saved on filesystem and reused by other http requests. But we can't really cache dynamic html this way, so this overhead could cause more trouble than benefits. CPU and memory usage would probably much higher. This would need some comprehensive performance testing.

The email review link is not really important, it just opens a review dialog. If it's not possible to select stars, maybe it's because that product doesn't have any review criteria associated? Check criteria conditions in back office.

This does not impact HTML code, just CSS and JS

Mode "replace existing ..." means that only association between records is deleted, not the actual referenced records. If you were importing products and used 'Replace existing feature values', you would not expect the old feature values to be removed from database. The same logic is applied for images -- the old images remains in database (and on disk), and new one are imported and linked with the product.

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.