All Activity

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

Its completly sick, what you already achieved without writting code your own 😅

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.

@vincentdenkspel amazing! 😏 Don't forget: be careful. I would always recommend to work with testshops at least. Also try to learn some basics (in case you don't know anything right now). But in general this so cool. Keep going! @30knees This was my first guess too. But we might be wrong. It could actually be, that thirty bees is a winner of this. We have an open architecture here. It's accessible for all AI tools. And the system itself was built for extensions/moduls.

Why not ? I'm not a developer. I just completed a giftcard module completely ai generated (claude sonnet 4.6). I'm still testing it, but as far as I can the functionality I wanted works. (including correct VAT calculation) How the module works: - Create a set number of gift card numbers. - Export the numbers to a CSV file for printing the gift cards. - Create a regular product (gift card) with 0% VAT. - Customer buys the product. - Link a gift card to the order. - Email the customer the PIN code. - Once the customer receives the physical gift card, they activate it with the PIN code on a special page. - After activation, the card can be used as a payment method. ----- GiftCardPayment — ThirtyBees Module Version: 1.0.0 Author: denkspellenparadijs [with assistance from Claude Sonnet 4.6] License: MIT Compatibility: ThirtyBees 1.6.x | PHP 8.0+ 📋 Description The GiftCardPayment module adds a complete gift card system to ThirtyBees webshops. Customers can use physical gift cards (with unique code and PIN) as a payment method — either fully or partially. In case of a partial payment, the remaining amount is automatically charged via the configured payment provider (Mollie or bank transfer). ✨ Features 🎁 Physical gift cards with unique codes and PIN protection 💳 Two-step payment flow: gift card + remaining amount via PSP 🔌 PSP-agnostic: works with Mollie and bank transfer (extendable with custom adapter) 🧾 VAT-correct handling for partial gift card payments 🏭 Bulk generation of gift cards via admin 💰 Balance check via frontend widget 🔗 Activation via email — customer activates card via personal activation link 🔒 Blocking after too many failed PIN attempts 📊 Full transaction history per gift card 🔒 Security PIN codes are stored as plaintext and as BCrypt hash (for validation) CSRF token validation on all AJAX endpoints Rate limiting on PIN attempts Cryptographically secure secure_key generation via random_bytes(32) 📦 Installation See INSTALLATION.md for full installation instructions. Quick install: 1. Upload giftcardpayment_v1.0.0.zip via Modules → Upload a Module 2. Install the module 3. Clear the cache ⚙️ Configuration After installation: 1. Go to Modules → GiftCardPayment → Configure 2. Set the payment provider (Mollie, Bank Transfer, etc.) 3. Set the validity period (default: 24 months) 4. Set the maximum number of failed PIN attempts (default: 3) 📁 Structure giftcardpayment/ ├── classes/ # Core classes │ ├── GiftCard.php │ ├── GiftCardTransaction.php │ ├── GiftCardCart.php │ ├── GiftCardOrder.php │ ├── GiftCardPartialPayment.php │ └── providers/ # PSP adapters │ ├── MolliePaymentProvider.php │ └── BankWirePaymentProvider.php ├── controllers/ │ ├── admin/ # Admin controllers │ └── front/ # Frontend controllers ├── sql/ # Database scripts ├── views/ # Templates ├── translations/ # Translations ├── giftcardpayment.php # Main module file ├── config.xml ├── CHANGELOG.md └── INSTALLATIE.md 📝 Changelog See CHANGELOG.md for the full version history. 📄 License MIT License — free to use, modify and distribute with attribution. Developed by denkspellenparadijs with assistance from Claude Sonnet 4.6 (Abacus.AI / ChatLLM Teams)

As for the “Guest Shopping” order mode, this option is not compliant with all EU directives on personal data protection and consumer rights: - the customer has no access to their personal data stored on the store's server, - the customer cannot edit their personal data, - the customer cannot submit a “right to be forgotten” request, - the customer cannot return purchased products (they must convert their guest account into a standard customer account). In addition, the “Guest Shopping” order mode is a terribly customer-unfriendly option. Customers have to laboriously fill in dozens of their personal and address details with every purchase. So if someone uses the “Guest shopping” mode in the store, they don't need the “Cancel order” button, because one more or less crime doesn't make a difference.

Agree. But not just for development. I think it will also change shop systems. It might be that systems like Shopify will benefit more than standalone systems because of their data advantage.

