Leaderboard

Yes, if this code exists in your tpl files, it means your store is already infected. But the fact that it isn't present doesn't mean your store is not vulnerable to this attack. We don't know about any vulnerability in the core that would allow attacker to modify/write to tpl files. We regularly check CVE database for prestashop vulnerabilities, and look for those that are relevant to ps16 codebase (so they are relevant to us, most likely). Again, that doesn't mean that they don't exists, we just don't know about any at the moment. But there were some that we have fixed in the past - running very old thirty bees versions is not encouraged. Most of the time the culprits are third party modules, usually those that allow uploading files (images usually) and do not properly sanitise inputs. That may allow attacker to upload php files instead of image, and then they have complete access to your entire store. Thankfully, you can use core updater module to check if any of the core files have been modified. If your store is infected, you will see it there as well. If your store is infected, it's not enough to just remove the infection. You need to find out the back door that was used to install the infection. That can be quite hard. Your server access logs can help a lot, so keep a few months of them if you can.

I created a small free module that updates all search engines that support the IndexNow ping protocol. As you might know Google is still not fully supporting it but other engines as Microsoft Bing, Naver, Seznam.cz, Yandex, Yep do. And if those are important for your markets this module might help you. https://github.com/therampagerado/tbindexnow/ Any help in developing the module is welcomed if you find this idea useful. Best regards, Rado

Hi everyone We've updated the Shops using ThirtyBees page + home page banner as requested. https://thirtybees.com/powered-by-thirty-bees/shops-using-thirty-bees/ If your site isn't on there or if there's an issue, please let me know and we'll sort it out asap. Thanks to @the.rampage.rado and everyone else concerned for creating the list and everyone who submitted their sites! I must say, seeing these sites, I was super impressed - some are even giving Shopify and Prest*sh*p a run for their money - especially in terms of designs. Obviously our sites are on ThirtyBees, so they're just better anyways 😉 Well done to all, and keep up the good work and please remember, if you haven't already, to please support ThirtyBees and become a member 😉 Your support helps us keep ThirtyBees alive and help it grow and thrive! https://forum.thirtybees.com/support-thirty-bees/

Hi everyone, hello @datakick, @Smile and @Acer My premium membership just expired, which felt like the right moment to pause and reflect on the current state of the project. I’ve been here since day one and truly appreciate everything achieved over the years. thirty bees has been a solid foundation for a long time, but I am seriously concerned about its future. Official commits on GitHub have become rare; while community PRs are still coming in, they often seem to go unnoticed. There is a lack of transparent communication regarding the roadmap. This leads me to a point where I have to ask: Is it still worth building on the thirty bees core, or is the project effectively dead as an open-source endeavor? Technical Hurdles and Workarounds In my daily work, legacy issues in the core are slowing me down significantly. Address handling is cluttered, and features like multishipping (used by maybe 5% of merchants) make the code unnecessarily complex and bug-prone. A prime example is the "splitting order" issue that hits me every few months—a bug known in the PrestaShop community for 15 years. To keep the system extendable, I’ve developed a "best practice" over the last few months using classes like OrderDetailExtension or ProductExtension that share the ID key to manage new columns. It works, but it’s a lot of overhead that only makes sense if maintaining backward compatibility with the core actually provides long-term value. If the project is stagnating, it would be more efficient for me to drop compatibility and modify core files directly. Waiting for Features Over a year ago, I had an intensive talk with Petr about a credit system for customers. Since I need exactly that, I waited—but I’m still standing here without a solution. In recent weeks, I haven't been able to reach Petr at all. While there was a recent sign of life on GitHub, it’s not enough for professional planning. I would love to see a Version 2.0 that modernizes the system radically: A rigorous code rewrite (even if it breaks old modules). Support only for currently supported PHP versions and updates for components like Smarty. A Backoffice designed around merchant needs, not just a collection of controllers. Clean Code as AI Foundation: clean, unambiguous codebase is essential today. If the core is logically structured, any AI can easily generate high-quality modules. If the base is "spaghetti," the AI will only produce more spaghetti code. Conclusion Is this vision of a Version 2.0 shared by the team, and is it something being actively worked towards? If not, that is perfectly fine. But then I have reached the point where I will likely move in this direction alone and radically decouple my own codebase from the core. Best Regards Emanuel

