All Activity

3.0.0 - 04/28/2026 New feature: Multi-language support per country (e.g. Belgium: FR + NL + DE, Switzerland: FR + DE + IT) One XML feed generated per country-language pair Dedicated CRON URL for each country-language combination Dynamic language selector with add/remove buttons in country configuration Full backward compatibility with existing single-language configurations Redesigned "About" tab: module info card, features list, and cross-selling section matching Mediacom87 standard Database index diagnostic with one-click creation buttons (AJAX) for optimal export performance Redesigned "Cron" tab: multiple configuration formats (WebCron, curl, wget, PHP CLI, cPanel/Plesk) with copy-to-clipboard Cron syntax reference panel with visual diagram and common scheduling examples New "FAQ" tab: comprehensive help covering module configuration, feed generation, Google Merchant Center and troubleshooting Languages sorted alphabetically in configuration selects Removed "More Modules" tab (merged into About) DataTables library updated to version 2.3.8 Fixed class name collision with other Mediacom87 modules (UpdateModule → GoogleExportUpdateModule) Fixed feed file detection not matching export naming convention for single-language countries Fixed feed file path for non-root export directory configuration

3.0.0 - 28/04/2026 Nouvelle fonctionnalité : Soutien multilingue par pays (par exemple Belgique: FR + NL + DE, Suisse: FR + DE + IT) Un flux XML généré par couple pays-langue URL CRON dédiée pour chaque combinaison pays-langue Sélecteur de langue dynamique avec boutons d'ajout/suppression dans la configuration des pays Compatibilité ascendante complète avec les configurations mono-langue existantes Onglet "À propos" repensé : carte d'information du module, liste des fonctionnalités et section de cross-selling au standard Mediacom87 Diagnostic des index de base de données avec boutons de création en un clic (AJAX) pour des performances d'export optimales Onglet "Cron" repensé : plusieurs formats de configuration (WebCron, curl, wget, PHP CLI, cPanel/Plesk) avec copie dans le presse-papier Panneau de référence de la syntaxe Cron avec diagramme visuel et exemples de planification courants Nouvel onglet "FAQ" : aide complète couvrant la configuration du module, la génération du flux, Google Merchant Center et le dépannage Langues triées par ordre alphabétique dans les sélecteurs de configuration Suppression de l'onglet "Plus de modules" (fusionné avec À propos) Bibliothèque DataTables mise à jour vers la version 2.3.8 Correction d'une collision de nom de classe avec d'autres modules Mediacom87 (UpdateModule → GoogleExportUpdateModule) Correction de la détection des fichiers de flux ne respectant pas la convention de nommage pour les pays mono-langue Correction du chemin du fichier de flux pour une configuration de répertoire d'export hors racine

orangepi5-thirtybees-setup.md orangepi5-thirtybees-setup.md

