Leaderboard

thirty bees 1.7 is here! 🐝 We’re excited to announce the release of thirty bees 1.7! This version brings a wide range of new features, powerful merchant tools, better performance insights, improved security, and a stronger foundation for the future of the platform. Better tools for merchants Managing your store is now easier with several new improvements: Session-based profiling Find performance bottlenecks without affecting your customers. You can enable profiling for your own session only, analyse real page performance, and optimise your store without turning on debug mode for everyone. Packs with combinations Product packs can now include combinations. Create more flexible bundles with specific sizes, colours, or variants exactly as your customers need them. Advanced list filters Back-office lists are more powerful than before. Create custom filters for orders, products, and customers to find what you need faster. Built-in credit system Issue store credit to customers and automate voucher generation while staying compliant with tax regulations. Official PayPal certified module thirty bees 1.7 includes a new official PayPal module using the latest PayPal APIs, providing a modern and future-proof payment solution. Smoother daily workflows Many improvements make everyday store management easier: PDF documents such as invoices can now be displayed directly in the browser. Create orders directly from abandoned guest carts. Attach files to customer service messages, such as invoices, manuals, photos, or return labels. Improved pack handling across the back office, orders, delivery slips, and dynamic pack synchronisation. More flexible back-office order creation, improved module warnings, better specific price management, custom export filenames, and clearer multistore order views. Better product and shipping management Products now support universal compliance attributes, including: HS codes Country of origin Age verification Dangerous goods information (UN number, hazard class, and packing group) These structured fields make it easier to manage shipping, customs, and invoicing requirements. Product combinations also received improvements: dimensions such as width, height, and depth can now change per combination. This allows carrier selection and shipping costs to be calculated more accurately for larger variants. Reliability, security, and future improvements thirty bees 1.7 introduces automatic database backups with configurable retention periods, helping protect your store and data. The platform also includes preparation work for PHP 8.4 compatibility, ensuring thirty bees continues to run on modern and secure server environments. For developers, version 1.7 adds new hooks and extension points, including improvements for payment options, webservice resources, delivery options, contact forms, custom KPIs, admin order buttons, and namespaced Object Model hooks. As always, this release also contains many smaller improvements, bug fixes, quality-of-life updates, and multiple security fixes. Thank you to the community ❤️ A huge thank you to everyone who contributed code, tested updates, reported bugs, and shared feedback. This release would not be possible without the thirty bees community. Update your store today and discover everything thirty bees 1.7 has to offer! 🐝

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.

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

Yes, we have decided to deprecate the old paypal module. We thought about creating a new major version of paypal module, but decided to go with a brand-new module, so if any one of you guys wanted to keep using the old one, you could. The new module will be released shortly. It's based on latest paypal API. At the beginning it will not contain as many features as the old one, it just focuses on accepting payments reliably. In the future, we will implement other features like refunds etc, if there is a demand for it. Feel free to use old version of the module for now. Just know that it's been officially deprecated, and we will not invest any time into it.

Hello everybody, TB is not dead .. it just smells funny, sorry that I couldn't resist. 😄 “Jazz isn't dead. It just smells funny.” ― Frank Zappa but it's up to us to make something different.. I have not much hope from the TEAM.. but from the community maybe things can go further. I still use and work with TB often, but now it's complicated to promote it to anybody because the lack of presence from the official communication. I still make many modules for some users, it's really fun to make modern modules with super cool looks on something that looks "dated", front and back end. Performances on TB are still the best ^^ php 8 does the job, no need for fancy framework. Best Regards to all of you guys !

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

OK, thank you Smile for the answer, that makes sense. This release gives me the will to get a nice modern theme to work with. Could that be done natively for once, instead of a theme that drags a pile of modules along with it? A default theme should work on its own, that's also easier for you to maintain. I'd be really happy to see a Bootstrap 5 theme in TB, and I'm willing to do the work. I did one a few years ago (Cisero), so I know where the landmines are. It would ship alongside Niara rather than replace it, so nothing breaks for existing shops, and with no build chain at all, plain CSS and variables, so anyone can edit it. Happy to talk about it whenever you have time.