Hi Vincent Thank you for your post and for your support. We are aware of the issues of communication, lack of a clear roadmap, the improvements to the premium modules etc. We will have a discussion with the team and will be posting about our roadmap in the future. For now however, I can reveal that we have been working on updating Mollie as well as PayPal. However, with limited resources, this has proven to take longer than expected. But we're getting there and there will be a release with those modules in the future. Also, I will discuss the outdated shipping modules with the team to formulate an action plan. Regards

Thirty bees is still alive, that is the only thing that counts for me 😊 A lot of great things are going on github. It would be wishful, if we could clone Datakick somewow, but might be difficult 🫠

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'm a paying member. A In my opinion there are several 'problems' with TB: 1) Some basic modules such as a payment module (mollie) or shipping modules (myparcel, send cloud) are outdated. The modules or not updated for TB/PS 1.6 2) Lack of communication about the roadmap of TB (what can we expect in the near future from TB). "The team is working on a surprise. When they are ready, it will be revealed. 🙂" Investors don't like surprises and uncertainty. I think the same applies to (potential) users of TB. For now TB still works for me but I think in the future I'm forced to with to another platform. Not because I wan't to, but because basic functions as mentioned above, don't work anymore. The 'membership' modules are nice to have, but are useless without good basic modules. We will see what the future brings

Hey, everyone, I'm checking this project and I'm very interested in it, but I wondering if it is still an active project. I've seen that there are a lot of pull requests and issues open. Also, the last release was a lot of time ago. I haven't seen much activity.

did you check size of database tables? if there was no cleaning made, you can be surprised how much data is stored there, and some of the tables can have huge impact on BO speed.

Thank you for your opinion. As always, there's some truth in both opinions. There are a lot of things happening behind the scenes at ThirtyBees that's been in play for months now as we've been (slowly but steadily) working on re-invigorating the project and attempting to encourage more support. Stuff like outreach to developers, and campaigns for visibility and more. Things that are not immediately visible, but things that are definitely happening. Willingness there is and a lot of it too. Thank you for the support and for using ThirtyBees 🏆👍

Hi everyone, I’ve just released a free Thirty Bees module called Bulk Update Price, designed to help store owners save time when updating product prices. What it does: Bulk Update Price allows you to update all product prices in a selected category — either by a fixed amount or percentage. You can increase or decrease prices simply by entering a positive or negative value. Features: Update prices by percentage or fixed amount Supports positive/negative values (e.g., +10 to increase by 10%, -5 to decrease by 5€) Clean and simple admin UI Compatible with Thirty Bees 1.4 to 1.6 Works with PHP 7.3 to 8.4 Free for use on your own websites Download the module here: https://ko-fi.com/s/e02ad7afcd Feedback and suggestions are very welcome!

The standard template that datakick module installs do not contain shipping weight by default. You can very easily add it, though. GMC documentation https://support.google.com/merchants/answer/6324503?hl=en tells us that they are looking for element like this <g:shipping_weight>3 kg</g:shipping_weight> So let's edit the template, and add this element under <entry> node To get data in correct format, you need to use the expression product.packageWeight + " kg" Note that you need to do this twice if you are using GMC template for combinations, as there are two <entry> nodes in template, one for products without combinations, one for products with combination. In this case, you will need to use different expression in second node: combination.packageWeight + " kg" You can download this template: gmc-with-weight.json and install it into your datakick module, as an inspiration

Sorry ich habe das Thema total vergessen. Das wurde in meinem Shop mittlerweile auch ganz anders gelöst. Ich erachte es als sehr sinnvoll solche Produkte zurückzustellen. Wir berechnen daher bei uns einen score wo verschiedene Parameter entscheiden, wie die beste Reihenfolge ist. Aber ok das ist ein anderes Thema. Zur Lösung: der Core Code ist hier wirklich hässlich... Du verwendest auf deinem Shop das Filter Modul. Deshalb muss man die Lösung da suchen. Das Module heisst blocklayered. Suche die Datei blocklayered.php. Es gibt dort eine Funktion: public function getProducts($selected_filters, &$products, &$nb_products, &$p, &$n, &$pages_nb, &$start, &$stop, &$range) Die musst du bearbeiten... Suche die Zeile: m.name manufacturer_name, Füge danach folgendes ein: IF(stock.quantity>0,1,0) AS sort_helper, Nun füge zudem nach "ORDER BY" folgendes ein: sort_helper DESC, Nun sollte es funktionieren. Hier noch ein kleiner Screenshot: Funktioniert das so für dich? Ich konnte diesen Code nicht intensiv testen, da meine Shops nicht dieses Modul nutzen. ACHTUNG: bei jedem Update dieses Modul wirst du das wieder anpassen müssen.

