Why Ajax can hang navigating list embedded in form intro...

[LeslieBrown]

I wasn't sure whether it was worth reporting this as it's probably a bit of a corner case. However, I then realised that it might have wider implications (see end of this post).

Also, as it took me a long time to work out what was going wrong, I thought I could at least save somebody else the same trouble.

Context
I have a list where each row contains a "title" field, a description, and some other stuff that's irrelevant here.

I wanted to display a stripped-down list - just the titles - down the left side of each details page, so the user could navigate to other pages without having to to-and-fro between details view and list view. After fiddling about with Joomla modules I found this thread and realised I could incorporate the list in the form intro.

Which I did. And it worked. Magic!

To check that it would still work when the list filled up, I set "Rows per page = 5" and "Show navigation = Yes" in the list's navigation parameters and added 7 rows.

Problem
The initial display was OK. For example, in the details view of Row 1 the list displayed the menu with the titles for rows 1 to 5, plus the navigation bar, with inactive links for First, Previous, and Page 1 plus active links towards Page 2, Next, and Last. However, when I clicked on the Page 2 link I got a spinner, which lasted...forever.

Checking the php error log I saw some notices

Undefined offset: 0 in D:\sites\mtc\build1\components\com_fabrik\views\list\view.raw.php...

This is the line that says

$o->groupHeading = $model->groupTemplates[$groupk] . ' ( ' . count($group) . ' )';

And $model->groupTemplates was an empty array...
After spending hours trying to work out what was going wrong server-side I did what I should have done in the first place and turned on Firebug. Javascript was hanging in mootools-core.js, in the last (eval) line of the JSON.decode function, with a missing ')' error.

JSON.decode = function(string, secure){
 if (!string || typeOf(string) != 'string') return null;
 if (secure || JSON.secure){
  if (JSON.parse) return JSON.parse(string);
  if (!JSON.validate(string)) throw new Error('JSON could not decode the input; security is enabled and the value is not secure.');
 }
 return eval('(' + string + ')');
};

The string in question had the php error notices at the beginning, each prefixed by an '\n'.

Workaround
I kludged a fix by adding an @ to the line that was causing the errors.

$o->groupHeading = @$model->groupTemplates[$groupk] . ' ( ' . count($group) . ' )';

While this fixed the problem by suppressing the error messages I wasn't happy with hacking the system for something I didn't understand. I made a minimal test case:

• Clean Joomla install
• Clean Fabrik install
• Create just one list with one form and two non-default elements: Title and Content
• Assign the template "default" to form and list
• Embed the list in the form intro
• Add 13 rows to the list

...impossible to reproduce the problem.

Solution

After another few hours trying to work out what I'd changed in the buggy site, it suddenly struck me that I had set Error Reporting = Maximum in Joomla/Global Configuration/Server.

• Setting Error Reporting = Maximum in the minimal test case caused the problem to occur
• Setting Error Reporting = System Default in "my" site removed the problem

So, no action needed, but...

Wider implications?
What worries me is that there might well be other cases where having maximum error reporting blows up Ajax interactions by injecting php error messages into the return code. If so, I wonder if a general fix is possible... maybe some kind of filtering on the return values?

 

[troester]

This is going to Rob/Hugh.

But I think you've got the wrong forum (Fabrik2).

 

[LeslieBrown]

Ooops, you're right. In fact, I never even noticed the 2/3 divide... Is there a way to move it to the right one?

 

[troester]

Moved......

 

[LeslieBrown]

Thanks, not only for the move but also for your suggestion of using a list placeholder in the form intro in the thread I quoted above. (In my final version of the site, I'll probably put the list placeholder in the form outro and float the details view to the right so that the details view comes first: better for search engines?).

 

[LeslieBrown]

Just an afterthought. The list had no groupings specified whatsoever, which might be the explanation of why $model->groupTemplates was an empty array. Perhaps in this case it ought to contain an empty element with index 0?

 

[rob]

thanks for the catch - I've added code so that that notice won't appear.
PHP error levels are tricky to manage.
Ideally your development sites should have maximum error reporting on, and the live site possibly with display errors off, but still logging the errors to the php error log.
I try to code with maximum error reporting on to try to catch any notices which might cause issues.

 

[LeslieBrown]

Ideally your development sites should have maximum error reporting on, and the live site possibly with display errors off, but still logging the errors to the php error log.
I try to code with maximum error reporting on to try to catch any notices which might cause issues.

I agree 200%.