All Activity

Kurz zur Klarstellung, hier als schnelle grafische Übersicht, damit wir hier sehr gerne über die technische Umsetzung weiterdiskutieren können. Es sind zwei Labels (das eine ist eigentlich eine "Mitteilung", daran erkennt man schon daß die immer erfolgen muss) die eindeutig verschiedene Zwecke und Anforderungen haben. Richtet sich das Verkaufsangebot innerhalb Deutschlands dann müssen natürlich die Labels mit deutscher Sprache genutzt werden.

For a Thirty Bees store, a good Bulk Email Sending Service Provider should offer easy SMTP setup and steady inbox delivery, and it helps to send marketing emails from a separate subdomain. DigitalAka™️ is another Bulk Email Sending Service Provider you can compare with Brevo or Sender.net if you want setup help along with sending. Before you switch, check that SPF, DKIM and DMARC are set up, and send a few test emails to Outlook and Gmail.

4.1.0 - 10/07/2026 New feature: New "Products" tab: keep a product out of the Google feed without touching its visibility on your shop, for bulky items, thin margins or references a platform keeps refusing Fixed: The public title of a promotion is now one per language. A single wording used to be sent to every market, so filling it in made a multilingual shop lose the translations it already had through the cart rule name Titles saved before this version are kept and moved to your default language The Promotions tab only offers the languages of your configured feeds, and shows under each empty title the cart rule name that will be used instead in that language

4.1.0 - 07/10/2026 Nouvelle fonctionnalité : Nouvel onglet « Produits » : gardez un produit hors du flux Google sans toucher à sa visibilité sur votre boutique, pour les articles encombrants, les faibles marges ou les références qu'une plateforme refuse Correction : Le titre public d'une promotion est désormais propre à chaque langue. Un seul libellé partait vers tous les marchés, si bien que le renseigner faisait perdre à une boutique multilingue les traductions qu'elle avait déjà par le nom de la règle panier Les titres enregistrés avant cette version sont conservés et placés dans votre langue par défaut L'onglet Promotions ne propose que les langues de vos flux configurés, et affiche sous chaque titre vide le nom de règle panier qui servira à sa place dans cette langue

Ja klar, ist auch eine gute Information. Nach derzeitigem Stand ist jedoch nur die Info in einem CMS nicht ganz so ausreichend... es muss deutlich sichtbar vor Abgabe des Kaufwillens sichtbar sein, d.h. wie man es dreht und wendet bleibt fast nur irgendein Step im Checkout übrig... Das Gewährleistungslabel darf (aktuell noch) auch nicht ausklappbar, ausgeblendet etc. sein. Wir haben die Anzeige drin direkt nach Auswahl "payment option", ergänzt mit einem kleinen Hinweis daß es eine gesetzliche Pflichtinformation ist. Ggf. verwirrt es die Kunden dann die ersten Wochen etwas weniger. Der große Unterschied ist da eben bspw. zum Garantielabel, das darf nämlich ausdrücklich (halb) ausgeblendet sein usw.... und die Angaben zur erweiterten Garantie wenn mehr als 2 Jahre müssten dann sogar im Warenkorb erscheinen und in der Bestellbestätigung sichtbar sein. Das ist dann schon mehr Aufwand.

Hey @DRMasterChief da ich mich zu dem Garantielabel nicht so sehr informiert habe, kann es wohl sehr gut sein, dass ich die Anforderungen mit dem Gewährleistungslabel vermischt habe. Trotzdem wollte ich nur vermitteln, dass man für das Gewährleistungslabel nicht zwangsläufig das Thema (.tpl dateien) anpassen muss.

Hallo @Bird der Aufwand ist sehr unterschiedlich. Für das Gewährleistungslabel ist es relativ einfach (das ist das Label das man immer anzeigen muss und auch im stationären Handel aushängt). Für das Garantielabel (das ist auch technisch was ganz anderes als das Gewährleistungslabe), ist es schon deutlich aufwändiger es gut im Shop umzusetzen. >> Wir dürfen die Anforderungen und Technik dahinter keinesfalls vermischen 😝 - das passiert aber leider sehr häufig wenn man online unterwegs ist. (ist dir das soeben auch passiert? )

