Leaderboard

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 🙂

Hi, I adapted Brevo's (Formerly SendInBlue) PS 1.7 version of their module to work on thirty bees and php 8.3. I didn't test on lower php versions, but it should work on php 8.0+ I believe. It connects and works and, for the price, they offer quite a bit of digital marketing functionality. Module is attached sendinblue_tb_v5.0.36.zip

I've added the option to set columns as hidden by default. When you create list column, you can pass 'hidden' => true, and thirtybees will not show it by default. Here's example: https://github.com/thirtybees/thirtybees/blob/f27320165d9e788af9f702af547adaaed6e0db90/controllers/admin/AdminOrdersController.php#L179 Once we implement list column customization, we will be able to show those default hidden columns, hide columns that are displayed by default, or even reorder columns in the list.

I am now on bleeding edge and php 8.4. My first impression is, that it works pretty well beside deprecation warnings. I will keep you updated 👍

Updated to fix abandon cart link generation issue with stock Brevo module.

This is a module I got the Copilot AI to create which exports products from a Thirty Bees store to a XML format that can be used to upload to Google Merchant center so they can be added to the shopping feed. The module extracts the following product details from a Thirty Bees store database: ✅ Product ID (<g:id>) ✅ Title (<g:title>) ✅ Short description (<g:description>) ✅ Product URL (<g:link>) ✅ Image URL (<g:image_link>) ✅ Price in store currency (<g:price>) ✅ Stock availability (<g:availability>) ✅ Product condition (<g:condition>) ✅ Brand (Manufacturer) (<g:brand>) ✅ MPN (Manufacturer Part Number) (<g:mpn>) ✅ GTIN (EAN or UPC if available) (<g:gtin>) ✅ Category name (<g:product_type>) These are far from the total number of field you can use with Google Merchant center but they include the minimum amount to get the product feed accepted. To install the module download the attachment exportgoogleshopping.zip from this post, and add a new module from your TB admin area and it will appear in the administration section when uploaded I created this module purely for my own personal use, but thought i would share it with the community for anyone else found it useful. It was my first time using AI to generate a module and I was suprised how well it managed to do it. But as i am not a developer I don't know if the code itself maybe buggy or insecure so if you are worried about that then maybe don't use it on a live store or uninstall it after you generated the XML file. I have tested it on both 1.5.1 and on 1.6.1 versions of TB and it worked OK on both for me, and the feed was accepted by Google Merchant center as valid. But I cannot offer any support for it should it not work for someone else or take any responsibility for any problems that might occur. I am happy if someone else wants to update and improve on this should module should they wish to. For those who might be interest in what prompts to give to an AI to generate a module like this one see below: "Create a Thirty Bees module that exports product data to an XML feed for Google Shopping. The module should include the following features: ✅ Manual XML generation via a "Generate XML" button in the back office ✅ Customizable title and description for the feed ✅ Dynamic price handling based on the store's default currency ✅ Stock availability pulled from the database (in_stock or out_of_stock) ✅ Condition extracted from the product's condition field (new, used, refurbished) ✅ Correct image retrieval using Product::getCover() ✅ Brand (manufacturer) added to <g:brand> if available ✅ MPN (manufacturer part number) added to <g:mpn> if available ✅ GTIN field dynamically populated with EAN or UPC if available ✅ Category assigned to <g:product_type> ✅ A "Return to Modules" button for navigation back after interaction ✅ Ensure clean XML output without empty fields ✅ Store feed file in a configurable location (default: /google_feed.xml) Include full module code in PHP that correctly integrates with Thirty Bees, following best practices for PrestaShop-based platforms. The module should be installable and configurable from the back office." exportgoogleshopping.zip

Sure, it make sense, but only after we add support for list column customization. Without it, there would be too much clutter.

Thanks you very much. It works now 👍 This feature will be so great, love it. Especially, if we can save presets. 🤩 As I had this functionality in mind too. I wonder about something. Why do you implement the new $this->filters_list? I wanted to add this functionality $this->fields_list, then I would also allow an employee to select the columns he wants to display. He could then save the columns and also filters. IMO this would help merchants to customize their list to their needs even further. They can just hide unnecessary stuff and as a dev we can add more columns, without having to think a lot about "is it too much". A module like orderlistcarriers would just be obsolete with a few lines of code. Also your example with the customer email would be good. Maybe some merchants would like to see in orders list!? I hope you get my proposal. Maybe I don't see the drawbacks!? 😊

Thanks everyone for testing. I've created the issues for those problems, and will make sure they are addressed before we merge this into bleeding edge. As we found out, the solution we implemented before was not good enough for all use cases. The virtual/dynamic attributes are fine in most cases, but sometimes we need even more flexibility. So we implemented yet another enhancement in this area -- full-fledged packs per combination. You can now choose between two different versions of packs Pack of existing products -- original implementation, when pack is defined on product lavel. You can use virtual/dynamic attributes here to tweak pack content using dynamic product attributes, as described in this thread above Pack of existing products - combinations -- new functionality. When you select this, you won't be able to define pack on product level, but you will have to define packs for every combination separately. This gives you great flexibility, as your combinations can have totally different/independent pack items. But obviously, it will be more complicated to set up, as you need to define pack content for every and each combinations. So choose this only when appropriate Pack content on combination level: This new functionality is in pack-combinations branch. If you can, please help us with testing once again.

Thanks for testing Yes, so far the values are saved in cookies. However, there is now an abstraction (ListViewStorage interface) that will make it possible to save filter values differently in the future. It's a todo task that I would like to implement soon. With this in place, cookies will be much smaller, and we will be able to implement additional features like saved filter presets. I think that will make this quite useful Thanks for bug report. I believe I have fixed this - could you please re-test on latest version of this branch? If you still get the error, please send me a controller class, so I can figure out what is wrong.

Da TB relativ einfach zu modifizieren ist sollte es weitaus weniger Probleme geben als bei verschachtelten Shops. Wer seinen Shop über Tap und hoch und runter bedienen kann ist schon fast dabei durch. Kontrastreiche Font Farben sind gegenläufig zu dem allgemeinen Händler Geschmack.

Unfortunately it won't be easy to upgrade smarty to newer versions easily. New versions of smarty raises a lot of new deprecation warnings when templates call php methods directly. We are now required to register all methods that are allowed to be called from smarty template. As you can imagine, that's something absolutely impossible for system like thirtybees/prestashop -- we simply don't have that information. For example, if some module template contains code like this: {if Configuration::get('PS_INVOICE')} <span>...</span> {/if} we would have to tell smarty engine that the method Configuration::get exists and can be called. In the near future, using that template without registering the method would cause runtime error. Because we are using templates from third party modules and themes, we simply don't know what methods are used. The only potential solution for us is to parse templates to collect list of all used methods so we could register them before template is used. While the parsing can be done only once (when template source changes), the registration of methods needs to be done on every render. That will cause quite a big performance impact - we need to load the info from somewhere and pass it to smarty engine. I don't understand why this change has been introduced, and I'm very unhappy about that. We will either have to keep using smarty 4.4.1 forever (which is not possible due to new php versions not supporting it). Or we will have to invest days or weeks of work to implement that stupid registration, just to get to the same point we are now.