TB rocks.. still doing new websites with it 🙂

It's a very interesting discussion here. I can understand both positions. It's really a chicken-egg game. But imo there is a huge game changer: AI. It has become way more simple and fast to write code. I am also not aware of the plans/roadmap of TB. But with the new AI tools, it's even possible for no coders to start modifying some stuff. Ofc it's always better, if you have some basic coding knowledge, otherwise you might mess things up. Even if you aren't brave enough to use AI yourself: I would guess, that prices for a custom module will come down a lot. @datakick what is your experience with AI these days? I would say it has speed up my developing work about 3-5 times. It's hard to tell, but it's for sure huge. The first time I have the feeling, that my todo-list may become shorter 🫣

A connector to a newsletter service, a modified connector to LexOffice to send Amazon invoices to LexOffice, and a connector to the ShopVote API. But these are already for PS 8.2.

@vincentdenkspelI said not just ... not just not. :) I have also created some modules that work. It's amazing!

I also created other modules. I use a dutch version of 'trustpilot' (keurmerk.info) The module I created with ai is twofold: 1) after the status of on order becomes 'delivered' the module will send a 'message' to keurmerk.info. Keurmerk.info will than send a review request to the customer. I the module I can set how much days after status 'delivered' the info is send to keurmerk.info. 2) the second part of the module is that I will display the last 5 reviews on my site in a slider. The third module I have created is a bulk-list-picker. With this module I select orders and the module will create a list of the stock locations of the ordered product. I can select 'per order' or 'bulk' This module has a bug in it, but I hope to sort this out very soon. consolidated_picking_list_20260223_123059.pdf

I will. It is only on a test site. What I did: I uploaded the all Thirtybees 1.6.0 files in AI and had it analyse all the files. Based on the analysis I made AI create a 'Thirtybees module development guide' Whit this guide and my input I had ai create the module.

Here is a description of the attack vector: https://www.prestashop.com/forums/topic/1105466-recent-prestashop-securtity-alert/?do=findComment&comment=3543558 Conclusion: Prestashop Addons Marketplace is a dangerous store where you should not provide any login details for your store. If you have provided your login details for your store on Prestashop Addons Marketplace, you should change them immediately.