Ich denke, dass so ein großer Aufwand für das Gewährleistungslabel gar nicht nötig ist. Aus den offiziellen Richtlinien kann man interpretieren, dass eine einfache CMS Seite ausreicht. Ich persönlich benutze das "Block CMS" modul und verweise darüber auf die entsprechende CMS Seite. Anscheinend muss man das Label aber auch zur Bestätigungsmail hinzufügen. Meine implementierung ist in beiden Fällen (CMS, Email) wie folgt. Deutsch: <a href="https://europa.eu/youreurope/garantien"> <img src="https://domain.tld/img/cms/Legal-guarantee-harmonised-notice_de.jpg" alt="Gewährleistungslabel" title="Gewährleistungslabel mit den wichtigsten Infos zum gesetzlichen Gewährleistungsrecht" width="880" height="1199" style="border: 1px solid #515560;"> </a> Englisch: <a href="https://europa.eu/youreurope/guarantees"> <img src="https://domain.tld/img/cms/Legal-guarantee-harmonised-notice_en.jpg" alt="Harmonised notice" width="884" height="1200" title="Harmonised notice highlighting the main elements of the legal guarantee of conformity" style="border: 1px solid #515560;"> </a>

I second this suggestion. Here are my entries, vibecoded mostly with gemini and lumo. The attached module "tbswipershim" converts the outdated bxSlider elements to Swiper.js elements instead. Now the slides work with touch input, yay! My other module, which is a fork of the NoCaptchaReCaptcha module, replaces the google captcha with an Altcha proof of work captcha, but although it works, it still needs a lot of work: tbswipershim.zip

Hi, in administration go to: Preferences -> Images. Then regenerate images.

Hi, I’m new here and came across your post while troubleshooting a similar image-upload issue. Thanks for posting the fix! Just to clarify, did running the Core Updater from the settings resolve both the missing thumbnails in the back office and the images not appearing on the storefront? Did you need to do anything else afterward, such as clear the cache or regenerate thumbnails?

3.5.2 - 10/07/2026 Critical fix: the database structure check emptied the whole stock movement history on shops without advanced stock management (at least since version 3.1.8). This check has been removed. Movements already deleted cannot be recovered.

3.5.2 - 07/10/2026 Correctif critique : la vérification de la structure de la base vidait tout l'historique des mouvements de stock sur les boutiques sans gestion avancée des stocks (au moins depuis la version 3.1.8). Ce contrôle est supprimé. Les mouvements déjà effacés ne peuvent pas être récupérés.

3.5.1 - 09/25/2026 Critical fix: opening the detailed list of orphan addresses deleted them instead of only displaying them, so they disappeared before you could review them (versions 3.4.1 to 3.5.0) Orphan address analysis and cleanup are now dozens of times faster on large shops: the queries now use the database indexes (about 19 seconds down to 0.3 second on a shop with 185,000 addresses) The orphan address counter now applies exactly the same rules as the deletion, so the announced number always matches what is removed Fixed an HTTP 500 error on PrestaShop 1.6 when enabling a module from the list: the module called a core method that only exists from PrestaShop 1.7 onwards Fixed disabling a module on PrestaShop 1.6 being reported as a failure although it had succeeded; the enabled state is now read back from the shop association after the action Fixed module names and descriptions containing HTML entities being escaped twice in the module list, showing the raw entity instead of the accented character Fixed an error when changing the database table prefix, caused by a call to a method that had been renamed Fixed a fatal error when upgrading the module from a version older than 2.3.0 Added the missing index.php protection files in the mail template directories

3.5.1 - 25/09/2026 Correctif critique : ouvrir la liste détaillée des adresses orphelines les supprimait au lieu de simplement les afficher, elles disparaissaient donc avant que vous puissiez les examiner (versions 3.4.1 à 3.5.0) L'analyse et le nettoyage des adresses orphelines sont désormais des dizaines de fois plus rapides sur les grosses boutiques : les requêtes utilisent maintenant les index de la base (environ 19 secondes ramenées à 0,3 seconde sur une boutique de 185 000 adresses) Le compteur d'adresses orphelines applique désormais exactement les mêmes règles que la suppression : le nombre annoncé correspond toujours à ce qui est supprimé Correction d'une erreur HTTP 500 sur PrestaShop 1.6 lors de l'activation d'un module depuis la liste : le module appelait une méthode du cœur qui n'existe qu'à partir de PrestaShop 1.7 Correction de la désactivation d'un module sur PrestaShop 1.6 rapportée comme un échec alors qu'elle avait réussi ; l'état activé est désormais relu depuis l'association à la boutique après l'action Correction des noms et descriptions de modules contenant des entités HTML échappés deux fois dans la liste des modules, affichant l'entité brute au lieu du caractère accentué Correction d'une erreur lors du changement de préfixe des tables de la base de données, causée par l'appel à une méthode qui avait été renommée Correction d'une erreur fatale lors de la mise à jour du module depuis une version antérieure à 2.3.0 Ajout des fichiers de protection index.php manquants dans les répertoires de gabarits d'e-mail