I actually came across a case where something very similar was being complained about. It's not about a cancellation for goods, but rather the long-standing law regarding cancellations for subscriptions or financial services, etc. It concerns an offer from HP: (please use the translation for you language) https://www.bundesjustizamt.de/DE/Themen/Verbraucherrechte/VerbandsklageregisterMusterfeststellungsklagenregister/Verbandsklagenregister/Unterlassungsklagen/Klagen/2025/282/UKlag_282_2025_node.html

Canceling an order is not the same as returning an order—they are two completely different processes. >> I understand the regulation to mean that cancellation must be possible via a button, regardless of whether the order is partially or completely canceled. As already mentioned, the return process (if goods actually need to be returned) is then handled separately and manually or through some other automated method. This doesn't affect the required cancellation button; that's a separate issue. As you wrote, in such cases, the customer has to follow the standard return process, but that's precisely what they initiate with the cancellation button (but only the first step). Whether the retailer then (automatically) sends a return label, etc., is independent of this and must be considered separately (or it's a much larger, more complex solution with associated costs, as I've already mentioned). A customer who has no information about their order is not a customer. >> I understand that, but that's not the point the regulation stipulates. Thank you so much for your contributions. Let's continue to think about this and find solutions. I'd like to add something regarding guest tracking, specifically the issue of the unsubscribe button not being easily and clearly visible to everyone: I think this alone will cause problems or legal warnings. We would then have to explain to "the world out there" that the button exists, but is only accessible with some difficulty. That's precisely what the law doesn't want... How exactly this should be resolved isn't entirely clear at the moment. That's precisely why I had the idea to make the button clearly visible and always accessible at the beginning of the regulation. If, after some time, there are court rulings and experience with them, it can potentially be adjusted so that it can be moved to the customer menu.

I don't understand why everyone in the PrestaShop forum seems to think this is so terrible.... bla bla. I would take massive legal action against the provider, meaning multiple official reports to the data protection authorities in every country where a forum member resides. That's the intended course of action, that's all there is to it. It should be noted that payment data is also affected. There's no room for "oh, what a shame, blah blah," but rather, hard facts must follow.

I like your approach for the guest customers. But here is what I think this law makes the waters very murky - I don't think it specifies certan cases of which statuses should be excluded from this option. I think it applies to all orders (probably even non considering download/digital products) - i believe it just upgrades the standard RMA and has to stay on top of it. So if you're using RMA, this button simply triggers the proces so you don't force your customers to manuall fill forms, send emails, etc. The moment where the customer would like to return (cancel/withdrawal) only part of the order is easily achievable by a table with all order products on the confirmation page and preselected checkboxes next to them. If they want to cancel the whole order, they simply have to click confirm. If they want only part of it - make the appropriate selection. But of course, this after that has to be wired to the current RMA process. How hard would it be - I don't know because I currently don't use it. IMHO the button should not be in the footer - it has to be in the profile of registered customers or as Yabber said in their guest tracking so there is at least some level of authentication. If the customer made a registration it is just as simple to cancel their order in their profile and this is the purpose of the law - 'order with one button' and 'cancel with one button'. Same with guest customers.

Canceling an order is not the same as returning an order - they are two completely different processes. A customer who has no information about their order is not a customer. Can you log into your bank account without any login information? You can't make this feature so that hackers from all over the world can cancel all orders in our store. This is my own module running on the displayOrderDetail hook - it is visible in standard customer and guest orders. The screenshot shows a simple configuration of the module. Of course, for orders that have the status “Order shipped” or “Delivered,” there can be no question of canceling the order. For such orders, the customer should make a standard return after receiving the shipment.

Such a leak of customer data could result in huge fines for Prestashop. This is probably why the previous owners sold Prestashop so quickly.

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 🫣

Wtf. If this statement is true... 😵 Probably they are afraid of lawsuit against them.

There are certainly various possibilities, but the law provides clear rules. Of course, this also applies to guest orders. How do we handle it if not all items are returned? Is this sufficient in this form, or does it comply with the law? The button must also be accessible to customers who no longer have a confirmation email, who can't log in, etc. Thus, they also can't access the guest tracking information. And I don't think a cloned contact form requires too much information. As already mentioned, name and order number are actually sufficient. @Yabber What solution do you actually use (shown in the picture)?

@DRMasterChief It won't be a "Cancel order" button, but a confusing contact form where the customer has to fill in dozens of pieces of information. This was certainly not the intention of the creators of this law. The customer clicks on the "Guest Tracking" link and sees a single "Cancel order" button, which changes the status of the order in the store to "Order canceled". And that's it.

