Posted by xjm

Problem/Motivation

This issue is spun off from #1847596: Deprecate Taxonomy term reference field in favor of Entity-reference.

The bundle selection for an entity reference field is probably the most important piece of configuration for that field. E.g., in the case of a node reference, the user wants to create a reference to their song nodes on their album nodes. In the case of taxonomy, the user wants to add their topic vocabulary to their pages. It's the first thing the user probably wants to choose.

Currently, however the bundle selection for reference fields is buried on the bottom of the third screen of the field creation workflow, under a fieldset ("Reference type") and parent field ("Reference method," "default") that, to the end user, have nothing to do with selecting the bundle they want to use. This makes adding and configuring ER fields confusing.

bundles.png

Proposed resolution

There are a few ways we could go about fixing this, all with pros and cons, not necessarily mutually exclusive.

  • Make the bundle selection a field-level setting rather than an instance setting. (What is the usecase for having wholly different referenced data on instances of the same field?)
  • By default, only enable the default reference method. Make overriding the reference method with a view or such a separate configuration.
  • Move the bundle selection up above the fold somehow. It doesn't make sense for it to be after the default value list, since it determines what's possible in the default value list. Is the current form ordering the result of Field API limitations?
  • Improve the label for the "default" reference method.
  • Improve the labeling for the "reference type" and "reference method".
  • Other suggestions?

Remaining tasks

  • Discuss possible approaches.

User interface changes

TBD

API changes

TBD

Files: 
CommentFileSizeAuthor
bundles.png19.28 KBxjm

Comments

Make the bundle selection a field-level setting rather than an instance setting. (What is the usecase for having wholly different referenced data on instances of the same field?)

This is a major limitation in the D7 contrib module, which I worked hard to remove from the D8 code, see #1340098: Move target bundle to the field instance settings. @andypost will hunt you down for even suggesting it, he was pretty vocal about this specific issue in Munich :)

By default, only enable the default reference method. Make overriding the reference method with a view or such a separate configuration.

I guess this could be done, but then the complexity is added in another place. And the ability to provide the entity selection list through a view is also a much requested feature (242 comments!) in contrib: #1253776: Add views support for providing a list of entities or bundles (views filtering, relationships, etc)

Move the bundle selection up above the fold somehow. It doesn't make sense for it to be after the default value list, since it determines what's possible in the default value list. Is the current form ordering the result of Field API limitations?

The bundle selection is provided by that 'default' setting, so I don't see how it could be moved from below it without a very distracting UX (change the value of a select widget and see that some part of the form was changed *above*).

After all that, I see label improvements and probably adding more description text as our only real choice here..

The bundle selection is provided by that 'default' setting, so I don't see how it could be moved from below it without a very distracting UX (change the value of a select widget and see that some part of the form was changed *above*).

Well, this is already happening with the default values, since changing the allowed bundles changes the possible default values.

IMHO there has to be some way to simplify the 80% (more like 95%) case of selecting a reference for one bundle while sill allowing the underlying flexibility of selecting multiple bundle types, filtering entities with a view, etc. We just haven't found it yet. :)

Another crazy thought. What if we added something like an "Add a field to..." option to the dropbutton for referenceable entity bundles (content types, vocabularies, etc.) It would mean introducing an additional possible workflow, and I've no idea how we'd accomplish that in the backend, but it would make it a ton easier to create to just quickly create a term reference or content type reference field. It would also help address one of the ongoing usability problems throughout Drupal: "I made this thing, but now how do I put it somewhere?"

Maybe hide the "Reference method" select by default, only keep the "list of referenceable bundles" checkboxes visible, with an "advanced" link or button that shows the "method" select back ?
When editing an existing field that uses a method other than "default", the form is displayed in "advanced" mode upfront.
I guess accessibility constraints imply doing this through ajax ?

Doesn't preclude the "initiate 'add reference field' action from the admin page of the bundle you want to reference" flow proposed in #3, but seems simpler to implement. I'm not sure how e_r would figure out the locations (which pages / in which dropbuttons) it should add that "add a field referencing that bundle" link.

Issue summary:View changes

Updated issue summary.

Issue summary:View changes

Removing myself from the author field so I can unfollow. --xjm