Currently when someone uses an Entity Reference field to reference nodes of more than one content type, there is no good way to distinguish one type of node from another. For example there may be "Season" nodes and "Person" nodes referenced by a single ER field, yet there could be more than one node titled "Autumn" or "Summer" (both of which can be both a person's name and a season).
Since entity reference field already has a "Sort by" field for the Simple entity selection, why not allow rendering that sort criteria as a Group heading to distinguish one group from another. A simple checkbox "Render Group Headings" or something similar could act as an on-off switch.
Here's how ER field currently renders:
Here's how I'm proposing it should look:
Comment | File | Size | Author |
---|---|---|---|
entity-ref-proposed.jpg | 9.01 KB | nodecode | |
entity-ref-current.jpg | 14.97 KB | nodecode |
Comments
Comment #1
jbrauer CreditAttribution: jbrauer commentedThis is a duplicate of #1812968: Provide option group for referenceable entities (though the documentation and suggested UI here is more complete.
Comment #2
spacerabbit CreditAttribution: spacerabbit commentedI've used an Entity Reference view display to generate a list of relations to be used in cck edit/node.
I've tried to group that list by field in the format settings (in my case was by taxonomy term field) and the auto preview is perfectly working.
Unfortunately when I load the view in nodetype (as Entity Reference field) the list is not grouped. Imho, it would be really usefull using "format settings" to group the entityreference list. Thanks
Comment #3
nodecode CreditAttribution: nodecode commentedMarked the other issue #1812968: Provide option group for referenceable entities as duplicate since this is better documented and explained. There were no objections when I asked in that issue queue.
Comment #4
tisteegz CreditAttribution: tisteegz commentedHas this now been added into the code? I currently have an entity reference field which is grouping by Bundle and I would really rather it not do this. Before I create a separate issue for this I want to mark this issue as complete.
Comment #5
nodecode CreditAttribution: nodecode commentedThere has been no progress on this issue whatsoever so there is no reason to mark this as complete.
Comment #6
geek-merlinjoin the party, this is part of (or followup to) #1782324: Add grouping info for select / options list
Comment #7
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedReopening this one because the problem that remains is better explained here. See https://drupal.org/node/1782324#comment-8786965 for more details why.
Comment #8
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedComment #9
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedWow, I thought I could just, in the mean time, use the "Views: filter by an entity reference view" selection mode and create a custom view that actually groups terms by vocabulary but above all displays the vocabulary name... but even that is not working! Terms are properly grouped but the vocabulary name is removed by entity reference! :(
Guess I'm gonna have to stick with a Field Collection of three different entity reference fields... or dig into the code but not much time for this right now.
If anybody has a quick workaround to make it possible to display Vocabulary name I'd love it!
Comment #10
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedI just had a look at the patch from the issue I just closed: https://drupal.org/node/1782324#comment-8676649 but it seems this issue was more about displaying grouping info only when "Views: filter by an entity reference view" option is selected, in other words, only for Views integration but not default Entity Reference behavior.
It looks like displaying grouping info has been solved already for select list at a global level (not only for Views) and it also impacts Views integration. However, entityreference_plugin_style.inc still has the line // @todo We don't display grouping info for now. Could be useful for select widget though. Which means the fix has not been made in this file. Which is logical since the fix is general. Which means patch should not be done here IMHO.
This leads me to the conclusion that we should find out how/where displaying grouping info has been solved for select lists and that we do the same for check boxes / radio buttons widget.
Maybe this has been documented in another issue.
Comment #11
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedIt looks like the limitation comes from Drupal Core Field module. From hook_options_list to be precise.
https://api.drupal.org/api/drupal/modules%21field%21modules%21options%21...
As you can see in the code
Grouping is only supported for the select list widget, not checkboxes and radio buttons.
Entity Reference implements this hook on line 761 of entityreference.module file. If you dpm() the $return variable you can see that all the data needed to display group labels is there.
Comment #12
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedIn modules/field/modules/options/options.module
function options_field_widget_form() calls function _options_get_options() where the following code is executed:
this is where the options get flattened out. So maybe we need to provide $properties['optgroups'] for it to work
Comment #13
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedin function _options_properties(), the optgroup property is set to true for selects:
but not for buttons:
now if I change it to:
the options_array_flatten() is not called anymore but the group rendering fails... instead of having three groups of checkboxes, I have three checkboxes with the "Array" label...
Comment #14
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedI've managed to make this work by modifying the core so I've opened a feature request in Drupal core issue queue to see if that can be added https://drupal.org/node/2269823
this discussion should perhaps be continued out there...
Comment #15
Nicolas Bouteille CreditAttribution: Nicolas Bouteille commentedMarking "works as designed" since Entity Reference is already doing all it needs to / can do and it actually is a limitation in core.
For those really needing this, if the core feature request is still not added in core when reading this, I suggest you create a Field Collection (reusable throughout content types) of as many Entity Reference fields as vocabulary or content types you need. This can actually give you more control over things and I guess you can also mix content types and vocabularies, although I don't see any use case for that :)