Hi everyone! For the last few years I’ve been using JoliSearch module v4.3.28. It’s been a staple in my store, but as my catalog grew to over 10k products, I felt it was time for something faster and more precise, especially for technical search terms. I’m not a hardcore developer, but I’m passionate about making my store run better. 😊 Why replace JoliSearch? JoliSearch has several limitations today: It is no longer actively maintained. Search relevance is difficult to fine-tune. Loose matching often returns hundreds of results. The first visible results are not always the most relevant. Users may leave the store because they cannot quickly find what they are looking for. In my case, searching for a popular product type returned over 500-800 products, many only partially matching the intent. That creates noise instead of helping the customer. For technical stores (industrial hardware, connectors, cables, IPC systems, etc.), this becomes a serious UX and conversion issue. Why Meilisearch? Meilisearch is a modern, open-source search engine designed specifically for high-performance, real-time search experiences. https://github.com/meilisearch/meilisearch Key characteristics: Index stored in RAM --> extremely fast response times (often 1–5 ms). Built-in typo tolerance and smart ranking. Simple and clean REST API. Lightweight and easy to self-host (currently running on same VPS as my store). Much easier to tune than older search modules. Native support includes: Synonyms Custom ranking rules Faceted search Filtering Typo tolerance controls Vector search (embeddings support) Automatic typo handling Meilisearch automatically handles common input problems: Minor spelling mistakes Missing hyphens (e.g. “usbc” vs “usb-c”) Word order variations At the same time, it allows strict control for technical catalogs: Disable typo tolerance for SKU/reference fields Limit the number of allowed typos depending on word length Keep technical codes exact (e.g. 81271, CA-SASA-12CU) This is extremely important in stores with many product references and model numbers. Dynamic suggestions & smart autocomplete The module already includes a live search endpoint and basic fast autocomplete. Further improvements (some already implemented, others in progress) include: Real-time product suggestions with image, price, manufacturer, and reference Intelligent grouping (products, categories, manufacturers, feature values) Query preprocessing for better intent detection Smart result limiting to avoid overwhelming users Even in its current state, this approach can significantly reduce search exit rates compared to classic result pages. AI integration – OpenAI embeddings & hybrid search One of the most exciting aspects is semantic search. Meilisearch supports vector search, which allows: Storing product embeddings Performing similarity-based queries Combining keyword search + semantic similarity (hybrid search) Using the OpenAI Embeddings API (or local embedding models), we can: Generate embeddings from: product name, technical parameters, categories, descriptions Store them in Meilisearch Enable natural language queries This enables: “Cable for powering laptop via USB-C 100W” “Splitter for two devices” “Industrial ethernet connector” The goal is not to replace keyword search, but to enhance it. Current status of my module After short initial testing, the results are very promising. Already implemented: Custom index (products_pl, products_eng) Batch reindexing (500 products per batch) Live progress bar in BO Live search endpoint Synonyms editor (graphical table UI) Automatic JSON generation for Meilisearch settings Query preprocessing for better intent detection Matching strategy control (strict vs fallback) Monitoring estimated result counts (to avoid result explosion) The improvement in relevance compared to JoliSearch is clearly visible, especially in edge cases e.g. “Y-type cables”, where search behavior can now be precisely controlled. The target is a search interface that behaves more like a modern SaaS-powered discovery engine rather than a traditional e-commerce search box — fast, relevant, visually structured, and intuitive for users (as shown in attached screenshot) Has anyone experimented with Meilisearch in ThirtyBees yet?

I don't think that's necessary. I think, for starters, you should improve your paid modules. There is a lot of good stuff coming out of premium modules.. but they are: - Undocumented - real pain... I don't really know what they do... - Not UI/UX friendly - some are pain to manage So basically... idea of those modules, and functions are cool. However... Forgive me @Acer but if you can't get https://store.thirtybees.com/premium-modules straight... then you think you will be able to sell thirty bees? Look at this page, sorry to say.. .but from marketing view its not worth much... First of all... and most important... It's a hell to see how they work and if they worth it. There is a WALL.... Want to see how it looks? Support TB first. FAQ Snippets... more like basic docs than advertising description.... and where is banner saying? "Want it? You can have it for free if you support tb development" Bulletpoints... Same story... really nothing about module. Purchases... some won't even know its a re-stock inventory planner. Purchases sounds like customer purchasing.. Shortcodes... some more info... but how it looks? Dynamic lists... is a mystery to me couldn't get it to work All those software is made more for programmers than for users/merchants (Unlike thirtybees). You could really get those modules to profit you, just first put some effort. Because making TB paid without good marketing will cost you a lot. And heed my warning... there are a lot who will say "Look at thirty bees, Prestashop is newer, better and FREE, but TB became paid for useless script" You will pour oil into fire and it may burn you. Also... you can make a module marketplace, where you - for a fee like 10%? - allow people sell their modules. For module creator it's a fee based place to advertise... only one thing they need to do is make their module compatible with TB - and belive me, more modules compatible with TB = better future for TB. Don't go making TB paid, before you finish what you actually started with Premium modules, because IDEA is cool, Backoffice integration is cool... however visual and informational layer is at its lowest.

Cyber_Folks is owned by H88, a company that has been acquiring smaller hosting companies in Poland for many years. After each such acquisition, the prices of all services are raised by an average of 300%. Also, after this acquisition, Prestashop will be the most expensive SaaS in the world.

No need to fix anything, this is merely a notice for developers to investigate the surrounding logic. And we did that 🙂 With or without the fix, the end result is the same - nothing actually happens when the object (cart) is not already saved in the database.

You can safely ignore this. This was already fixed in bleeding edge, see comit https://github.com/thirtybees/thirtybees/commit/3c8447874a71825a1561fb2edb5371ee8249375b

