Problem/Motivation
Hi,
we are using the contrib module real name for the user display name. If you use the real name "field" as a filter, the real name value is a string attached to the user object.
$raw_field = $entity->$real_field_name->value;
$raw_field = $entity->realname->value;
The $entity->realname is a type of string, and we got the error message Warning: Attempt to read property "value" on string.
Steps to reproduce
- Install the real name module and config the real name value setting
- Add as a filter to a user view and expose it with views autocomplete filter
- Search for a real name value and get the error message above. No autocomplete dropdown will be rendered
Proposed resolution
It is a really specific problem with the contrib real name module. So I don't know if you want to change it at all. But I added a "if type check" from
$raw_field = $entity->$real_field_name->value;
to
$real_field = $entity->$real_field_name;
if ($real_field instanceof FieldItemListInterface) {
$raw_field = $real_field->value;
}
elseif (is_string($real_field)) {
$raw_field = $real_field;
}
and it works for my use cases. I am unsure if FieldItemListInterface is sufficient for all fields in exposed forms.
| Comment | File | Size | Author |
|---|---|---|---|
| #11 | 3393550-11.patch | 1.46 KB | jonasanne |
| #2 | 3393550-2.patch | 1.25 KB | mvogel |
Issue fork views_autocomplete_filters-3393550
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #2
mvogel commentedattached patch
Comment #3
shalini_jha commentedComment #4
viren18febs commented#2 is working for me so moving to +RTBC.
Comment #5
vasikesorry guys, but thanks
This can't considered as bug report, as this too specific to a module, so i would say it's a feature request.
Also this means it should be for the next D10 version (first).
Also there was an update https://www.drupal.org/project/views_autocomplete_filters/issues/3394657 which probably "messed around" your patch.
Is there another "similar" case where this patch could "save the day"?
Also do you have any thoughts or suggestions, about a need of hook or something that could easily fix such custom cases?
As it is hard to solve all contrib cases.
Just saying ....
Thanks again for all efforts and support.
Comment #6
mvogel commentedYou are right. Inversion of control should be the approach here. I will think about it and make a proposal later.
Comment #8
mvogel commentedI created a merge request.
I defined an alter hook to change the value for the autocomplete result. The will run after the default code so contrib or custom modules can change it.
I made the original code null save by adding
?->Because otherwise, it will generate watchdog entries for the 'realname' fields.
I don't know if this adds too much complexity, and if it is a straightforward approach, I tried to document as much as possible and give the hook as much context as someone may need.
Comment #9
mvogel commentedI forgot to change the status to "needs review"
Comment #10
vasikeThread on MR + conflicts with the latest updates.
+ update the issue title to cover the solution needed.
Comment #11
jonasanne commentedReroll patch from #2 for 2.0.2