All Activity

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

The 404 usually happens because the router can't handle the optional hyphen if the attribute is missing. Try p/{id}-{id_product_attribute}/{rewrite}.html but only for items that actually have variants.

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.

Lokalisierung > Steuersätze und Steuerregeln einstellen, alles nicht benötigte rausschmeissen bzw. einfach abändern zu 7 und 19% oder was bei dir eben zutrifft. Wenn du an Endkunden im Shop verkaufst, darf da nicht "zzgl. MwSt." stehen, die Preise müssen INKL. MwSt. angegeben werden, das ist dir sicher bekannt. Es scheint auch das Modul Europäische Rechtssicherheit nicht aktiv zu sein. Das brauchst du, teilweise wegen der MwSt.-Einstellung und auch daß der Hinweis "zzgl. Versandkosten" (oder eben was anderes) angezeigt wird, was auch vorgeschrieben ist. Handelst du hauptsächlich in Deutschland? !! vorher aber ggf. die Länder richtig erstellen wohin du liefern magst bzw. Gebiete daraus erstellen (EU, Schweiz, USA bspw., das wird dann jeweils anders behandelt und du kannst auch einstellen ob du bspw. für USA die deutsche USt. erheben willst auch wenn netto geliefert werden würde, denn da gilt kein USt-OSS). Die USA sieht also dann die Preise brutto wie in DE. Die richtigen Ländereinstellungen sind extrem wichtig.

Sure can do. Danke nochmals. Die US-AL Rate kann ich nicht über das BE ein bzw ausstellen. Ich nehme an daran liegt es Und im FE sieht es so aus:

hast du mal einen Screenshot o.ä.? ich verstehe das nicht ganz und konnte auch keinen derartigen Fehler feststellen, auch in anderen Versionen nicht. Hast du das EU-Modul aktiv?

@vir - Because I have some ideas, can you help me with your workflow? How do you plan to proceed with those requests? What you envision is your optimal workflow in BO? Where are you located and what are your local requirements for delivery refunds in such cases?

@DRMasterChief It's a pleasure to contribute to the discussion. Unfortunately, however, I must once again contradict you, since, contrary to what you claim, I have never found any evidence to suggest that the withdrawal function should be accessible even without logging in. Furthermore, the same underlying logic supports my thesis: requesting a withdrawal without logging in (and therefore manually entering order details) is certainly more complex than logging in and pressing a button (without having to manually retrieve any data), and the law, as you yourself pointed out, establishes that "the procedure for requesting withdrawal must not be more complex than the procedure for concluding the purchase contract" (which necessarily requires a login or, in any case, the entry of at least one email address and the generation of a password, to ensure security and privacy during the purchase/payment process).

Danke, nun Anzeigen auf nein, cache löschen und trotz allem ist die MwSt. noch drin. TB 1.6 hat eindeutig mehr Macken als die 1.3. So ist eine Kategorie gegraut. Im Frontend wird sie aber gezeigt. Ich schreibe den inkl. MwSt. in die Beschreibung nur die zzgl MwSt. sticht halt ins Auge.

Thanks for your contribution. I don't want to discuss here whether a particular approach is the right one. Only time will tell, and then the next few weeks when the law is in effect. However, all the statements I've found so far point in this direction: The cancellation function must be accessible even without logging in. We must also not forget that we are viewing this strongly from the perspective of a shop owner... So it wouldn't be as most people here seem to think. It remains a nonsensical approach, and of course, it annoys the shop owner to varying degrees 🙂

@DRMasterChief Hi. I think that the crux of the matter here is "Die Ausübung des Widerrufsrechts soll nicht aufwendiger sein als das Verfahren für den Vertragsabschluss" ("Exercising the right of withdrawal must not be more complicated than the contract conclusion procedure.")...so there is no doubt about the legitimacy of the login, since any buyer, whether a customer or a guest, on any e-commerce platform (thirtybees, woocommerce or other) must register with at least an email address and password (chosen by the buyer or provided by the system) and then log in to the system to conclude the purchase contract (and therefore, since it is no more complicated than the purchase procedure, log in to withdraw from the contract). Therefore, the procedure provided by the module PS I am using is correct and unobjectionable by any lawyer/authority.