datakick

as long as the module is for ps16, it should be compatible

Search for 'prestashop checkout extra fields module', you should be able to find few of those (paid).

Could you elaborate?

That seems to be problem related to supercheckout module. I'm afraid nobody can help you without the knowledge of its source code

Also, the same error message is also saved inside your log directory within your thirtybees root. So you can always ftp and look for errors there.

That does not help much. Copy error, then go to Advanced Parameters > Logs, and paste it to Decrypt an exception message. It will show you the error message in readable format.

What does the error log says?

@Chandra please look into tb_configuration table and verify that PS_MAIL_PASSWD is correct. Maybe this problem is related to configuration escaping issue... although not likely

Not necessary, it's simple fix, already submitted

It's probably problem with your infrastructure. I've just tested stmp (mailgun) on 1.0.8, and it works as expected.

This problem originates from referralprogram module. I'm pretty sure this exception will be thrown even on tb1.0.7, if this module is installed and url does not contain &sponsor=xxx parameter. The reason this exception is thrown is because Tools::getValue('sponsor') returns false when 'sponsor' parameter is not part of the request. This invalid value is then passed to cipher tool for decryption. Blowfish would return null for invalid input (boolean type), while PhpEncryption will throws exception. This should be fixed in the core -- the behaviour should be consistent. But the module itself should be fixed as well -- there's no need for decryption call, if we don't have anything to decrypt.

The error message is complaining about missing method Validate::isJSON. That's very strange, because this method is clearly there. There are only two explanations I can think of. you have modified core class classes/Validate.php and removed/renamed this method. That's very unlikely. The other possibility is classname conflict. It's possible that some module have class with name Validate, and this class gets loaded at the very beginning of the request. Thirtybees uses lazy loading autoloader, which means it will load any core class only when needed. In this case the core class would never be loaded, because class with the same name exists. But this third party Validate class does not contain isJSON method. This is another way to override core classes. Unlike normal overrides, which extends core class, this method replace the whole core class. Very dangerous, and officially not supported. But some module developers do this kind of things

@movieseals you can download release 1.0.7 and use Configuration.php file from that version

@wakabayashi unfortunately it's a real problem in tb core with incorrect escaping of configuration value. This module stores serialized json object into configuration table. Due to improper escaping, this json can't be decoded when read back from the configuration. That triggers cascade of errors and problems, one of them manifests as smarty notices. But the module is indeed unusable because of this bug

I've tracked this to another issue in 1.0.8 release. @movieseals if you need immediate fix, you can revert this commit: https://github.com/thirtybees/thirtybees/commit/12d2d6c5f9f8c6d821603fba011e9de03eb1f70d

@elund it seems to me that the captcha is working on your site. I've just performed simulated attack -- tried to submit new message via curl, with invalid captcha validation token. My attack attempt was successfully intercepted by the captcha module, see the screenshot. How many spams are you receiving? PS: from your screenshot it's apparent that you are not using latest version of the module. Maybe that would help

@movieseals sure, send it to me. I'm curious.

hard to tell without the module source code

I've just went over the code and found one bug. If the Login attempts is set to non-zero number, the validation for Contact controller is always skipped. So make sure it's zero until this bug is fixed.

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 :)