All Activity

2.1.0 - 10/11/2026 Mise à jour depuis les versions précédentes corrigée : elle pouvait s'arrêter sur une erreur Saisie de la clé de licence corrigée : une clé valide est de nouveau acceptée, même tapée en minuscules ou collée depuis un e-mail Après toute action dans l'onglet Licence, la page se rouvre sur cet onglet et affiche le résultat Dates de licence affichées au format de la langue de votre back-office L'aperçu de l'URL du script et le test de configuration tiennent compte de l'option Serveurs européens Achats directs : le bouton Contact ouvre un formulaire de support envoyé par votre boutique, sans logiciel de messagerie FAQ réorganisée par thème

It didn't take AI long to fix it. But I completely eliminated the time zone table with a new class that handles the calls to the old time zone in the table. Their maybe an issue if someone uses a direct sql call of the time zone table. pointer for backwards compatibility. It needs more testing but installed just fine with America\New York time zone.

Just testing out the new paypal module on the PayPal sandbox. Every transaction I try produces an error message: ThirtyBeesException: Property Thirtybees\Module\TbPayPal\Model\PayPalOrder->amount has invalid value [91.060000000000002] The price should be 91.06 Where do all these extra decimal points come from? PayPal Checkout Pro v0.0.1 - by thirty bees TB 1.70

Is there a command to run to identify this issue or do I need to go with a debugger? Like I said I'm a dotnet guy but claude might be able to figure this out. I'm going to try to figure this out but you guys are a whole heck of a lot more advanced than i especially being a php nubbie.

security was the first objective of the project. security patches all already implemented. Thanks anyway for your concern and the advice.

Locking down the schema question seems like the practical first step before anyone touches the credit module, and a short list of what maintainers already have planned would settle whether to wait or start. I'm curious whether the 1.6 to 1.7 path mentioned here needed any database adjustments, or if it was mostly file replacement. That detail would help those of us weighing when to move. On payments, Wero is outside my own setup, but if a large share of stores depend on it, asking early whether it's in scope alongside 1.7 seems fair rather than pushy.

The stability and performance points are what matter most to me. A store that loads quickly and doesn't fall over on busy days is worth more than a long feature list. The migration detail is interesting too, since losing customizations is usually the main worry. One thing I'd want to know: how much ongoing maintenance does a fork like this require, especially around PHP updates, compared with the upstream project? Open-source help in the forum sounds reassuring, but it depends on how active that community stays over time.

Getting a 1.4.0 install clean on PHP 8.4 with no notices in the logs is a real accomplishment, so credit to the patch authors. The point about updating anyway is the one I'd underline: backporting compatibility fixes keeps an old codebase running but doesn't carry the security patches that shipped since. For anyone maintaining a legacy storefront, the practical path is usually to keep the patched install as a stopgap while planning the full upgrade, rather than treating it as the destination.

Nevertheless, it is VITAL to update to the latest version - it has MANY security patches that are not included in your store.

Our good old TB 1.4.0 is now running on PHP 8.4, thanks to the patches from PS The Web Solution! It runs like a rocket, and after all our testing, there are no errors, warnings, or deprecation notices in the logs! Thanks guys, outstanding work!

The point about the core schema being settled before anyone contributes to the credit module makes sense to me — building gift cards and store credit on tables that might still shift seems like avoidable rework. A clear statement of what's already planned would help people decide whether to wait or start. I don't have a Mollie setup myself, but the Wero question sounds like it matters to a fair number of stores, so it's reasonable to ask whether it's on the roadmap alongside the 1.7 release.

The point about separating installer-side validation from a PHP version mismatch is worth pursuing. Before running a CLI install with a US identifier, I'd check the array or validation rule the installer uses to build its timezone list and see whether a zone like America/New_York is present in it. If it is, the failure is likely a matching issue; if not, it's a list problem. Also confirm the PHP build's supported identifiers, since those changed across versions. That distinction should tell you whether tax settings tied to the current value are even at risk.

The Europe/France workaround pointing to installer-side validation rather than a database issue makes sense. Since internal PHP timezones have shifted across versions, I'd want to confirm whether the installer is rejecting the identifier itself or failing to match it against its own list before the DB step. That would separate a mapping bug from a PHP version mismatch. If it's the former, a US identifier might be fixable without touching anything tied to tax settings, which would matter for US shops.

Bonjour, Merci pour votre retour détaillé. Concernant votre interrogation sur les performances, soyez rassuré : avec le protocole HTTP/2, l’impact est négligeable. J’accorde depuis toujours une attention particulière aux performances et à l’optimisation de mes modules. Je suis un peu un dinosaure du développement web, issu d’une époque où l’optimisation n’était pas une option, mais une nécessité. J’ai conservé cette culture au fil des années, et elle reste aujourd’hui au cœur de ma manière de développer.

Good to hear the 1.6 to 1.7 upgrade went smoothly — that's reassuring for those of us still planning the move. On the credit module offer, the key question is really whether the core schema is settled; if gift cards and store credit end up sharing tables, contributing before that's locked in could save duplicated work. Worth waiting for a clear answer on what's already planned before anyone starts building alongside it. Mollie and Wero is a separate concern, but it seems like the kind of payment update that affects a lot of stores, so hopefully it's on the radar too.

The Europe/France workaround suggests the installer's timezone list is rejecting US identifiers before the database step ever runs. If the CLI install uses the same validation, a US zone likely fails there too, so testing it wouldn't tell you much. A safer approach might be to check which timezone value the installer actually writes and whether the server's PHP build recognizes that identifier, since internal PHP timezones changed across versions. Worth confirming that before assuming a back-office change would break tax rules tied to the original setting.

