All Activity

@DRMasterChief What you want to implement in your store doesn’t require any changes to Thirtybees or any additional modules. You want a button that links to a contact form where the customer must submit a request to cancel their order. Just add a link or button anywhere in your store that leads to the standard contact form, and that’s it. And since this solution has nothing to do with the functionality of the "Cancel order" button, has no integration with the store, and doesn’t automate any actions in the store (such as automatically changing the order status), that’s a different matter. What you’re proposing is just plain old email writing. The customer has to write an email providing all their details, then the store staff has to read that email and take some further action on the order. And this whole "canceling orders without logging into the customer’s account" thing is total nonsense. Hackers will be canceling all the orders in the store every day. There are no safety measures in this solution. Here’s an example of how it’s done in WooCommerce: https://woocommerce.com/products/customer-order-cancellation-for-woocommerce/ The customer logs into their account, sees a list of their orders, and on that list there’s a "Cancel order" button—they don’t have to spend an hour filling out confusing forms where they have to provide all their personal information. In my module, I implemented this as follows: the "Cancel order" button is always visible in the store's navigation bar; when the customer clicks it, they are taken to their order list and can cancel the order with a single click. In the module’s configuration, you can exclude order cancellations for virtual products and customer personalized products; by law, such products are non-returnable. When the customer clicks the "Cancel order" button, the order status is automatically changed to "Order canceled". Many electronic payment gateways offer automatic refunds when the status is changed to the one specified in their configuration—in this case, we achieve 100% automation of store operations that require no action from store staff.

The module I'm using implements the contract withdrawal request button in the details of the order just completed (see attached screenshot). Therefore, the consumer will immediately find the button to access the contract withdrawal function in the details of the order just placed. It's already there, ready to be used. The login, which you see as a complication, will only be necessary to return to the order details at a later time and is an essential requirement (required by other regulations and directives) to ensure the appropriate level of confidentiality and security of the system in use. Avoiding the login to an e-commerce site that provides a personal customer area that collects personal and sensitive data would violate other equally stringent and stringent regulations, not only in Germany, such as the Privacy Act. I repeat, therefore, the login cannot be seen as "a complication to access the procedure" but as a "conditio sine qua non" due to the Privacy Act. exactly what is provided for in Article 11a of the law.

ok, so you are fine. It´s not my idea. The regulation says in point 37 regarding implementation: ....For example, the consumer should not have to undertake procedures to find or access the function.... So again my question: is a login an additional "procedure" to access this function? Please answer this question for yourself. In my opinion, it's at least one more step than simply clicking the first button or link, so it is. But perhaps we simply have to wait until June to see how this plays out. In Germany, we have the specific problem that lawyers can send out cease-and-desist letters, which are very expensive. This isn't the case in all countries, so perhaps that's why you're not so sensitive about it. Yes, unfortunately, this makes us very "anxious" in Germany, and online shop owners are often treated like serfs.

I don't support the module. I bought it, it works, it's cheap, it fully complies with the regulations, and I'd like to share it with anyone who wants to use it, nothing more.... What I don't understand, however, is your insistence that login is an "obstacle" or at least not compliant, since no part of the regulation states this. Furthermore, without login, it would be even more complicated for the customer to provide their order information... with login, everything becomes automatic... just one click. exactly what is provided for in Article 11a of the law.

Hi, https://www.prestatoolbox.com/free-prestashop-modules/481-deadman-switch-auto-catalog-mode.html

I understand if you want to support the module for your own reasons... but that's no reason to be so pushy. As already mentioned, requiring a login could be seen as a hurdle > it's not entirely clear yet; time will tell. However, I don't want to be a guinea pig and have to pay for it. 🙂 The explanations in point 37 of the regulation provide further clarity regarding implementation: ....For example, the consumer should not have to undertake procedures to find or access the function.... Is a login a "procedure" to access this function? Please answer this question for yourself. I just find it problematic to offer a module that might not take this into account and tells the customer it's 101% compatible with the regulation, because I don't think it is or it is not clear yet. But it's everyone's own decision. We'll probably find different solutions, and that's why we're here, not to quarrel.

[email protected] ...They are the best in my personal experience.

exactly what is provided for in Article 11a of the law.

@Yabber no absolutely not - and even if that were the case, it is exactly what is sufficient. 🤒 Do you have read any of the papers? And what about the opinions and recommendations of chambers of commerce, lawyers, etc.? I almost don't think so... You also haven't read my ideas on this, and yes, of course, it can be implemented in different ways, but I still want to keep it at the most minimal level. This needs to be implemented, and that's enough work and expense for most retailers. I won't be adding any extraordinary service levels. Please explain how you see this and how you will implement it. Then carefully check off the checklist to determine if and how the EU requirements are met.