Hello, this is already possible (always tax-included), you have to configure all the countries in the same way including tax.

I think the distinction between invoice and delivery address is important when configuring taxes in a multistore setup. I’d also want a clear way to make one store consistently display tax-inclusive prices regardless of whether the customer is logged in or where they are browsing from.

Also for the warranty workflow to work we have to implement warranty as a concept in the system. Currently, we have no records anywhere (global, per category, manufacturer, product, etc) that indicates this for the system/modules to reuse later. We have to track statutory_conformity_period and commercial_warranty_period as both are not the same under EU law. We might accept a conformity claim which falls in the mandatory 24 months period but we should not accept a commercial claim if the commercial warranty is only 12 months and they file a claim at month 15th.

Will businesses with 1M turnover pay X amount if they are not forced to do so? 🙂 So thirty bees has to hire some compliance and fraud specialists too, except coders. 🙂

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.

maybe you should implement something that says, if you have more than 1M turnover, you have to pay ammount x. If you are below, it is for free or just like now with the subscription

I use it in the standard format. Allowing customers to submit for a return, generally because they ordered the wrong thing. I serves it's purpose to help us understand why packages are showing up at our door. It functions good enough for that, but could definitely be improved. I don't do defective/warranty returns via RMA. I also do not do direct exchanges due to the fluid nature of our inventory and the varying prices between combinations. Generally I handle those via manual email. I have the RMA emails automatically sending on status change and that works well. A couple things on this though: - I work with very large companies on a regular basis, and most struggle with their RMA process and have very manual workstreams. - It seems that larger storefronts like Shopify are embracing that most robust RMA workflows move to 3rd party modules (Like Shipstation) so that customer submission via portal page and return label generation is automated and data integrates into the main shipping platform. - It would be great if there was a capability to let the customer choose another combination of the product to exchange with and eliminate our human interaction requirement, but that would even be challenging since our combinations are offered at different prices.

4.0.0 - 09/16/2026 New feature: Google promotions feed: publish your discount vouchers so Google displays a "special offer" link below your Shopping ads 9 new target countries aligned with the official Google Merchant Center list: Ethiopia, Ghana, Kenya, Mauritius, Nigeria, Tanzania, Uganda, Zambia and Zimbabwe, for a total of 71 countries Fixed the missing United Kingdom flag on shops where the country ISO code is uk instead of gb Module archive reduced by more than half: the flags of countries Google does not support were never displayed and weighed 2.8 MB New "Promotions" tab: every cart rule is audited, the ones Google cannot announce safely are blocked with an explicit reason Cart rules reserved for one customer, expired, limited to some products or without an expressible discount are never published Supported offer types: percentage off, amount off, free shipping and free gift, with minimum purchase amount and validity dates Editable public title per promotion, because the internal name of a cart rule is rarely suitable for shoppers The promotions feed is regenerated together with its product feed and inherits the same protection: secret fingerprint, atomic write and gzip A promotions feed with nothing to announce is now published as a valid empty document instead of being deleted: a deleted file turned a URL declared for scheduled fetch into a 404, which Merchant Center reports as a data source error Saving the Promotions tab no longer regenerates the feeds: each one now has its own Generate button, and the feed table says how many promotions are ready for that country New feature: New option "Protect the feed URL": a secret fingerprint is added to the feed file name so nobody can download your catalog, prices and stocks from a guessable address New "Renew the security key" action: deletes every generated feed and invalidates leaked feed and CRON URLs The export directory is now protected by an .htaccess file (no directory listing, no access to feeds being written) Feeds are now written to a temporary file and swapped in atomically: Google can no longer fetch a truncated feed during generation New option "Compress the feed (gzip)": generates a .xml.gz feed, natively supported by Google Merchant Center New feature: New "Diagnostic" tab gathering the product image audit, the feed quality report and the database index check Product image audit: detects images below 500x500 pixels before the Google deadline of January 31, 2027, measured on the original file and not on theme thumbnails Feed quality report: products kept out of the feed are counted by cause (empty description, no image, empty title, shop root category) with up to 50 examples each Products exported without a brand are now reported as at risk of Google disapproval Feed download is now authenticated with a constant-time key comparison FAQ tab rewritten: 40 questions grouped into 9 themes, all answers visible at once with no accordion to unfold Module interface available in 18 languages: every screen, help text, FAQ and changelog entry, not just the configuration labels The Feed tab is now named and translated in every language: its label was the French word "Flux", left untranslated in most back offices Contact support from a form modal: the message and the installation details are mailed by the shop itself, so a back office with no mail client configured can still reach support The DataTables library is no longer loaded from an external CDN: the category table now uses the in-house medTable library shipped with the module, so the back office works without Internet access and nothing is requested from a third party The country selector of the Categories tab is now hidden when the Google product category option is off: it only switches the column that option displays, so it had nothing to drive