Hi all We've been at work behind the scenes to bring you a new release of TB. An official announcement should be made within the next week or so, with all the details etc. This update brings a new, official TB version of the PayPal module (using the latest PayPal APIs etc) - certified by PayPal. I've let the guys know about the message you've been getting - as far as I understand, the update should bring your module up-to-date with the latest version. We will keep you posted. @Smile @datakick

Hi all, From 19 June 2026, EU law (Directive 2023/2673) requires every online store selling to consumers to show a clearly visible withdrawal button, so customers can cancel an eligible order without digging through contact forms or legal text. To make compliance painless, we built tbwithdrawalbutton and it's completely free for everyone. No license, no tiers, no catch. What it does Adds a single, prominent "Withdraw my order" button on a clean standalone page. Walks the customer through a simple, guided withdrawal request. Automatically routes the request to your customer service works with both the core CS system and the tbticketsystem module (release for members in upcomming weeks). Matches your shop's look and feel out of the box, including styled confirmation e-mails. Why it's worth installing It's the law - from June 2026 a withdrawal button is mandatory for B2C distance sales in the EU. Less support overhead - requests arrive structured and in the right place. More buyer trust - a transparent, easy cancellation process increases confidence. Download / install 👉 Get it here: https://github.com/thirtybees/tbwithdrawalbutton Feedback and questions welcome in this thread. tbwithdrawalbutton-v1.6.0.zip

Found it! In the past I had first used the Eicaptcha module and then I had switched to the Thirty Bees module and disabled Eicaptcha. However, somehow the Eicaptcha override was still present. Now that it is removed things work again.

I have been here from the beginning. I can't remember any serious collaboration by the community. It were always individuals, that were investing some time here and there. There was once the idea of developping a new theme together. I failed very quickly. 90% - 95% of the improvements came from the core team. That's just a fact. It was Dekker, Traumflug and Datakick. Then there was Lesley and Smile who were more on the business side of the project. The core team isn't anymore active. That's why the project is likely to be dead. Who will fix major security issues in the future? Who will update to newer php versions? Who will handle github? There are 50 open PR. Who can update smarty? Who could fix the core updater if it breaks? These are the major questions. And the only decent answer in recent years was Datakick.

Any news on an updated Mollie module?

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.

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 🫣

My idea is to split the RMA process into a tree They choose reason for the RMA: - Exchange. - Warranty claim. If they choose Exchange, they are presented with an option to choose another combination from the same product. If they are at the same price- perfect - the customer sees guidance on how and where to return the item and how/when they will receive the exchange. If the combination they choose is cheaper they are presented with an option to receive store credit or get a refund after the process is completed. If they end up with the first option, we're using the new credit system. If they choose a combination that is more expensive, we might generate them a virtual product, add it to new cart for them and escort them to the checkout after they complete their RMA request. The virtual product should be limited to this customer and hiden from the normal catalog. Product name Price difference – RMA #000184 Short description: Price difference for exchange associated with RMA #000184. Original item: hmlCORE XK Jersey Size M Replacement: hmlCORE XK Jersey Size XL Returned-item credit: €31.95 Replacement value: €36.95 Amount payable: €5.00 Original order: #001284 That way they can use any payment method we offer, even COD which can be attached to the replacement product we ship to them. We only ship the replacement when they have returned the original product and paid the difference (if use of prepayment method like card/bank wire is selected). Same for choosing an entirely different product in the other branch - we can display a normal search field, where they can find all products by name/ref number, select combinations if present and proced with the flow in the same way - same value - perfect, replacement is cheaper - choose store credit or refund, replacement is more expensive - generate the virtual product and make them check it out. For warranty claims, we can have a configurable form where they select a predefined issue (delivered broken, broken after usage, defective part, etc), they might be asked to describe the issue in writing, and of course to upload mandatory images so we can inspect the defect. Then after we process the request in BO the customer receives a special RMA contact email with instructions how we proceed with it. We can even expose hooks so external shipment modules like the one Codex generated for me for our local courier can generate a return label and send it out with the email. In general, the idea of a custom module doing this is good but i think that RMA process should be part of the core as every shop is mandated to have this process in one way or another. We simply have to modernize and optimize it so the customers find it easy to use and detailed enough so they don't think they are left in the deep and have to email or phone us. If the form is descriptive enough and acts more like a wizard with 2-3-4 steps, I think the user will gladly use the RMA flow more and leave the emails as a last resort.