@DRMasterChief What you're trying to do has NOTHING to do with a quick “Cancel Order” button. It's just a link to some confusing contact form where customers have to spend an hour writing out lengthy requests.

I won't be performing any customer validation beforehand, as the policy doesn't require it. To prevent spam, I'm integrating Cloudflare Turnstile. If any "fake" customers misuse the form, it's just one more email we have to delete. But emails with the subject "cancellation" have to be processed or at least briefly reviewed anyway. A more automated solution isn't an option for us, as we only accept orders in the shop, and all further handling, delivery, invoicing, etc., is done in an ERP system. The form includes: Name, email, order number, and an optional text field for customer notes (e.g., to cancel only some items). That's sufficient for processing. We'll see whether we need to add another interface to the ERP system later (the number of returns is simply too low to justify the cost, thankfully). I'll place the link to the form in the "My Account" section, highlighted in color, so it's accessible from every page. There's plenty of space there, and it looks good and is easy to find. The emails to the customer are equally simple; they contain exactly the information they entered in the form. I'll also include the date and time (because that's required by the regulations), as the email header apparently won't suffice. There's still time before the deadline. I've already started working on it and can finish it within a few hours.

I also have probably under 0.5% cancelations/returns. That's why I don't know (or care) about the exact numbers. How do you envision the validation before the customer/guest clicks on the 'withdraw contract' button? Guest tracking is only for guest orders - if you try to check your customer order, there is a message that shows that guides you to log in to your profile and proceed with tracking there. Withdrawal period could be easily configured from the day 'Delivered' status is set for the order. Let's say your T&C state 30 days returns - you set 30 days and after that the button is automatically hidden. If you have partial deliveries, mark the order Delivered after you have delivered the last item in it. The first ones will have a longer period, but I doubt any business will go bankrupt because of that option. And altogether this button is valid for the whole order, not for part of it, so the customer could choose to receive/keep or cancel/return all items.

Hi, it is clearly stated: The withdrawal function shall be continuously available throughout the withdrawal period. Even if the button is displayed after the withdrawal period has expired, this is not a legal problem. There is no reliable technical way to calculate the withdrawal period in the shop. It depends on many factors, such as partial deliveries or whatever period the retailer voluntarily grants. The details of a partial cancellation of a larger order are not addressed in the EU directive. Thank you for that 😞 If a reliable way can be found to link the withdrawal period to the withdrawal period, that's fine. Please do so. However, if there is only one instance of an incorrect withdrawal period, it is not good for the retailer. The permanently displayed button naturally carries the risk that it will be used even after the withdrawal period has expired. However, this is not a problem; the withdrawal is then invalid. The retailer will have to check this in any case and inform the customer, etc. Then he has to inform the customer that the cancellation was received after the deadline, but this is no different from before, or if a customer still cancels by email. Just expose your guest tracking controller with a link in the footer for all guests, and that should suffice. >> Yes, that's true, but guests and logged-in customers can use it, except that the login process is (possibly) displayed afterward. This could be seen as an additional hurdle by logged-in customers > not good. I'm not sure if it's clear what I mean by that point? With all this in mind, I have to say that we actually don't have any cancellations/returns. Maybe I'm oversimplifying things? We simply have to implement it; only one customer will use it per year. But please let us discuss here further!

I continue to think that your tesis of 'available everywhere' is not needed. The document clearly states - 'make the process not harder than ordering'. For registered customers: They have to register an account -> checkout If they want to make a withdrawal -> log in to your account -> find the order in order history -> click on two buttons -> the process (manual or automatic) is triggered. For guests: they can order with just entering their data (including email) -> checkout If they want to make a withdrawal -> use Guest tracking controller -> enter the order number and email (same level of validation as when ordering) -> use a button on this page with the same effect as if a registered customer. Just expose your Guest tracking controller with link in the footer for all guests and this aspect should sufice. If you just make a new controller and put it in the footer, you will still have to have some sort of validation - you can put only the order reference field there, but I think this would not imrpove the process.

