datakick

If it's an intermittent problem, then it's most definitely mysql server connection limit issue, as @lesley said. Basically, your database server rejects another connection. The very first sql statement that is executed on every connection is setting the utf8 mode. When this sql statement is executed on closed connection it results in failure. The real / underlying issue is obscured by the no UTF-8 support error message. This seems like a database misconfiguration. While it's not a bug in tb itself, the misleading error message should be fixed

It does perform backend validation, but it depends on override. Please ensure that the override for ContactController is installed (you can use overridecheck module to do this), and that you do not have override disabled in settings.

@rubben1985 this philosophy is not new, and it's used in every software I know. It's called exception handling, and the gist is simple - if the code discovers an error, and can't safely recover from it, then it should throw the exception and transfer the responsibility to the caller. That's the best way to deal with this problem I know of, and I've been developing software for 20 years now. When we throw an exception in the code, we do it because we really don't know how to solve the situation at hand. Imagine if you received an email order for product you don't sell. Would you just send different product to the customer?... Because this is what you are asking thirtybees to do -- to ignore the problem and carry on like noting happened. But something happened, we know that much.

@Briljander handling invalid inputs is a really hard problem for us developers. What should we know when we know for sure that the input is incorrect? When we know that the caller made a mistake, that there is more definitely a bug? Shall we try to recover somehow, or just give up? From my personal experience, recovering does not usually work very well. That's because we don't know the context, what the caller expects, etc. For example, take a division by zero. I have seen many programs that just bails the caller out ty returning zero in that case. You must agree that's not a good solution, since it will most likely cause other problems later. What if the returned number is used to multiply the cart total? The total result would be zero as well, and merchants could quite easily loose real world money because of such bug. It's very similar in this case. TB core doesn't know what the caller use the result for. But we know that such key can not exists in the db. Can we simply return null? Since we don't know what the result is used for, it would be a real gamble. Again, this might very easily cost you money. I'm a big fan of fail fast philosophy in these cases. I understand that, in this particular case, it would be probably better for @violinparts if thirtybees just returned null. His site would work as before, and he wouldn't have to solve this crisis. But by failing fast we have discovered and fixed another bug in the code, making the whole product more stable for everyone

The problem is not in the tb core, it's in the elasticsearch module, on line 484: $defaultCurrency = Currency::getCurrencyInstance(Configuration::get(' PS_CURRENCY_DEFAULT')); The intent of code above is to return currency object for default currency. But it actually never did, because of the typo in configuration key. The Configuration::get(' PS_CURRENCY_DEFAULT') statement returned null because ' PS_CURRENCY_DEFAULT' does not exists (there exists only key without leading space) That in turn resulted in Currency::getCurrencyInstance(null)call, which returned brand new, unsaved currency. As you can see, everything's wrong. The rest of the code continued to evaluate with wrong currency object. We don't know what went wrong down the stream, but rest assured -- this definitely manifested in some other bugs later on. Thirtybees 1.0.8 introduced new check that actually detects these kind of bugs. I agree that the die was too much, simple warning in log might have been enough. But then again -- nobody really notice these warnings in logs, right? To fix your problem, simply replace the line with $defaultCurrency = Currency::getCurrencyInstance(Configuration::get('PS_CURRENCY_DEFAULT'));

This will be addressed in the next release, one way or another. Hopefully this functionality will be salvaged :)

@hedgehog try to separate the images by ; instead of ,

@hedgehog are you using correct multiple value separator ?

@hedgehog that's definitely enough memory. So the culprit must be somewhere else. Could you please try to modify this line in classes/Tools.php and change it to look like this: 'verify' => _PS_TOOL_DIR_.'cacert.pem',

@gandalf why the no override requirement?

@hedgehog what is your memory limit? When thirtybees copy image, it needs to resize it. It's likely that the source images are huge, so they require large amount of memory to process. TB will not try to resize such images if you run on server with limited memory, as it would lead to server crash.

Don't forget to toggle Display to customer

@andyc if it's showing 1.0.7, then it probably wasn't. Did you encounter any problems during update?

@Fabsca without error message we can't really help you much. Please look into thirtybees error logs inside log directory server's error log -- location can vary depending on server's configuration, but it's usually /var/log/apache2/error.log or something like that. If you have some sort of cpanel, then you should also be able to access your error logs through there. Once we know what the problem is, we can fix it

You need to increase php memory_limit in your php.ini, 128MB is not enough.

Hi @LucaSabatoUK, does this module work on vanilla ps16? If so, what issues did you encounter? Since we are talking about open source module, could you provide link to github repository? I'll have a look at it in my spare time

That's true, the source images must be high quality. Merchant needs to make sure that the white background does not blend into the image. At this point, it's probably easier to just remove the background altogether, and make it transparent png. Then we could simply show this image on top of any background

I think it's indeed some on-the-fly image manipulation. https://static.toom.de/produkte/bilder/1450502/145050202.png https://static.toom.de/produkte/bilder/1450502/145050202.png?grey=1 This effect can be achieved by imagemagick, for example by using floodfill. For this to work, source images must be in good quality, and have pure white background.

Does this module work on ps16?

@Steve, if your php can't send emails directly, you can always use stmp. Simply enter your credentials for your gmail (or any other) account, and thirtybees will send emails through this email address.

highest 1.6 version, in this case 1.6.1

@Fabsca look into log directory inside your thirtybees installation, there should be file with error log. Let us know the error message

sure, it will be part of the upcoming release. Here's all the commits that are scheduled: https://github.com/thirtybees/thirtybees/compare/1.0.7...1.0.x

@danwarrior could you share link to your course?

Try to change this order by