thirty bees integration test report Measured on 2026-08-24 against the local thirty bees 1.8.0 shop using PHP 8.3.30. The repository remained the canonical source. This report distinguishes measurements and observations from interpretation. CCC and lifecycle Measured: installing tbwikiminifier while official tbminifier was installed returned false, showed the explicit conflict error, created no hook rows, and left both module versions unchanged. The old module was never modified automatically. Measured: after clean old-module removal, the new module registered exactly actionMinifyCss and actionMinifyJs for shop 1. No actionMinifyHtml row, controller, table, or setting was introduced. Measured: direct Media::minifyCSS() and Media::packJS() probes recorded the new hooks in Hook::$executed_hooks; outputs matched Wikimedia Minify apart from the core JS semicolon trimming/join contract. Fifteen generated CCC bundles across the tested page set parsed successfully. Measured: disable and re-enable removed/restored the only active hook provider in separate PHP requests. CCC CSS/JS versions advanced together through 15, 16, 17, 18, 19, 20, and 21 during lifecycle tests. After the interleaved comparison, tbwikiminifier was restored as the sole active provider and tbminifier was uninstalled. Observation: thirty bees core calls the first CSS/JS hook response and does not chain providers, although all responding providers can run. The explicit old-module conflict prevents the known double-provider case. Asset corpus benchmark Every one of the 156 generated outputs (78 inputs multiplied by two engines) passed the applicable Acorn or CSSTree syntax validation. The actual-shop subset contains 33 JavaScript inputs totalling 1,178,692 bytes and 22 CSS inputs totalling 541,778 bytes. Actual-shop aggregate tbminifier tbwikiminifier New - old JS output 1,063,778 B 1,061,031 B -2,747 B JS gzip 288,557 B 287,785 B -772 B CSS output 424,402 B 429,813 B +5,411 B CSS gzip 86,794 B 87,173 B +379 B Summed per-input median time, JS 2,123.47 ms 896.55 ms -1,226.92 ms Summed per-input median time, CSS 135.19 ms 9.00 ms -126.19 ms The summed actual-corpus medians were 2,258.664 ms for the old engine and 905.548 ms for Wikimedia (2.49x old/new ratio). This is a minifier-operation comparison, not a front-office TTFB claim. Brotli is N/A because neither a Brotli executable nor PHP extension was available. The 2 MiB stress cases completed successfully: 2 MiB case Engine Output Gzip Median p95 Peak memory increase JavaScript tbminifier 1,825,339 B 5,380 B 4,318.185 ms 4,663.861 ms 3,653,824 B JavaScript tbwikiminifier 1,827,104 B 6,916 B 1,429.121 ms 1,741.703 ms 1,832,024 B CSS tbminifier 1,592,317 B 4,708 B 913.665 ms 949.068 ms 24,349,888 B CSS tbwikiminifier 1,708,828 B 5,054 B 47.876 ms 57.636 ms 8,163,352 B Real HTTP performance The initial sequential cold runs intentionally regenerated provider-specific CCC assets. They are valid cold observations but vulnerable to time-order/environment drift. Cold homepage metric tbminifier tbwikiminifier New - old TTFB 617.120 ms 321.106 ms -296.014 ms Total 622.828 ms 327.096 ms -295.732 ms Provider-specific home bundles from those runs were: Asset tbminifier raw / gzip tbwikiminifier raw / gzip New raw / gzip JavaScript 316,517 / 90,378 B 315,520 / 90,271 B -997 / -107 B CSS 364,698 / 68,888 B 369,260 / 69,096 B +4,562 / +208 B The stronger warm comparison randomized 40 blocks (20 per provider) with 10 requests per block and seed 20260824. Both modules were installed once before measurement. All 400 requests used the same page, database/shop, warmed CCC bundle state, cURL handle, cookie jar, web-server pool, and OPcache pool. Only the shop activation row changed between blocks; no lifecycle method, module install/uninstall, or CCC clear ran inside the loop. The harness cannot force Apache to select the identical worker process for every request. Interleaved warm metric tbminifier (n=200) tbwikiminifier (n=200) New - old TTFB median 107.681 ms 106.630 ms -1.051 ms TTFB mean 108.977 ms 107.283 ms -1.694 ms TTFB p95 123.013 ms 120.897 ms -2.116 ms Total median 113.785 ms 112.257 ms -1.528 ms Total p95 128.607 ms 127.207 ms -1.400 ms Measured: both engines returned HTTP 200 for all 200 samples; response size was constant within each engine (18,361 and 18,363 bytes respectively); no transport retry was needed. Measured: before/after CCC versions remained CSS 21 and JS 21, with the same five bundle paths, byte sizes, and SHA-256 hashes. Every transition snapshot contained exactly the requested single provider. Inference: warmed front-office overhead is effectively equivalent in this environment. The small 1-2 ms Wikimedia advantage should not be generalized as a guaranteed production improvement. Browser, network, and visual validation Measured: home, category, product, search, CMS, cart, and checkout pages completed under both engines. Candidate product option selection, quantity change, add-to-cart, carrier change, and payment-option selection worked; no order was submitted. Measured: all candidate CCC JavaScript/CSS responses loaded successfully and parsed. No browser or PHP error unique to tbwikiminifier appeared. Observed in both baselines: the theme's external lite-youtube.min.js is an ES module loaded as a classic script (Unexpected token 'export'), and the theme bundle calls missing $.debounce. The latter prevented the mobile menu and absent search UI in both runs. These pre-existing theme defects are outside the module and were not hidden. Measured visual stable regions: mobile home was pixel-identical; product was pixel-identical; category changed 0.0607% of stable-region pixels with mean RGB delta 0.0357. Desktop home used different effective responsive breakpoints and cart contents were intentionally changed, so those pairs are retained but marked incomparable. The candidate product full-page image has a browser fixed-header stitching artifact below y=720, which is excluded from the stable region. Security and dependency review Measured: composer audit --locked and the production-only composer audit --locked --no-dev reported no advisories. The complete development graph reports abandoned marcusschwarz/lesserphp; it is transitive development-only benchmark code and is absent from the release. Production dependencies are Wikimedia Minify 2.11.0 and pear/net_url2. Measured: the repository security scan found zero reportable findings. Production contains no public controller, upload, SQL, shell command, eval, deserialization, remote include, outbound request, telemetry, source logging, or source persistence. Observation: developer benchmark/capture utilities are CLI-only and excluded from the release ZIP. Limitations and evidence retention Wikimedia's deliberate parser trade-offs remain: CSS source-looking comments inside quoted strings and JavaScript multibyte line separators in certain comment contexts can change content. These have regression documentation and are correctness concerns, not remotely exploitable module attack paths. Invalid CSS that does not make Wikimedia throw cannot always trigger fallback; valid CCC inputs remain a prerequisite. All JSON, CSV, Markdown, and screenshot results under build/reports/ are retained. Raw non-customer test-shop capture inputs under ignored build/captured/ are also retained for reproducibility and are excluded from the release package. -------------------------- I would invite everybody to test this new module. Simply uninstall the bundled minifier module and install this one. Test for visual bugs. The cold combined js and css files should take 2x less time to generate. Which I think is a huge win for FTTB for customers coming from SERPs directly onto your product/category pages. 3 times less memory usage is a bonus. Yes, our total combined css+js package becomes 3 kb larger but I doubt this is an issue with modern 5G and optical networks if our page is around 1 mb in total. tbwikiminifier-1.0.0.zip