Nice module idea — integrating WhatsApp chat can really help shops connect with customers quickly in real time. Just be sure to use a safe version like GB WhatsApp resmi or the official WhatsApp so chats are reliable and secur

Hello, thank you for your input. I have read several papers from lawyers and from the Chamber of Commerce. My concrete ideas are: we need to have a withdrawal button next to each order for the specified withdrawal period (by law or if extended by our policies) >> No, I don't want to make it that complicated, and there's no legal obligation to link it to the cancellation period. It's mandatory that the customer must be able to easily access the cancellation button anytime, anywhere (just like the legal notice). And it's important that they don't have to be logged in! It must be accessible to the customer even without logging in (e.g. for guest customers and if you have forgotten your password, it must be hold super simple for the customers). Of course, a customer could then press the button even after the cancellation period has expired, but the right of cancellation is quite clear about that, and once the time has passed, the cancellation is no longer effective (or, as a retailer, you can handle it however you like). However, I definitely want to avoid a very complicated implementation in the back office and don't want to automate any checks using back office data. The cancellation button must always be visible on the front end anyway. we should lead the customer to another page where they can confirm the request of withdrawal >> Yes, but easily accessible. I would therefore like to simply place the cancellation button in the footer, where information about shipping costs, legal notice, etc., is also found. The refund process does not need to be initiated simultaneously, nor does it need to be started digitally. This is generally covered by the right of withdrawal or the retailer's terms and conditions. we should send them email with the details of the withdrawal request >> Yes, a very simple confirmation that the cancellation has been received is sufficient. I believe that the retailer will then check it manually anyway. If you are a large retailer who has to process many returns a day, you will have a different, expensive solution programmed including payment management etc. We should have this solution simple and easy for smaller retailers. My specific idea is therefore to clone the contact form including the controller (with a new name). It already includes everything necessary: The subject selection function (customer service, etc.) should even be deleted. The heading should be renamed "Cancellation." The submit button must also be renamed, and a new email template should be created, which will then be automatically sent (by the cloned Controller) to the customer and the retailer. It is of course necessary to have a field for the customer's name and email address, as well as the order number if applicable. You might also want to include a field for the postal code to ensure consistency with the customer data and prevent misuse (however, this presents a legal hurdle). On this cancellation form, we can include a fixed text so that the customer automatically declares their cancellation. It may be helpful to add a free text field so that the customer can indicate if they are only cancelling part of the purchase. Just like with the contact form, you should probably include Turnstile (or another Captcha) to prevent the form from being misused by bots.

Hi @DRMasterChief, Can you describe what you want to achieve? I reviewed few online articles and the information I get is: we need to have a withdrawal button next to each order for the specified withdrawal period (by law or if extended by our policies) we should lead the customer to another page where they can confirm the request of withdrawal we should send them email with the details of the withdrawal request I think the best implementation would be in BO: In Preferences->Orders - a value in days to specify the withdrawal period and a switch to display or hide the withdrawal button in FO-> order history In FO: In My Account-> Order history right after the current buttons we place new column with the withdrawal button, after that we take the customer to a confirmation page and after confirmation we send out a withdrawal confirmation email. After the request is recieved it gets little bit messy. Probably we will have to track those requests in separate BO controller and process them there. Or we simply receive a message with the order ID and we apply appropriate actions depending on it's current status (we contact the customer to return the products, cancel the order if not shipped, refund money, etc.). But then what happens with their personal data? Should we also obfuscate it as part of the process? Sources: https://www.heuking.de/en/news-events/newsletter-articles/detail/new-cancellation-button-what-companies-must-implement-by-june-19-2026.html https://eur-lex.europa.eu/legal-content/EN/TXT/PDF/?uri=OJ:L_202302673

Hi everyone, Has no one really looked into this yet? It's coming into effect across the EU in June. I can't believe no one has started working on a solution yet. I think a paid module for this is overkill, especially since you can easily put together your own solution. Or perhaps offering a small paid module / code solution would be a good option for ThirtyBees, considering future financing, etc. @Acer Here's my post in the German forum, where I'm already working on a solution: Widerrufsbutton - Deutsches Forum - Generelle Fragen - thirty bees forum

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 @nicponim We've added your site. Nicely done, thank you 👍 https://thirtybees.com/powered-by-thirty-bees/shops-using-thirty-bees/

To clarify, we do have full time employees. Some of us are volunteers that are working on TB part-time. The point is that we require additional support to have more full time employees to make TB better and deliver additional features faster.

TB should invite more to their project, over time workload increases. There are volunteers here.