ab -n 10000 -c 100 -k https/XXXX.XX/index.php 2>&1 | grep "Requests per second\|Time per request\|Failed" Failed requests: 0 Requests per second: 8402.12 [#/sec] (mean) Time per request: 11.902 [ms] (mean) Time per request: 0.119 [ms] (mean, across all concurrent requests) root@orangepi5:/var/www/thirtybees# 8400 requests per second at 100 concurrent users with zero failures! That's an absolutely remarkable result for an ~$80 ARM board. To put it in perspective: 8400 req/s — would handle massive traffic spikes 0.119ms per request across concurrent users Zero failed requests Pure nginx serving from memory cache, no PHP, no database This Orange Pi 5 with NVMe + nginx fastcgi_cache could handle a serious production thirtybees store. Most small/medium e-commerce sites see maybe 10-50 req/s peak traffic. Final stack summary: ✅ Nginx 1.29 with fastcgi_cache ✅ PHP 8.3-FPM (80 workers) ✅ MariaDB with 2GB buffer pool ✅ Valkey (Redis-compatible) for DB query cache ✅ Thirtybees page cache as fallback ✅ OPcache enabled noatime — in fstab with commit=600 (batches writes every 600 seconds) zram swap — running with 3.9GB lzo-rle compressed swap zram /var/log — logs are in RAM (50MB), reducing disk writes cat /etc/os-release uname -a PRETTY_NAME="Armbian 26.2.0-trunk.811 bookworm" NAME="Debian GNU/Linux" VERSION_ID="12" VERSION="12 (bookworm)" VERSION_CODENAME=bookworm ID=debian HOME_URL="https://www.armbian.com/" SUPPORT_URL="https://forum.armbian.com" BUG_REPORT_URL="https://www.armbian.com/bugs" ARMBIAN_PRETTY_NAME="Armbian 26.2.0-trunk.811 bookworm" Linux orangepi5 6.1.115-vendor-rk35xx #1 SMP Sat Apr 25 16:15:42 UTC 2026 aarch64 GNU/Linux root@orangepi5:/var/www/thirtybees#

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

Yes, I understand, thank you for your detailed answer! But not every customer can have their own server; just think of the environmental impact. The biggest problem, in my opinion, is administration. A dedicated physical server is a huge security issue, and very few people can adequately secure and maintain it daily. And very few want to pay professionals... VPS (virtual private servers) would be a better solution; they're also available managed. There are plenty of providers that offer sufficient performance, including hosting services.

This is related to MAX_JOIN_SIZE configuration variable in mysql server. From documentations: If the max_join_size variable (also called sql_max_join_size) is set, then it will limit any SELECT statements that probably need to examine more than MAX_JOIN_SIZE rows. This means that database server (during preparation stage) will estimate how many rows it will need to process (based on table statistics). If the estimate is above threshold, it will refuse to execute the query. This is set on some shared hostings to achieve some kind of fair usage between all users. Sometimes we can indeed optimize the query, or create a new db indexes so the join space is not so huge. But sometimes its just not possible. I still maintain that this is stupid and dangerous practice by hosting providers. This can kill any sql query, and therefore cause a lot of 500 error pages. Ecommerce store should not run on such hosting.

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,

I'd really like to know what database size we're talking about here? Are you planning to import a database, or what exactly are you doing? Generally speaking, this isn't a real problem anymore, even on shared hosting. I know some excellent providers where you don't have these issues and it still only costs a few euros a month.

There is a potential workaround here. You can set SQL_BIG_SELECTS variable for a database session. That should allow you to bypass the error (may or may not work, depending on your hosting configuration) Create a new override override/classes/db/Db.php with this content: <?php class Db extends DbCore { /** * This override allows complex queries to run on shared hosting */ public function connect() { $link = parent::connect(); $link->exec('SET SQL_BIG_SELECTS = 1'); return $link; } } Then clear cache in Advanced Parameters > Performance to reload the overrides

Well sure, you can remove old data, it will reduce the number of rows db have to examine. But still, the root cause of the issue is that your hosting is throttling your database. We send them valid sql request, and they may or may not return results. This is just stupid. Who knows what other sql queries they will kill randomly. This "fair usage mechanism" can cost you sales. But that's sharing hosting. You can always move to a dedicated hosting without such restrictions

Hi @datakick Thank you for your swift reply. Much appreciated. We contacted them, and here's what they said: I appreciate the detailed error message and the domain information you have provided. Your concern is duly noted, especially given its impact on customer management in the back office. Kindly be informed that no new restrictions on SQL queries have been implemented recently on our hosting platform. The issue you are encountering is a recognized MySQL safeguard commonly applied in shared hosting environments. The error signifies that the query generated by your ThirtyBees installation is attempting to process an exceptionally large dataset. MySQL restricts this type of query to prevent excessive server load or potential performance degradation. This measure is not a recent restriction but a protective limit intended to prevent queries that could adversely affect the server. From a support perspective, the issue is more likely related to the application level rather than the hosting level. I suggest the following actions: 1. Verify the presence of all necessary indexes * Pay particular attention to tables associated with carts and customers. 2. Examine the recent behavior of modules * Even if no recent modifications have been made, certain modules may produce inefficient queries under specific data conditions. 3. Activate debug mode in ThirtyBees * This will help identify the precise SQL query responsible for the issue. 4. Perform database optimization * Removing outdated carts and sessions can substantially decrease the size of queries. 5. Request a developer to review the query * The query found in the following files likely requires optimization: * classes/Customer.php * AdminController.php Would the module "Optimizing and cleaning up your Thirtybees store" help us out? Other modules that might help us solve this issue? (We're on the pro plan of the shared hosting provider, if this means anything) All the best

Depends on what you plan, you alternatively (temporary) upgrade your 1.6 a bit. https://github.com/PrestaShop/PrestaShop-1.6 This archive did not release official version, but newest files were patched for PHP 7.2. Not many know what. You can quickly drop changed files and make ps 1.6 PHP 7.2 compatible... but for not official modules it's other story.

This is your hosting restrictions. You are probably on a shared hosting, and they have enabled this restriction to ensure fair usage for all customers. Ask them if they can disable this.

Hi, Suddenly we got a "Invalid list SQL" error when we click on "Active shopping carts" from the Activity overview and the customers tab. Both Error in log says this: Message: ThirtyBeesDatabaseException: The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET MAX_JOIN_SIZE=# if the SELECT is okay Location: classes/Customer.php line 827, classes/controller/AdminController.php line 1184 Can anyone help shed some light on this? Not being able to modify customers could become a serious issue down the road 🙂 we're on latest bleeding edge and php 8.3.30 Thanx in advance