Be extra careful when removing image formats here as every theme creates what is needed during install. Regarding speeding up image generation - if you're generating your images during manual product creation the only way is to increase the speed of your server (buy better VPS/server). If you are annoyed that image creation times out/is slow during product import - simply don't create the thumbnails during the import but later in a dedicated tab while you do other work. The image section got nice rewrite by @wakabayashi but in the end it has to regenerate the files. Also - don't use jpg, it's 2026. Switch at least to webp, avif is even better if your server/php version supports it. BEFORE you switch the image format and regenerate all images - make sure that your theme can work with the new formats. Take inspiration from Niara and see how you can pass the file extension dynamically. Backup, make the change, then regenerate all thumbnails (Images -> Reset status -> Regenerate all). This will not speed up your generation time but will speed your FO performance and speed score if you approach the quality conservatively.

The approach described by @DRMasterChief will not work on newer versions of thirty bees, intentionally. You can check if your tb_employee table contains column signature - if the column exists, you can't change the email/password in the table manually. You also need to change the value of column signature, but for that you need to know a secret that's not available to mysl. This mechanism exists to prevent attackers to elevate sql injections into complete access. If your store contained SQL-injection vulnerability (often caused by older third party modules), attacker could use it to change admin password, and then log in (basically the same mechanism described above). With the requirement to change signature as well, this no longer works. You can use force-login php script to log into your admin, see this post: You will have to: upload force-login.php file into your admin123xyz directory (every installation have different admin folder name) open url https://your.store/admin123xyz/force-login.php this will logs you in as an admin change password delete force-login.php script