4.0.0 - 16/09/2026 Nouvelle fonctionnalité : Flux de promotions Google : publiez vos bons de réduction pour que Google affiche un lien « offre spéciale » sous vos annonces Shopping 9 nouveaux pays cibles alignés sur la liste officielle Google Merchant Center : Éthiopie, Ghana, Kenya, Maurice, Nigeria, Tanzanie, Ouganda, Zambie et Zimbabwe, soit 71 pays au total Correction du drapeau du Royaume-Uni manquant sur les boutiques où le code ISO du pays est uk au lieu de gb Archive du module réduite de plus de moitié : les drapeaux des pays non supportés par Google n'étaient jamais affichés et pesaient 2,8 Mo Nouvel onglet « Promotions » : chaque règle panier est auditée, celles que Google ne peut pas annoncer sans risque sont bloquées avec une raison explicite Les règles panier réservées à un client, expirées, limitées à certains produits ou sans remise exprimable ne sont jamais publiées Types d'offres pris en charge : remise en pourcentage, remise en montant, livraison offerte et cadeau offert, avec achat minimum et dates de validité Titre public modifiable pour chaque promotion, car le nom interne d'une règle panier est rarement présentable aux clients Le flux de promotions est régénéré avec son flux produits et hérite des mêmes protections : empreinte secrète, écriture atomique et gzip Un flux promotions sans rien à annoncer est désormais publié comme un document vide valide au lieu d'être supprimé : un fichier supprimé transformait une URL déclarée en récupération planifiée en 404, ce que Merchant Center signale comme une erreur de source de données L'enregistrement de l'onglet Promotions ne régénère plus les flux : chacun dispose désormais de son propre bouton Générer, et le tableau des flux indique combien de promotions sont prêtes pour ce pays Nouvelle fonctionnalité : Nouvelle option « Protéger l'URL du flux » : une empreinte secrète est ajoutée au nom du fichier de flux afin que personne ne puisse télécharger votre catalogue, vos prix et vos stocks depuis une adresse devinable Nouvelle action « Renouveler la clé de sécurité » : supprime tous les flux générés et invalide les URL de flux et de CRON ayant fuité Le dossier d'export est désormais protégé par un fichier .htaccess (pas de listing du répertoire, pas d'accès aux flux en cours d'écriture) Les flux sont désormais écrits dans un fichier temporaire puis basculés de façon atomique : Google ne peut plus récupérer un flux tronqué pendant la génération Nouvelle option « Compresser le flux (gzip) » : génère un flux .xml.gz, nativement accepté par Google Merchant Center Nouvelle fonctionnalité : Nouvel onglet « Diagnostic » regroupant l'audit des images produit, le rapport de qualité des flux et la vérification des index de base de données Audit des images produit : détecte les images sous 500x500 pixels avant l'échéance Google du 31 janvier 2027, mesurées sur le fichier d'origine et non sur les vignettes du thème Rapport de qualité des flux : les produits écartés sont comptés par cause (description vide, aucune image, titre vide, catégorie racine de la boutique) avec jusqu'à 50 exemples pour chacune Les produits exportés sans marque sont désormais signalés comme risquant un refus de Google Le téléchargement du flux est désormais authentifié avec une comparaison de clé en temps constant Onglet FAQ réécrit : 40 questions regroupées en 9 thèmes, toutes les réponses visibles d'un coup, sans accordéon à déplier Module entièrement traduit en 18 langues : tous les écrans, textes d'aide, entrées de FAQ et de changelog, et non plus seulement les libellés de configuration L'onglet Flux porte enfin un nom traduit dans toutes les langues : son libellé était le mot français « Flux », qui restait tel quel dans la plupart des back-offices Contact du support depuis une fenêtre modale : le message et les informations d'installation sont envoyés par la boutique elle-même, ce qui permet de joindre le support depuis un back-office sans client de messagerie configuré La bibliothèque DataTables n'est plus chargée depuis un CDN externe : le tableau des catégories utilise désormais la bibliothèque maison medTable livrée avec le module, ce qui permet au back-office de fonctionner sans accès Internet et n'adresse plus aucune requête à un tiers Le sélecteur de pays de l'onglet Catégories est désormais masqué lorsque l'option Catégorie de produit Google est désactivée : il ne fait que basculer la colonne affichée par cette option, il n'avait donc rien à piloter