In 1.6 there was a rewrite of the whole images section thanks to @wakabayashi and @datakick. In order to update to 1.6 and later you have to follow this guide in the BO -> Images:

It's active. Go through the branches and see what is cooking underneath. 🙂 And there are other BIG projects that are not on github but they took long time to develop.

we are using Turnstile and it is highly recommended by us (you have to register at Cloudflare, but this is quickly done and ok), >> and have a look at Blackhole for Bad Bots - thirty bees store also, this is very useful too !!

Not all stores use Clodflare. The module from the thirtybees repository “nocaptcharecaptcha” also secures the customer registration form.

Parameters behind # are for client use only. Request to the server never contains those parameters, server never sees them and can't react to them. When you open urls https://www.example.com/en/products/84/sample-product#/72-size-large or https://www.example.com/en/products/84/sample-product#/whatever your server receive the very same request - https://www.example.com/en/products/84/sample-product It does not know what combination you are requesting. Javascript will later parse the hash parameters, and will modify the product page to display the wanted combination if it's found. This also means that initial page render shows different combination, and only a few milliseconds later the page is 'adjusted' When you provide ?combination=xxx parameter, server knows upfront what you want to display, and can returns page with combination already selected (if your theme supports this, of course). The page already contains correct pricing information, product name, reference code etc -- this is important for web crawlers. This means that you need to provide urls with standard query parameters (after ?) to google

The thread in prestashop forum is quite interesting. I am now with 50k of products and notice here and there some performance issues. But these are almost always issues on my own code. With 3.4 million products you will find even much more such stuff. But these issues are often not relevant, if you have only 1k products. In my expierence the perfomance issues came to 90% from modules and maybe 10% from bad hardware or missconfiguration. What is the name of the corresponding thirtybees module?

I managed to achieve a similar result with CSS and a slight modification of the theme tpl file. product.tpl ~451 {elseif ($group.group_type == 'radio')} <ul> {foreach from=$group.attributes key=id_attribute item=group_attribute} <li><label class="radio-btn"> <input type="radio" class="attribute_radio" name="{$groupName|escape:'html':'UTF-8'}" value="{$id_attribute}" {if ($group.default == $id_attribute)} checked="checked"{/if}> <span>{$group_attribute|escape:'html':'UTF-8'}</span> </label></li> {/foreach} </ul> {/if} The following label was added inside the list-item element: <label class="radio-btn"> Then the CSS to get the button display that I wanted: /* applies button style to all radio elements */ /* default as configured is a block presenting a vertical stack of options */ label.radio-btn { cursor: pointer; display: block; } label.radio-btn input { position: absolute; top: 0; left: 0; visibility: hidden; pointer-events: none; } label.radio-btn span { padding: 7px 14px; border: 2px solid rgb(var(--color-dark-gray-rgb)/var(--color-opacity-03));/*replaced #EEE;*/ display: inline-block; color:var(--color-dark-gray-rgb);/*replaced #333; */ border-radius: 0.3rem; text-transform: uppercase; width:100%; } label.radio-btn span:hover { background-color:#002b45;color:#ffffff; border-color: #3498db; } label.radio-btn input:checked + span { border-color: #009BA2; color: white; background: #3498db; background-image: -webkit-linear-gradient(top, #3498db, #2980b9); background-image: -moz-linear-gradient(top, #3498db, #2980b9); background-image: -ms-linear-gradient(top, #3498db, #2980b9); background-image: -o-linear-gradient(top, #3498db, #2980b9); background-image: linear-gradient(to bottom, #3498db, #2980b9); } /*adjust fieldset styles on the radio button attributes*/ fieldset.attribute_fieldset .attribute_list ul li { float:unset; text-align:center; margin:0.5rem; } The theme is based on the Community Theme. Hopefully those who want to take an approach not requiring additional javascript will find this information helpful.

Why do we need a solution that is only needed in one store out of a million? Let the customer learn how to configure redirects in their email account. One customer wants to send to two emails, and another wants to send to two hundred 🙂 That's what redirects in the customer's email account are for.

Petr is around and working on TB stuff (some stuff may not be visible in GitHub). He is about to go on leave soon for 3 weeks. I'm curious though (perhaps I'm in a cheeky mood), if the Trusted Members here have seen this post? If we constantly worry about TB being dead, maybe we should try to do something? Like help if we haven't already? And if we have helped already (which is sincerely appreciated and awesome), maybe we can make a post there and encourage others to do the same? And maybe just maybe we can get another Petr or two or three + some new features, bug fixes, and other cool stuff while we're at it?

I believe the project is as death as the last 5 times, this was asked 😉 But you are right, @datakick is absent for some time now. I guess it's just holidays/recovery 😊

From a developer’s perspective, I can say that working with PrestaShop since version 1.7.8 has been a very good experience. A large number of new hooks have been added, which allow me to create modules for my clients in a clean way — without overrides, and without modifying the template or the core engine. When developing a module for the general market, I try to provide support for version 1.6 and ThirtyBees as well, but it's not always possible to do so in a clean and maintainable way. On the other hand, the complexity of PrestaShop's code has increased significantly — as if it were being developed primarily for tech-savvy users rather than for merchants in the first place. I see many flaws in the project, and I’m not surprised it might be losing market share. Nevertheless, I’m still able to build a wide variety of stores on this platform and efficiently add new features to them as needed. Another important factor is support from couriers and payment gateways. Many of our local Polish companies develop their modules exclusively for PrestaShop, often only for version 1.7. That’s why clients who come to us tend to choose PrestaShop and ask us to build their stores using this software.

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.

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

Hi, This module will allow you to quickly integrate a contact form on your product sheets. This contact form will be easily accessible by a simple click on the button added on your product sheet. This will allow your customers to contact you directly without leaving the visited product sheet, because we all know that a customer who leaves a product sheet is unlikely to come back. I've simplified the whole configuration and use of this module as much as possible while keeping it wide customization possibilities so that you can do what you want with it without tearing your hair out at understanding how it can work, simple and didactic. You can see for yourself by testing the module on its demonstration available on its presentation sheet. DEMONSTRATION PrestaShop 8 DOWNLOAD thirty bees: https://store.thirtybees.com/shop-modules/front-office/dynamic-contact-form-on-product-page PrestaToolbox: https://www.prestatoolbox.com/front-office-features/109-contact-on-product-page.html Addons: https://addons.prestashop.com/en/contact-forms-surveys/2312-dynamic-contact-form-on-product-page.html DEMONSTRATION https://interestedinproduct.carrd.co/ DOWNLOAD thirty bees: https://store.thirtybees.com/shop-modules/front-office/dynamic-contact-form-on-product-page PrestaToolbox: https://www.prestatoolbox.com/front-office-features/109-contact-on-product-page.html Addons: https://addons.prestashop.com/en/contact-forms-surveys/2312-dynamic-contact-form-on-product-page.html

There is a bug in thirty bees or the core updater that not every time the update runs define('_TB_BUILD_PHP_', '8.1'); in settings.inc.php is updated. It is not critical and you can manually edit this if you're sure the update propagated and your shop is running OK. This isssue was spotted a while back and @datakick advised that it can be fixed that way but nobody tracked down the issue so it's still present for some users in some scenarios.

Aside from adding another "Billing email" address to the customer record, which wouldn't be that challenging, automatically interacting with this new field in specific business situations would probably take some heavy lifting of core code. It's a relevant enhancement to request on Github as it definitely pertains to B2B. The complexities would revolve around classifying default email types to know whether they should go to the email 1 or email 2 always and other situations like that.

This is just hypothetical, right? Or do you have any powerful prestashop/thirtybees in mind? Cause my company is steadily growing and I am considering hiring a full time dev. If I can find a suitable person. He would ofc also contribute to the core.

That kind of help is what we need as well. Especially with things like YT, expanding developer resources for maintenance and new features and supporting the day-to-day running of TB, etc. If you have some ideas how you can help, you're welcome to DM me. Thank you 👍

If you need a hand, feel free to contact 😉

I am waiting for Mollie support since two or three years. All I need for my shop is Mollie, a nice and modern way to change my start page for making it more attractive for my customers in visual and speed terms and a better way to manage my catalogue in a whole (Prestashopmanager or Storecommander).

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.

limiting picture sizes would be a good idea. header 1920 x 1080 i.e Compression function included?