TECHNICAL ERROR: unable to save account Details: Error thrown: [object Object] Text status: error - FILLING CLIENT´S FORM

[farmadia]

Im building a online shop with thirty bees and its going ok. But then it appeared a major problem to me: i cant finish any client´s form because of this error TECHNICAL ERROR: unable to save account Details: Error thrown: [object Object] Text status: error How can i fix it? Someone can help me?

[basix101]

Solved it by:

Turning off Debugger Advanced Parameters/Performance/Debug Mode

Turning on SSL in Preferences/General/Enable SSL

Also turned off and on Preferences/SEO's Friendly URL

[Traumflug]

Do you have non-standard modules installed? Causes for trouble are pretty often found there. But this also gives the opportunity to narrow down that trouble by disabling all the non-thirty-bees modules, then to turn them back on one by one, while exercising what went wrong before.

[farmadia]

I only used the modules from https://store.thirtybees.com/shop-modules. I supposed they were all standard thirty bees modules...... or at least validated by thirty bees.... but i´ll try your suggestion.... hope it works... if doesnt.... im still gonna need help.... :)

[farmadia]

Nope... your suggestion didnt work. I have other site with thirty bess 1.0.3 and this one is working. But the 1.0.4 is not. Could be it?

[lesley]

Is error reporting turned on for the site? If so, turn it off.

[musicmaster]

Same problem for me. The thing works ok on localhost but not online.

This is a very serious problem. 

"Details: Error thrown: [object Object] Text status: error" is just horrible as a bug report. You might just as well say: we had a bug and we won't bother to tell you what it was. Is it really impossible to have something better? 

Edited March 26, 2019 by musicmaster

[datakick]

1 hour ago, musicmaster said:

Same problem for me. The thing works ok on localhost but not online.

This is a very serious problem. 

"Details: Error thrown: [object Object] Text status: error" is just horrible as a bug report. You might just as well say: we had a bug and we won't bother to tell you what it was. Is it really impossible to have something better? 

I agree it's terrible error message, and it should definitely be fixed.

Do you, by any chance, have nocaptcharecaptcha module installed?

[datakick]

BTW, this error is very often displayed when debug mode is enabled, and there is some (sometimes even unimportant) warning on the page. These notices or warnings were printed into standard output. If the client expects json response, these messages effectively destroyed it.

Response like this is not a valid json, and can't be parsed by front end javascript:

PHP Deprecated: The each() function is deprecated. This message will be suppressed on further calls
{"hasErrors": false}

Because javascript code fails to parse this response, error handler is shown, resulting in the error message you have seen. 

Note that the source of this notice/warning might not even be in thirtybees core. Any installed module can caused this. 

That's one of the reason we have revamped error reporting mechanism, and no longer print php error messages into the standard output. 

 

[musicmaster]

Thank you for your reaction. I use Eicaptcha. I will try disabling it.

I know that php error messages can give such problem when debug mode is on. However, in this case debug mode doesn't make a difference. In both cases the ajax just returns nothing or a 500 error - depending on where you look.

I would like to keep the option to have php error messages in the standard output. The place where an error message occurs in the output is sometimes an important indicator of what is wrong.

[datakick]

23 minutes ago, musicmaster said:

I know that php error messages can give such problem when debug mode is on. However, in this case debug mode doesn't make a difference. In both cases the ajax just returns nothing or a 500 error - depending on where you look.

When ajax call returns 500 error code, then there's really nothing (at the moment) javascript ajax handler can display, only a generic message that something went wrong. Frontend doesn't know any details, since server did not provide it. We can format the error message to be more user friendly thant Details: Error thrown: [object Object] Text status: error, but it will still have the same amount of information. 

If the 500 error page is generated by thirtybees error handler, then we could potentially do something about it in the future. If it's an ajax request that EXPECTS json response, we could format error message to some json object and return it. This would required assistance from front-end javascript, though -- it would have to somehow advice server that it can process this new json error response.

If it's 500 error page generated by your server (apache, ngingx), that means that there is some fundamental error that terminated script execution. For example syntax error. We can't do anything in these cases, but to display generic 'Something went wrong' message.

 

[musicmaster]

On one server it does work. So maybe it has something to with ports that are closed. But how to know when you absolutely clueless about what causes the problem?

[lesley]

The message is caused by either a 500 error or php notices / warnings. Check the php error logs to see what error is being thrown. 

[KolS]

On 3/26/2019 at 1:03 PM, musicmaster said:

Same problem for me. The thing works ok on localhost but not online.

This is a very serious problem. 

"Details: Error thrown: [object Object] Text status: error" is just horrible as a bug report. You might just as well say: we had a bug and we won't bother to tell you what it was. Is it really impossible to have something better? 

I'm having the same error right now. Please help. How we can resolve this?

[KolS]

On 10/10/2019 at 10:54 AM, basix101 said:

Solved it by:

Turning off Debugger Advanced Parameters/Performance/Debug Mode

Turning on SSL in Preferences/General/Enable SSL

Also turned off and on Preferences/SEO's Friendly URL

Turning on SSL in Preferences/General/Enable SSL solved mine but I have to re upload the new demo site.

[dareCzech]

Solution in my case was to change length of the password in /override/classes/Customer.php to the value 60 (password data type in database is varchar(60)).

Specifically this line:
'passwd' =>                    array('type' => self::TYPE_STRING, 'validate' => 'isPasswd', 'required' => true, 'size' => 32),

to

'passwd' =>                    array('type' => self::TYPE_STRING, 'validate' => 'isPasswd', 'required' => true, 'size' => 60),