Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Problem/Motivation
The views integration of Search API currently "doubles up" the available fields in views if relationships are used. As far as I know this is due the fact that Search API uses a specilized table but names the fields the same way as views does.
This leads to a really painfull user expirience when working with relationships (Choose both available fields, add them & remove then the one not needed).
Proposed resolution
I'd propose to do something like fago proposed in this comment: #1266036-88: Add generic Views entity tables with fields and relationships
So maybe we should just fix the names of the search api index fields to be named differently? E.g. "Indexed node: Title"?
The attached patch adds a the prefix "Indexed " to the table group - this leads to nice field label prefixes and even a specialized group in the views field selection.
Remaining tasks
Review patch in #3.
Decide what group label to use.
User interface changes
Labels of the fields provided by Search API will change in views.
API changes
none.
Comments
Comment #1
das-peter CreditAttribution: das-peter commentedAdded Views sprint tag.
Comment #2
drunken monkeyThis needs a
t()call.Also, I'm really not sure whether this won't be confusing in a different way. „Indexed“ might carry some invalid implications which might confuse users. And I'm probably the worst judge of that, as I of course know what goes on there, which can't be expected of users.
Maybe not using the entity type at all, but just „Search result“ might be even better?
Would be great to get some more input to this.
Comment #3
das-peter CreditAttribution: das-peter commentedAdded
t()and switched to simply name it to „Search result“.Frankly speaking I don't give the used prefix that much priority as long as there's a way to distinguish between what I've to click.
Comment #4
drunken monkeyI've asked fago for his opinion, he usually also has some ideas about such UX issues.
And I understand, being able to distinguish the two at all is of course most important.
Comment #5
fagoImho both options would be a good improvement. Still, having the entity type included probably makes sense, so the users always has a clear context (oh, yes it's a node.. :D).
Thus, I'd vote for "Indexed %entity-type".
Comment #6
drunken monkeyThanks for the input, Wolfgang, then let's do it that way!
The attached patch also contains a small note in the README.
Comment #7
das-peter CreditAttribution: das-peter commentedReadme addition looks good and also with the naming I'm absolutely happy.
From my point of view this deserves RTBC.
Comment #8
fagoLooks good to me too!
Comment #9
drunken monkeyCommitted.
Thanks, you two!
Comment #10.0
(not verified) CreditAttribution: commentedUpdated issue summary.