Parse json field value in calc

I have a multi-select field called services. Here's a sample value:
["Cut Lawn","Trim Hedge"]

Now I want to combine it with a date field to come up with a field that reads:

Cut lawn, Trim Hedge - 2022-11-01

First, I need a clean version of this text, and that's where I get into trouble.
$blurb = json_decode('["Cut Lawn","Trim Hedge"]') //this works fine, as a hardcoded test string, yet...
$blurb = json_decode('{jobs___services}') //comes out null
$blurb = json_decode('{jobs___services_raw}') //comes out null

So I thought to take a longer approach and just cut the offending characters from the string. Easy enough for the square brackets, but nothing seems to work for the quotes.
return str_replace('"','', '{jobs___services}'); //comes out unchanged from the original
return str_replace('\"','', '{jobs___services}'). //escaping the character doesn't help.

What's going on?
 
With $blurb = json_decode('{jobs___services_raw}'), try var_dump($blurb) or print_r($blurb), then you'll see that you're getting an array, which you can easily implode(', ', $blurb) and concatenate with the hyphen and date.
 
Last edited:
Thanks, but that doesn't actually work.

return var_dump(json_decode('{jobs___services_raw}')); // returns NULL

check to see that the string is there....
return var_dump($blurb = '{jobs___services_raw}'); // returns: string(45) "["Cut Lawn","Trim Hedge"]"

okay, so the string is there. Is there something about the way it's formatted that makes json_decode fail...try the literal...

return var_dump(json_decode('["Cut Lawn","Trim Hedge"]')) // returns array(2) { [0]=> string(8) "Cut Lawn" [1]=> string(10) "Trim Hedge" }

json_decode works with the identical string if it's provided as a literal.

Problem is the same in both F3 and F4-alpha 3. Could the problem of not being able to strip quote characters from a string be related? Seems like there's some weird interpretation of the field values going on that prevents normal parsing.
 
Maybe this is a clue... when I do a var_dump of the field, it says the string is 45 characters long, but the equivalent output as a string would be 26 characters. I only count 26 characters.
 
Can you change double quotes to single quotes in your JSON string? What happens then?

Just shooting in the dark, haven't made any tests.
 
Apparently, I cannot.

Code:
$blurb = '{jobs___services}';
$blurb = str_replace('"', ''', $blurb);
return var_dump($blurb);
returns string(45) "["Cut Lawn","Trim Hedge"]"

Even though
Code:
$blurb = '["Cut Lawn","Trim Hedge"]';
$blurb = str_replace('"', ''', $blurb);
return var_dump($blurb);
returns string(25) "['Cut Lawn','Trim Hedge']"
 
You forgot _raw. And json_decode etc should work.

Copy and paste this exact code instead of yours, please, and let us know:
Code:
$blurb1 = json_decode('{jobs___services_raw}');
$blurb2 = implode(', ', $blurb1);
return $blurb2.' - 2022-11-01';
 
... and if the previous one doesn't work, try this instead:
Code:
$blurb = '{jobs___services_raw}';
$blurb1 = json_decode($blurb);
$blurb2 = implode(', ', $blurb1);
return $blurb2.' - 2022-11-01';
 
Sorry, neither of those work because whether I use raw or not, the string does not get interpreted as json. The results I get when adding _raw are identical to the results I first posted

$blurb = json_decode('["Cut Lawn","Trim Hedge"]') //this works fine, as a hardcoded test string, yet...
$blurb = json_decode('{jobs___services}') //comes out null
$blurb = json_decode('{jobs___services_raw}') //comes out null
 
In a calc element:
  • return '{jobs___services_raw}'; // ["Cut Lawn","Trim Hedge"]
  • return '{jobs___services}'; // ["Cut Lawn","Trim Hedge"]
  • with or without raw, json_decode fails
  • with or without raw, str_replace fails to remove quotes
In a form plug-in:
  • $blurb = json_decode('{jobs___services_raw}'); // NULL - same without raw
  • $blurb = '{jobs___services_raw}' ; // Cut Lawn,Trim Hedge - same without raw
I don't understand why the same php has different outputs depending on the plugin. I don't understand why _raw is the same as not-raw. I don't understand why something that looks exactly like json cannot be treated as json. I don't understand why the square brackets are included in the output of the calc element but not in the form plug-in. And I don't understand why str_replace cannot remove the quotes in the calc plugin.

I guess I found a workaround, using the form plugin. But I gotta say, long after the future of Fabrik is on firmer footing, it'll be weird quirks like this that make me wonder whether I should be investing my time in using this tool!
URRGG!!
 
I've tested my code
Code:
return '{jobs___services_raw}'.' - 2022-11-01';
with a multi-select dropdown element named "services", storing the exact same raw value ["Cut Lawn","Trim Hedge"] in the corresponding DB cell -- I only used a different table name.
A calc element with my code then returned exactly what you want: Cut Lawn, Trim Hedge - 2022-11-01
So, it worked for me, and I have no idea why it doesn't for you. Something must be still wrong at your end, and from here I can't tell what, sorry.
 
Weird! I'm trying this on both a F3/J3 and an F4/J4 system, hosted at different hosts and both return the results that I'm seeing. Out of curiosity, can you please copy and paste the stored value from your table itself? Mine is stored with the brackets and quotes: ["Cut Lawn","Trim Hedge"]
 
Ditto here
Code:
["Cut Lawn","Trim Hedge"]
Stored in my calc DB cell
Code:
Cut Lawn,Trim Hedge - 2022-11-01
with calc code (my own placeholder, of course)
Code:
return '{jobs___services_raw}'.' - 2022-11-01';
with "Only calc on save = yes", else at default.
F3 Github and PHP 7.4
 
FWIW, I stumbled across FabrikWorker::JSONtoData a while later and that did the trick! I'm guessing that because I'm on PHP 8.1 for this, that made the difference. Thanks for the input, folks.
 
...I'm on PHP 8.1...
Just like J!3, Fabrik 3.x must not be considered compatible with PHP 8.1.
AFAIK, Fabrik 3.x is not even (fully) compatible with 8.0, although a lot of effort has gone into it, and more is under the way, supposedly.
 
We are in need of some funding.
More details.

Thank you.

Members online

Back
Top