Norwegian_Rat

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,

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

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

Hi We have encountered an unusual issue we just cant seem to get our head around. Following our update to the latest bleeding-edge version, all functionalities within the back office appeared to operate smoothly. However, we have noticed that the emails being sent out are not rendering correctly. This problem did not exist prior to the upgrade; now, emails sent from both /mails and /modules/mailalerts are displaying styling code, with addresses replaced by random characters, and the emails are not presenting well in mail clients on either mobile devices or desktop browsers. Additionally, the logo image appears blurry and has a significantly degraded resolution. I have attempted to replace the folders with the original ones from the download file and have also tried using older versions, but these efforts have not resolved the issue. We also tried a new upload of the mail logo, but to no avail. We are currently operating on version 1.7.0 with PHP 8.3. Has anyone else experienced this problem? If so, does anyone have any suggestions for a solution?

Hi, Does anyone else get an error when selecting paypal in checkout after doing a force compile /clear cache action? It seems like everytime we do this, PP throws a "Authentication failed due to invalid authentication credentials or a missing Authorization header" When we then go into the PP-module and do a resave it's working again. Sometimes it wont let you and throws an error in the pp-settings as well, but suddenly it will and everything is fine until next force compile. Another thing that happened after installing the latest bleeding edge the thumbnails in the image section of a product isn't showing. Image cant be found. And when you go to "show in store" live mode they dont show as well. They do however show up when your not in the live configuration mode though. Bleeding edge as mentioned, every module is up to date, running php 8.3

We're running bleeding edge, yes. I dont thinl we have any major php issues. Database scheme throws no errors at least. We got a few other hick-ups regarding the "online visitors" link (500 server error. been with us for a while), but besides that I believe everything is as it should. I belibve we were on php8.0 before the update I think we managed to solve it somehow. We experienced another error as well, but the last one occured when tweaking the PP-settings via their page, so this shouldn't be a TB/Module-issue. The "Authentication failed" error came around when we updated the keys for the second time. First It went from working (updated to latest PP-module with new keys) to being on and off without us doing anything, to working again (so far) with new keys. We'll keep an extra eye open and test regurlarly ourselves. Hope it makes sense. Let me know if anyone else should run into the same issues and need more info.

Hi. We've run into a little issue with the PayPal module after we did some updates. We have created new keys and all that, but the error still shows up. Sometimes it works, sometimes it throws an error. Anyone with the same experience? TB 1.6 .0, Php 8.2.17, PayPal 5.6.1

Hi, I was trying out the option to send tracking via the edit option in the shipping section. https://zemez.io/support/prestashop/how-to/prestashop-1-6-x-add-courier-tracking-number-customers-order/ E-mail was sent, but not with the text/code i entered. This field was empty. I then did a search, and found this: https://help.extensiv.com/en_US/1624573-blank-tracking-number-prestashop Is this solution something that will work in ThirtyBees? I found the right sections, but some code was edited (f.ex "shipping_number" is now "shippingNumber" A bit reluctant to alter code if it's not exactly the same. Hope someone can push me in the right direction regarding this. All the best,

Hi. I've run into a little issue when I was about to upgrade a store from 1.3 to stable/bleeding edge. When I hit Modules page I get the 500 error page. When decrypting the error it gives me this: Decoded exception method_exists(): Argument #1 ($object_or_class) must be of type object|string, bool given in file classes/controller/AdminController.php at line 3460 line 3460:3460: if (method_exists(Module::getInstanceByName($module->name), 'reset')) { We're on PHP 8.0 atm. Is there an easy fix for this, or did we screw up by not upgrading when we was on php 7 ? Regards

We're on bleeding edge, using No Captcha reCAPTCHA Module v.1.1.3. There's not many coming through, but there's one or two almost dayly from this Eric Jones. It's just very, very annoying, even though it's manageable

Hi, I was just wondering if someone out there knows how to get rid of the spam mails (that makes it through the captcha obstacle?). Mr. Eric Jones in particular 😃