Thank you very much for the additional information. However, there seem to be differing opinions or different laws depending on the EU country. It appears that the EU regulation is then transposed into national law in each country. In Germany, the situation is such that the button must be clearly visible at all times, from anywhere (possibly highlighted in color). A login could present an additional obstacle and is therefore not permitted. A login is only allowed if ordering can only be done with a login. This likely doesn't apply to most shops, as almost all of them allow guest checkout. See my link, which is in English and explains all the guidelines for implementation in Germany. The same applies to several other EU countries, so Germany isn't alone in this. This concerns the amendment to EU Directive 2023/2673 on the introduction of the right of withdrawal (for goods deliveries). I absolutely cannot see in this that the shop operator has to provide a solution in which the customer can identify the contract (i.e., select their order in a login process). It is perfectly fine if the customer simply enters the order number in the withdrawal form. That's why I initially wanted to know how to implement such a button and now we can clearly see that most of the solutions will bringt this into the footer. I wish your module were suitable for me, but after all this and a checklist, unfortunately, it isn't. This is the official document and you can choose every EU language: https://eur-lex.europa.eu/eli/dir/2023/2673/oj (main thing is Article 11 a) and it explains in detail what is necessary (and what is not necessary, or what we as retailers do not need to represent).

Hi. Directive (EU) 2023/2673 does not require the withdrawal button to be accessible without logging in. The directive (which amends Directive 2011/83/EU) introduces the requirement for a "digital withdrawal function" that must be: easily accessible clear and visible simple to use equivalent in simplicity to the purchasing process Key point: Contract identification The regulation requires that the consumer be able to: identify the contract (order) send the withdrawal declaration In practice, this means: access to an area where the order is recognizable (order history - order details) This module does all of this and is therefore fully compliant with the regulation. What the module does is indicated in the module description in https://psitsolution.com/tools/en/thirtybees-ps-mandatory-withdrawal-button-module The Thirtybees PS Mandatory Withdrawal Button module implements a digital function that allows customers to easily exercise their right of withdrawal directly from the store's personal area, as required by Directive 2023/2673 on withdrawal from online contracts. The module records the request, sends a confirmation email, and makes the request visible in the merchant's back office for management, as required by the new regulation. This module adds a withdrawal request button to the order detail page in the customer account. When the customer uses this feature: a confirmation page is displayed identifying the relevant order; the customer confirms the withdrawal request through a dedicated button; the request is recorded in the database including key data (order, customer, date and IP address); a confirmation email is sent automatically; the request becomes visible in the module back office. In the back office, the merchant can review all withdrawal requests and access the related order directly for easier processing. The module is designed to provide a simple and transparent withdrawal process for customers while maintaining a reliable record of all requests for the merchant.

Hello, thank you for the information. Please provide us with some more details. The product images are unfortunately difficult to see. How are guest orders handled? According to regulations, a login should not be required. The button must always be easily accessible and available. You mention refunds several times. Is this process implemented, or are you only referring to the cancellation request? An automatic refund would be problematic for the retailer and is not required. Additionally i found an actual paper with a lot of pratical help and hints, which explains a lot of questions which was earlier in this post here (e.g. place it in the footer...), please find it: https://www.noerr.com/en/insights/implementing-legislation-for-the-withdrawal-button-published

hi. the mandatory withdrawal button is a new legal requirement in the European Union (Directive 2023/2673), effective from 19 June 2026, designed to make it as easy for consumers to withdraw from online contracts as it is to conclude them. More details here: https://psitsolution.com/tools/en/info/eu-directive-eu-20232673-of-2023-mandatory-withdrawal-button-from-june-2026 It might be useful: the thirtybees module to implement and comply with the new legislation can be found here: https://psitsolution.com/tools/en/thirtybees-ps-mandatory-withdrawal-button-module

I have been using the free versions of Google Gemini and Microsoft Co-Pilot and am somewhat impressed. Since I'm retired and just do some stuff as a hobby I don't do enough development work to justify paying for a plan. I prefer Gemini since it can "see" the tabs I'm working in. Sometimes it gets stuck in a circular loop that makes the same mistakes when I am trying to debug an issue or it breaks something the was working when it makes a change, and will make the same mistake more than once. In general it is much more efficient than I am. I used Co-pilot to help Gemini solve one of my circular loop debug efforts and it corrected Gemini on the first try. I feed that output back to Gemini and moved on further in my regression testing. I copy and paste between the AI and my source as it has no direct connection to the source. I gave Gemini a set of ground rules and frequently tell it to go back and redo complying with the rules, otherwise it starts changing stuff I did not want touched. Here are some rules I gave it to adhere to when generating or updating my code: The mandatory ground rules found in the testing document are as follows: 1. Preservation of Comments: Preserve any comments or annotations in the existing code. 2. No Unauthorized Optimization: Do not optimize or change any existing code. Suggestions can be made for acceptance or rejection. 3. Patch Formatting: When providing a patch, specify the line before and after the patch for easy location. Use /** START xyz Change **/ as the first line and /** END xyz Change **/ as the last line for inserted code. These may be removed during final cleanup. 4. Incremental Updates: Perform updates one function at a time and ask for permission to proceed to the next item to allow for testing. 5. Source Code Requests: Request the source for whatever is being updated if it was not already pasted. Use that source for the update unless instructed otherwise. 6. Debug Output Encapsulation: All debug output support, which may be done in a production environment, must be encapsulated using the cm_is_super_admin() function to isolate the display. An example provided is: PHP /** START DEBUG ENCAPSULATION **/ if (cm_is_super_admin()) { /*** DEBUG PLACEHOLDER BELOW ***/ echo "<br>". __LINE__ . " data:<pre>" . print_r(array_keys($data), true) . "</pre>"; //DEBUG /*** DEBUG PLACEHOLDER ABOVE ***/ } /** END DEBUG ENCAPSULATION **/