3.9.0 - 04/21/2026 Added an option to enable or disable the mathematical test on the contact form independently from the other protections (honeypot and blacklists stay active) The calculation introduction sentence field is now displayed right below the mathematical test option and is automatically hidden when the contact form or the mathematical test is disabled Add several domains at once to the blacklist by separating them with commas, with individual validation and per-entry error reporting The banned domains, banned emails and logs lists now use DataTables server-side processing: pagination, sorting and search are handled by the database, keeping the administration panel fast even with tens of thousands of entries Added automatic update notification in the configuration panel when a new version of the module is available Redesigned the Informations and support tab with a clearer module summary (logo, version, compatibility, support link, features list) Simplified the More Modules tab and hidden it entirely when no recommendations are available Enriched the FAQ with six new questions covering GDPR compliance, performance impact, newsletter protection, optional math test, multi-domain input and responsible vulnerability disclosure Removed the legacy License tab (the module is distributed under AFL 3.0, information available in the security policy and changelog) DataTables library updated to version 2.3.7

Oh, I didn't even noticed this was ps16. Yeah, Alex, you should thoroughly test your store, because this will not be the only problem. If possible, downgrade your php version. Or even better, migrate to thirtybees.

With an outdated version like PrestaShop 1.6, you shouldn't change the PHP version, as it will cause a whole host of errors. The maximum supported PHP version for PS 1.6 is 7.1

Thanx a lot Datakick - That did the trick. We had updated the PHP version lately, and that must be the reason, but now it works again 😄

Hi Alex, did you install some new module, or changed you PHP version recently? Anyway, this issue is caused by an override. You need to edit file /override/controllers/admin/AdminLoginController.php and replace code public function viewAccess() with public function viewAccess($disable = false) That should do the trick

Hi I have one shop more on a prestashop 1.6, but suddenly I can't login on backoffice anymore. I have recieved an mail about a new payment from the shop and I should see what was ordred, but I can't get in. I get an HTTP 500 error when i try. My errorlog on the server reports: [Fri Apr 17 11:46:32.695892 2026] [fastcgi:error] [pid 57442:tid 57463] [client 127.0.0.1:9196] FastCGI: server "/usr/local/apache/cgi-bin/php7-fcgi116" stderr: PHP message: PHP Deprecated: Function get_magic_quotes_gpc() is deprecated in /home/t/e/ftp_textiltryk-skiltedk/shop/config/defines.inc.php on line 143PHP message: PHP Deprecated: array_key_exists(): Using array_key_exists() on objects is deprecated. Use isset() or property_exists() instead in /home/t/e/ftp_textiltryk-skiltedk/shop/Adapter/Adapter_EntityMapper.php on line 84PHP message: PHP Fatal error: Declaration of AdminLoginControllerCore::viewAccess() must be compatible with AdminControllerCore::viewAccess($disable = false) in /home/t/e/ftp_textiltryk-skiltedk/shop/controllers/admin/AdminLoginController.php on line 153 Anyone who can help me here?

@the.rampage.rado here you can find the guidelines I followed https://psitsolution.com/tools/en/info/eu-directive-eu-20232673-of-2023-mandatory-withdrawal-button-from-june-2026

ok scheint also besser zu werden... schaue unbedingt die Länder durch etc. und "ändere" vielleicht einen vorhandenen Mwst.-Satz, statt neu anzulegen, das musst du einfach mal probieren. Wie gesagt hatte ich da nie Probleme bei tb. Suche dir auch mal "alte" Forumsbeiträge (auch von Prestashop) über das Modul Europäische Rechtssicherheit, das war am Anfang recht kompliziert und fehlerhaft bzw. musste man eine Reihenfolge beachten für die Mwst., sonst hat das nicht funktioniert wie es sein sollte. Das für tb sollte nun aber fehlerfrei sein. Zum Thema Installation: ich hatte testweise ein einziges mal versucht, tb über so einen Softwaredienst aufs Hosting zu installieren (Softaculous) - nie wieder, war total buggy.

Jo der Grund warum ich hier gepostet habe ist ja der das zzgl. MwSt weg zubekommen. Länder und Deutschland ist das einzige Land das gecheckt ist. Woher die US Steuerregel kommt, möglicherweise bei der Installation über eine andere Domain. Deutschland war allerdings von Anfang an eingestellt. Außer den beiden Steuersätzen inkl MwSt ist jetzt nichts mehr dabei. über 80 Steuersätze habe ich löschen müssen. Jupp ist da und installiert jetzt ist immerhin kein zzgl MwSt mehr dabei.

I want to know which proxy tool works best for detecting bots, proxies, VPNs, IP address lookups, and fake traffic.