Thanx a lot for your answer, @datakick! We'll go and purchase this module then. Keep up the good work! All the best, Norwegian Rat

Hi @datakick, First of all; Great work with TB 1.4! We've been through a ton of upgrades from 1.4, but it's never been as easy and smooth sailing as it's been the last years. Not even easy cosmetic issues. Well done! Got one question though. What is the status regarding your Chex / OPC module. Compatible with 1.4 (BE 1.5) php 8.1 and all that jazz? Regards, Norwegian Rat

Hi @datakick, Giving this module a test, but it throws an error during install: [PrestaShop] Fatal error in module file :"address"/Tar.php: Cannot use result of built-in function in write context. Do you know what's causing this by any chance? I'm running TB 1.0.7, PHP 7.2, default PS 1.6 theme Edit: Might be something with our store. Hang on 😃 All the best

It's not really complicated upgrading TB. You just go to "Core Updater" in the BO, chose whatever version you want to upgrade/downgrade to and hit the action button. Its pretty solid made! We switched from PS to TB, and it's running flawless. The people behind TB are extremely competent and skilled. Everything always work and regarding documentation and issue management, you can always use prestashop forums as well.

Upgraded all modules and store from a 1.0.4 installation to a 1.0.8, and it all went seamless! Thank you for all the great work you guys do! Finally it seems like we don't have to prepare for the worst when upgrading! Switching to thirty bees has been nothing but a joyride for us. Thanx a lot!

@Traumflug: I did not play around with it for too long, as I aborted the testing when (luckily) a new customer contacted us through FB telling us he could not create an account / log into our main store. I can provide you with the info I got though, if you can make something out of it. We installed a new shop in a subfolder a while back with a new database for this store, as we're able to have several databases on our hosting plan. Seemed to work fine, until we were settting up payment solutions (paypal and stripe). To give these a test, we tried making an account, but nothing happened on the login pages. No Error, no nothing. Just didn't take you to the "your page"-site. This happened on Chrome and Firefox. (If I'm not mistaken I believe my partner managed to log in using Vivaldi and Edge....) Thinking it might be a SSL-issue with security within the browsers, I thought I could try turning on SSL in BO, which seemed to be a solution, as we both now managed to log in using Chrome and FF. Believing this issue now was solved we called it a day. Early next moring this customer had messaged us through our FB- page telling us he could not create/log in in our main store. Knowing that this most likely was related to the subdomain store, I logegd in and turned off the SSL in the subdomain store, and told him to try again, and now it worked, thirty bees version: 1.0.7 (Upgraded from PS 1.4 through PS 1.6 to tb 1.0.3) PHP version 7.1.26 MySQL version 10.1.30-MariaDB-1~xenial MySQL engine InnoDB MySQL driver DbPDO

Yea that is of course a solution. I was just curious if anyone else had experience with this issue and uf there was a solution to it

This was the plan, yes. F.ex domain.com/band

Basically we're going into a larger collaboration with a band, and to make it tidy we want to use a standalone shop for this part.

Played around with a second store in a subfolder on our domain, and when we enabled SSL in the subfolder store, customers had trouble making an account/logging in on the default root store. At least everything worked when I turned off the SSL in the subfolder store. Anyone else noticed this behaviour?

If the solution @lesley provided don't work, you can give the free PayPal module from PrestaShop a go. We had the same issues as you, but it did not happen with the PS version.

How much, @pedalman? Concidering a OPC myself you see ?

What payment gateway are you using @DavidP ? Ok for others to know if they're concidering buying an OPC-module :)

Mkai...so it looks like it was a php 7.2 issue. Downgraded and now everything seems to be working. (I know tb is not quite ready for 7.2 yet, but I'm pretty certain we ran under 7.2 during the 0.3 era though...) But to the others facing strange issues: CHECK YOUR PHP VERSION BEFORE GOING HAYWIRE ON YOUR SHOP =)