For those who don't know yet, the mandatory withdrawal button is a new legal requirement in the European Union (Directive 2023/2673), effective from 19 June 2026, designed to make it as easy for consumers to withdraw from online contracts as it is to conclude them. More details here: https://psitsolution.com/tools/en/info/eu-directive-eu-20232673-of-2023-mandatory-withdrawal-button-from-june-2026 It might be useful: the thirtybees module to implement and comply with the new legislation can be found here: https://psitsolution.com/tools/en/thirtybees-ps-mandatory-withdrawal-button-module

2.10.2 - 03/16/2026 Fixed combinations never being exported even when the option was enabled Fixed meta titles/descriptions never being used in export even when the option was enabled Fixed out-of-stock products never being excluded even when the option was enabled Fixed purchase price (cost_of_goods_sold) fallback for combinations without wholesale price Fixed images being progressively lost for combinations without specific images Fixed shipping cost calculation receiving malformed price data Fixed export language silently falling back to wrong language for unknown countries Fixed AJAX date refresh crashing when no export file exists for a country Fixed PHP 5.6 compatibility (removed public const and type hints) Fixed feed URL generation on Windows servers Improved security on debug controller (strict comparison) Removed obsolete debug controller Fixed wrong flag displayed by default in categories tab 2.10.1 - 01/27/2026 Fixed a bug in stock export Fixed a bug with selecting custom product IDs Fixed a bug when exporting Cron to other modules

2.10.2 - 16/03/2026 Les combinaisons fixes ne sont jamais exportées, même lorsque l'option est activée Correction d'un problème où les méta-titres et méta-descriptions n'étaient jamais utilisés lors de l'exportation, même lorsque l'option était activée Correction d'un problème : les produits en rupture de stock n'étaient jamais exclus, même lorsque l'option était activée Solution de repli avec prix d'achat fixe (coût des marchandises vendues) pour les combinaisons sans prix de gros Correction d'un problème entraînant la perte progressive d'images pour les combinaisons ne comportant pas d'images spécifiques Correction du calcul des frais de port en cas de réception de données de prix incorrectes Correction d'un problème où la langue d'exportation basculait automatiquement vers une langue incorrecte pour les pays inconnus Correction d'un plantage lors de l'actualisation de la date via AJAX lorsqu'aucun fichier d'exportation n'existe pour un pays Correction de la compatibilité avec PHP 5.6 (suppression de « public const » et des indications de type) Correction de la génération d'URL de flux sur les serveurs Windows Sécurité renforcée sur le contrôleur de débogage (comparaison stricte) Suppression du contrôleur de débogage obsolète Correction d'un drapeau incorrect affiché par défaut dans l'onglet « Catégories » 2.10.1 - 27/01/2026 Correction d'un bug dans l'exportation des stocks Correction d'un bug lié à la sélection d'identifiants de produit personnalisés Correction d'un bug lors de l'exportation de Cron vers d'autres modules

3.8.2 - 03/16/2026 Fixed a bug where the modal window would not open when clicking the button after a product variation change Improved back-office information page layout Fixed XSS vulnerabilities in the contact form processing Added product link validation in the form submission Fixed product cover image error handling when image is unavailable Added missing product variation field in the PrestaShop 1.6 form template Code quality improvements and coding standards compliance

Hello, Petter, we can help with Thirty Bees migrations. Our team has been working with PrestaShop and Thirty Bees for more than 10 years and we regularly handle migrations from different platforms and older PS versions. If you are interested, send us some details about your current shop (number of products, modules, customizations, etc.) and we can take a look. Email: [email protected]

Hi! Are there any experienced Thiry bees developers here who can undertake paid work with upgrading to Thirybees from Prestasop 1.6.24?