json_decode() expects parameter 1 to be string, array given

[Bauer]

This error comes up at line 1460 of ./components/com_fabrik/models/groups.php

It may not be a fatal error - I only discovered it because it stopped the inlineedit plugin from working in a list I am using.

Sure enough the line before initializes $origGroupRowsIds as an array.

I'm not sure if this is the correct fix - but it at least allowed the inlineedit plugin to function. I just replaced line 1460...
$origGroupRowsIds = json_decode($origGroupRowsIds);
with...
$tmpGroupRowsIds = array();
foreach($origGroupRowsIds as $gid)
{
$tmpGroupRowsIds[] = json_decode($gid);
}
$origGroupRowsIds = $tmpGroupRowsIds;

 

[cheesegrits]

Hmmm. That data should always be a JSON string, period. Maybe there's some weird route through the code to reach that point with inline edit.

        $origGroupRowsIds = FArrayHelper::getValue($origGroupRowsIds, $groupId, array());

It's not actually "initializing" it to an array, that's the default if $groupId doesn't exist. So barring "some weird route through the code", the only time I'd see it winding up as an array would be if $groupId didn't exist (which it always should, but again ... inline edit ...).

However, as you know, inline edit is funky as all get out (which is why we've quit working on it), so it's possible we may wind up there with an array, or emptyness.

Anyway, I think the correct approach would be ...

        $origGroupRowsIds = FArrayHelper::getValue($origGroupRowsIds, $groupId, '[]');
        $origGroupRowsIds = FabrikWorker::JSONtoData($origGroupRowsIds, true);

This replaces the erroneous default to be an empty JSON array, then calls FabrikWorker::JSONtoData, which is basically a wrapper around json_decode(), specifically for handling this kind of eventuality, where the data might possibly not be JSON, and handles all (well, most) eventualities gracefully.

Give that a go, let me know.

If you could also test "normal" group deletion as well as inline edit, I'd appreciate it.

-- hugh

 

[Bauer]

The suggested code now causes the inline edit popup to be displayed as detail - no editing allowed - which sort of kills the purpose of using inline editing.

For the record, this is a datbasejoin element being used in the parent table in a list containing repeat groups - not in the repeat group itself. (I know that was always an issue.)

So if this inline edit plugin has so many issues - and you are no longer going to develop or support it - why not just remove it from the fabrik package once and for all to prevent users a lot of heartache?

And I suppose, if you are going to trash the inline edit plugin - or at least stop supporting it, I should switch to another method.
Yet I hate to see it go, rather than being fixed, as that was one of the plugins I was most interested in years ago when I first discovered fabrik - and it is critical to the way I wanted this particular list to work, because it is the only element that is editable in the parent table.

 

[cheesegrits]

We haven't decided if we're going to trash it, we simply don't have time to work on it. We've already spent many hundreds of hours on it, and anything to do with working on it eats time at a ferocious rate. We very clearly document this in the wiki:

NOTE - this plugin is provided "as-is", and we will not be doing any more development or bug fixing of it in the 3.x versions of Fabrik. Please test the functionality you need, before committing any app design to rely on using it. It works for simple use cases, but may not work as expected for "complex" usage, involving menu pre-filtering, element ACL's, joins (as mentioned above), non-trivial form plugins (such as PayPal), etc.

For simple use cases, it works. Which for a lot of existing users is all they need. So no, we're not going to just remove it. We clearly tell people that they may be in for heartache if it doesn't work off the bat for them, and that we aren't going to be doing any more work on it right now.

If someone(s) wants to fund us to do development on it, that'd be a different matter. Or if people want to work on it themselves and fix issues, and I'll help when I can with stuff. Like this issue - I'll try and free up some time to reproduce it, but I can't guarantee anything. This is Zen Master level of code complexity, and any time I work on it it takes me half a day just to wrap my head back round how it all works.

-- hugh