Not over yet 😉

Yes, now drop the spam 🙂

OpenAI.. the company that is not ethical at all.. OK ^^ 😂 I banned them for all my usages.

I use "Email Templates Manager" module: https://addons.prestashop.com/en/email-marketing-automation/25939-email-templates-manager.html To build email templates compatible with module, use Emails SDK: https://github.com/PrestaShopCorp/email-templates-sdk Like any Prestashop module, this one has a lot of bugs and needs to be fixed first. The screenshots show a sample email and the email configuration in the module.

Hello thirtybees community, ours are: - https://www.duvalo.sk - https://www.hudobniny.net We rushed into production, so still tweaking some stuff.

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

I basically told Codex to use this and that local repo of Warehouse, upgrade FA to 7.2, use the shims and not make any changes to the actual usage of the font in the theme so I can check if the shim layer works. After I saw that the new icons are loading with the old code calling them (FA3 and 4) I asked it to inspect all the theme files and module and swap the code for the new formatting. The old font files light stay for the initial testing and you will have to put the new FO files where they are expected to be (I beleive in 7.2 they must be in /webfonts folder under theme's /css folder). After that the bot will merge the big global.css file with all the glyph mappings in the FA source css (necessary if you don't want to have an additional call to another css), this adds around 11k lines of css. The only issue I think I had was in FO -> My profile section one of the icons was not rendering properly so I had to change it to similar one in the new package. In total, around 2 hours with all the testing

restarting apache2 maybe?

The problem is that all templates and modules for PrestaShop 1.6 are not compatible with PHP 8. Templates for PrestaShop 1.7, 8, and 9 are not compatible with Thirtybees. Thirtybees is not very popular, so no one is creating templates for it: https://themeforest.net/search/thirtybees There are no templates for Thirtybees, so it’s not very popular. And so the vicious cycle continues.

@Madhosh i think you should urgently install the module in BO: Mail via phpmailer v.1.1.1 (this is the new module for E-mail transport and you need this)

You need to update your theme and remove dependency on polyfill.io This is how we did it in niara theme: https://github.com/thirtybees/niara/commit/3ab40e7ae52e0c495a2b67f09131996fb6ed65ea For your theme, it will be mostly the same - edit file header.tpl, find line with polyfill.io, and delete it.