It detects every email we send out and list them in a list so the merchant can turn this feature on for said period, generate templates they use in other modules and then turn this detection off when they are confident all emails have an override.

The variable mismatch between order_conf and {items}/{products} explains a lot — that's probably why my attempts at keeping two templates in sync always drifted. The MJML-based approach sounds much cleaner than hand-editing both, especially the automatic PDF versioning per shop so terms are never stale. One question: does the override detection handle third-party module emails gracefully, or does it sometimes generate templates for transactional mails where a custom design isn't really appropriate? Curious how you keep that from creating clutter.

The security work in 2.0.0 stands out to me—signing each script and limiting changes to SuperAdmin with logging is a solid defense against tampering. I'm curious how the signature check handles legitimate edits when someone restores a store from a backup. Also, storing every snippet in its own file is a smart move since one broken script won't take down the rest, but does it add noticeable overhead on pages that load many scripts at once? The independent per-shop handling for multiboutique is a welcome fix too.

Ok the Europe / France works with no issue. Now this problem has been going on for a long time. And it's not a simple change in the back office because taxes etc are tied to it. Has anyone found a timezone that work in the US? Now my php isn't my cup of tea but I like ThirtyBees over prestashop because of the advanced stock management. Now with AI this fix should be fail simple. Also, as someone else said the are internal timesones in php now to a simple class to replace to tables should work. But for ThirtyBees to get a better foot in the market in the US this is a neceassity. Has anyone done the commandline install for a US timezone? Did it work? My guess is it didn't.

2.0.0 - 05/11/2026 Corrigé : Le code JavaScript contenant des barres obliques inverses ou des signes de comparaison n'est plus altéré à l'enregistrement Corrigé : Le code JavaScript du pied de page est de nouveau chargé sur PrestaShop 1.7 et suivants Corrigé : En multiboutique, chaque boutique a ses propres scripts Sécurité : La suppression d'un script ou le changement de son statut ne peut plus être déclenché par un lien piégé Sécurité : Les valeurs affichées dans la page de configuration sont échappées Sécurité : Chaque script est signé : un script modifié en dehors du back-office n'est pas chargé et il est signalé Sécurité : Seul le profil SuperAdmin peut ajouter, modifier ou activer un script, et chaque modification est enregistrée dans les logs Chaque code JavaScript a son propre fichier : une erreur dans un script n'arrête plus les autres Avertissement quand le code ne correspond pas au type choisi Activation ou désactivation d'un script en un clic depuis la liste, sans recharger la page Nouvel onglet FAQ Fenêtre de dons, affichée de temps en temps une fois le module utilisé : Ko-fi n'est chargé que si vous choisissez de faire un don Enregistrement gratuit du module, notifications de mise à jour et formulaire de support Plus de publicité ni de service externe chargé dans le back-office

3.5.4 - 11/02/2026 Fixed an error 503 when cleaning a visitor table holding several million rows. Much faster counting of the visitors to clean, even on very busy shops. Large tables are cleaned in fewer steps. New: you can now clean the list of pages not found (404 errors) recorded by your shop. New: the database tools tab spots the tables keeping space freed by cleanings and gives it back to the disk in one click. New: a FAQ tab answers the most common questions about cleaning results, backups and the cron.

3.5.4 - 02/11/2026 Correction d'une erreur 503 lors du nettoyage d'une table de visiteurs de plusieurs millions de lignes. Comptage des visiteurs à nettoyer bien plus rapide, même sur les boutiques à très fort trafic. Les grandes tables se nettoient en moins d'étapes. Nouveau : vous pouvez désormais nettoyer la liste des pages introuvables (erreurs 404) enregistrées par votre boutique. Nouveau : l'onglet Outils de base de données repère les tables qui gardent l'espace libéré par les nettoyages et le rend au disque en un clic. Nouveau : un onglet FAQ répond aux questions les plus fréquentes sur les résultats des nettoyages, les sauvegardes et le cron.

4.1.0 - 10/30/2026 New feature: Import / Export tab: save your banned domains and emails as a CSV file, and load a list from a file or a copy and paste New feature: Block a domain or an email address in one click from the attack dashboard Fixed: The attack dashboard no longer lists values that are not email addresses, and the attacking domains panel is filled again Fixed: Installation no longer fails on shared hosting while loading the 22,000 bundled domains Fixed: The module can be installed next to PrestaMailchimp and the other modules that customize the newsletter block: its protection no longer relies on an override The back office no longer loads anything from an external CDN and works without Internet access Contact support from a form: the message is sent by the shop itself, even without a mail client FAQ extended: import and export, uninstallation, multistore and the sentence before the calculation A warning shows when the Newsletter subscription module is too old for its block to be protected (version 2.6.0 or later required) Compatibility: PrestaShop 1.6.1.12 minimum

Here is how order_conf looks with my module. Colors, banner image, links, and much more is configurable. The module detects outgoing emails that don't have an override template so we can make them. It works with another module I created with Codex that builds a PDF of the CMS pages, and this one attaches the latest version. So if we change the TnC of the site we don't have to worry if we are sending out the latest version - it automatically does so per shop. If there is interest in these modules, I can make them available. There are a few things to optimize still. The designs are build with MJML and they are completely responsive and deliverable in any client (images are exclusions, the have to put the domain in their allow list, but we have no control over that..)