Value 'not found' returned by empty placeholder

[Bauer]

I'm just wondering when this started?
I have a databasejoin element named 'project_overview___fabrik_groups' that I reference in a calc element.

This line of code
$groups = '{project_overview___fabrik_groups_raw}';
used to assign an empty string ('') to $groups if '{project_overview___fabrik_groups_raw}' was empty.
(That would happen when editing of a new record)

I am now finding that if '{project_overview___fabrik_groups_raw}' is empty, $groups is a string that has been assigned the value 'not found'.

Why was this changed and why would you want to do that?
Wouldn't that change have messed up a lot of fabrik user's code (like mine) - if in the past they had been checking for an empty string and now it is no longer seen as empty (like this example)?

I suppose I'll first try requesting that this change be reversed before I have to spend days trying to find all places in my project where I check to see if the value of a placeholder is an empty string.

 

[cheesegrits]

Nope, I've not changed anything to do with empty placeholders.

The only candidate I can find (which has always been like this) is the multiOptionTargetIds() method in the databasejoin element model, line 3912, which would happen if we cant find the data for a multiselect.

https://github.com/Fabrik/fabrik/bl...k_element/databasejoin/databasejoin.php#L3912

Try editing that default string, and see if your calc comes up with your changed string. Then at least we'll know where it comes from, and can figure out why it's happening.

-- hugh

 

[Bauer]

There is no default - because the databasejoin element (project_overview___fabrik_groups) is configured as a multiselect dropdown,

But, just to accommodate your request, I tried assigning a default value.
1st I tried: 0 (zero)
Then I tried setting Eval to Yes and using: return '';

In any case, the placeholder '{project_overview___fabrik_groups_raw}' always returns "not found" (if echoed to the php error log) when editing a newly added row - or no option is selected. Otherwise it returns what I expect - a comma-delimited list of the selected IDs (e.g. "569,505,431").

So if I'm using a calc element that relies on that value, or a php validation to see that an option has been selected (i.e. Check that it is not a blank value, or empty array when the php explode() function is used), I will not get what is expected from the raw placeholder.

I'm still trying to figure out where that "no found" even comes from.

FYI - Using php v.7.1.9 and Joomla v.3.7.5 with a Fabrik update from github last done about 10 days ago.
And I'm now using (int) '{project_overview___fabrik_groups_raw}' to determine if empty - but that doesn't make it 'fixed'. This "not found" result is still goofy.

 

[cheesegrits]

No, I meant change that 'not found' default in the line of code I referenced, to see of that's where it's coming from.

Sent from my HTC6545LVW using Tapatalk

 

[Bauer]

Yeah that's definitely it.
Sorry I don't know how I missed that link or misinterpreted your reply - or why my initial search for 'not found' did not include the databasejoin.php file. (I haven't been well lately)

So what's the purpose of specifically assigning 'not found' instead of an empty string?
(It's happening because there are no option selections made.)

 

[cheesegrits]

I have no idea why we used 'not found'. We don't use that string for comparison anywhere else.

What I'm puzzled about is why the data doesn't exist. The _id key should exist, even if no selections are made. It should just be an empty array. I just tested with my 'multi select torture test' form, and I can't get it to behave the way you are seeing - even with no selections

I've committed a change to just use an empty string instead of 'not found', but given that the behavior changed on your site without me making any changes to cause it, and the fact that the data should exist ... I suspect there may be some more deeply seated issue causing it.

EDIT - I made a second commit which I *think* is the Right Thing To Do (to do with whether multiOptionTargetIds() returns false or an empty array. Don't think it'll affect your usage.

-- hugh

 

[Bauer]

I have no idea why we used 'not found'. We don't use that string for comparison anywhere else.

That was my point exactly.

What I'm puzzled about is why the data doesn't exist. The _id key should exist, even if no selections are made. It should just be an empty array. I just tested with my 'multi select torture test' form, and I can't get it to behave the way you are seeing - even with no selections

The ID won't exist yet in a new record, right? Did you test by referencing the dbj element using a (raw) placeholder in a calc element when adding a new record? (That's when/how it happens for me.)

I've committed a change to just use an empty string instead of 'not found', but given that the behavior changed on your site without me making any changes to cause it, and the fact that the data should exist ... I suspect there may be some more deeply seated issue causing it.

EDIT - I made a second commit which I *think* is the Right Thing To Do (to do with whether multiOptionTargetIds() returns false or an empty array. Don't think it'll affect your usage.

-- hugh

Thanks. That's what I would have expected you to do.
Like I said, it makes no sense to me that this 'not found' assignment got introduced out of nowhere.