In that case, screenshots wouldn't be helpful. We have them as standard and have only really integrated the logo well. By "adjustments," I meant technical ones, like placeholders or modified uses for standard themes (such as notifications about partial deliveries). We use a third-party theme for the shop and the relatively clean standard emails are quite suitable for it (thankfully).

Ok. I got it. This "0. Ignore this Column" is exactly what I need. Somehow I have forgotten all this. An there is even way to save what do You need. So there is no need to "play" every time what column You need to ignore. I use excel to make CSV. This way I can combine names because they vary, depends on functionality. And if there is 10 000+ items there's no way to edit all these by hand. Excel itself can't handle some specific symbols like Greek letters. So there are some formulas in on cell with 60+ variables. Also in my language there are letters that is best to give with CSV. And due to language peculiarity I need comma in description. So field separator is in my case semi-colon and for value separator I need to use this sign - &. Finally it is more confident to use Notepad2 where I can set encoding and line ending. I even don't dream that this is handy, but at least so far this all works for me. Anyway Big Thank You, if this is enough

Thank you so much for your swift reply and suggested solution, @datakick! Much appreciated! The override worked like a charm! @DRMasterChief We didn’t try to do anything. It just happened from "one day to the next". I’m guessing we suddenly reached some kind of threshold. However, our store has been through a few facelifts. In some miraculous way, we’ve managed to upgrade from PS 1.4 all the way to TB 1.7, so who knows what kind of calls, requests and mysterious potions and bombs are being made. This is one of the reasons I mentioned the cleanup module as well. Would it be a wise move to run it, or is there little to gain here? And as a side question: Fiken is one of the most popular accounting apps in Norway for small businesses. I believe only WooCommerce and Shopify has a more or less seamless plugin/module for it. Could this be something for ThirtyBees - targeting the TB solution with a fiken module solution towards Norwegian customers? I know for a fact our accountant would love such a solution, so if you think this might be something, let us know, and we will chip in with fundings and other information you should need. All the best,

Hi @led24ee @led24ee No, the project is not dead. And Petr is still around - he's just working on things that are not currently committed to GitHub, but will be in the future. Yes, we only have 1 core developer, and the concerns you have, imo, are valid - which is something we've been wanting to change for a long while. We've been trying to drive "support Thirtybees" campaigns, so we can boost funds and hire more developers and hire some of us full time. Which will result in a massive injection of energy and improvements and new life for ThirtyBees. Unfortunately, it's been a bit of a struggle as I'm sure you've seen with our reminder posts or mentions on the topic from time to time. Chicken and egg scenario, and that is the truth. That being said, there is movement albeit slow, and there are plans, and eventually (hopefully soon), you will see more movement and obvious progress. But yes, more support will be beneficial for ThirtyBees. Don't give up on us yet - see what you can do to help, and hopefully we can all see an improvement soon. Thank you You can DM me directly if you need an email answered - I will share Smile's email address.

Database, PREFIX_employee table, campaign_disabled field. Set the date 100 years in the future.

Hi there Thank you for your post, and welcome to ThirtyBees. We literally have thousands of stores running, so you're not alone. TB remains one of the best and top eCommerce platforms out there. It's stable, it's fast and it's awesome. It's the best PS that PS could've been - and better! So it may still be a good choice for you. About your comment about TB going the same route as PrestaShop. The reason PS went down this slow and painful dead-end is due to corporate greed and dark-side behavior; where they would literally take what was free before and lock it behind a paywall; not to mention not giving a sh*t about their client base and what was good for PS and going symphony route. Which hurt them badly. Many of these reasons are why TB exists in the first place. And it's for that reason that we are unlikely to go down that specific path and "fail like PS did". However; our very nature (being good, doing it for the community, hoping for the best) may be our undoing. And we may fail anyway. As simply closing our eyes, crossing our fingers, and hoping that people who love the software will signup for memberships or make a donation - to make TB better, get more developers, make more themes, do more marketing to pull in more customers etc. Wishful thinking on our part? Maybe you're right. Maybe we should start charging entry. Maybe people would stop being indifferent then. And if people feel strongly about what I just said, even if it made them upset, then well, they know what to do: