Javascript freeze on row deletion

[Bauer]

If I delete a row that has a Yes/No element the page will freeze with just the ajax spinner showing. I'm not sure if this will only happen on of deletion, but that's when it happened in this case.

The error log is filled with...
[13-Apr-2016 09:38:44 America/Denver] 166 whatnothing Backtrace from warning 'Undefined property: PlgFabrik_ElementYesno::$tmpl' at /home/public_html/plugins/fabrik_element/yesno/yesno.php 76:
(One error line for each row in the list)

The fix at line 76 of yesno.php is...
//$displayData->tmpl = @$this->tmpl;
$displayData->tmpl = isset($this->tmpl) ? $this->tmpl : '';

I've been fixing that after a github update for I don't know how long.

 

[troester]

endless spinners etc:
ususally thoses warnings/notices will break the expected JSON of the network response (typically you can see also something like "unexpected token..." in the browser dev console).
If it's no severe error it may be ok if you set Joomla's error reporting to simple or none.

 

[cheesegrits]

That must be a PHP 7 thing. That line uses the @ error suppression, which should squash any error reporting ...

http://php.net/manual/en/language.operators.errorcontrol.php

... and I don't have any problems deleting rows with yesno elements in them in 5.5, even with error reporting at max.

As I said in a reply on another thread, I strongly recommend punting back to 5.6, and wait to use PHP 7 when we release fabrik 4.0, which we will be putting some actual serious effort into PHP 7 compat for. Even if this particular issue isn't 7 related, you are definitely going to be making problems for yourself using it with Fabrik 3.x as-is.

And as Troester says, you do need to turn error reporting off, or at least lower it so you are only reporting errors rather than notices, as any error report generated during an AJAX call will break the Javascript calling it, as the error report breaks the JSON response parsing.

I keep meaning to submit a PR on J! itself, to allow things like J! debug mode and error reporting to be applied on a usergroup basis. So you can have a group for which debug and error reporting is enabled, but for everyone else it isn't.

All that said, I'll go and apply that fix in github.

-- hugh

 

[cheesegrits]

https://github.com/Fabrik/fabrik/commit/3e300eaf56110241cb381da0b6e4c81954973f3c

-- hugh

 

[Bauer]

Thanks!

 

[Bauer]

That must be a PHP 7 thing. That line uses the @ error suppression, which should squash any error reporting ...

http://php.net/manual/en/language.operators.errorcontrol.php
[...]
And as Troester says, you do need to turn error reporting off, or at least lower it so you are only reporting errors rather than notices, as any error report generated during an AJAX call will break the Javascript calling it, as the error report breaks the JSON response parsing.

I'm pretty well versed on error level settings. And as you know, I'm not one to just ignore 'Warnings'. Because, as you also know and admit, many times those warnings are what leads to other fatal errors later on - or worse yet incorrect queries run - which might corrupt the database table or prevent table from being updated as expected.

I now know that the first thing to do is change the error level in cases involving ajax issues.

That said... Please clarify this. I'm already aware that any debugging code that uses php 'echo' might break the script (especially if the script is used by ajax). But does that mean that any php debugging code that I have writing to the php error log might also break the script?