Empty options list should not be shown when editing a field that has no allowed values (for example, a term reference field whose vocabulary has no terms)

I can fix this, I think.

Rolled against HEAD; makes _taxonomy_term_select return array() when there are no non-"blank" terms. I return array() instead of NULL because I seem to remember that the Form API got notice- or even warning-level hiccups on NULL elements... could be wrong though.

I have tested this successfully with a simple empty vocabulary, but I may have missed some more complex cases if any exist.

Also fixed two notice-level errors for $_POST elements on line 1444.

No longer applies.

One of the two functions changed in the patch has moved to an admin.inc file. On checking this file, it turned out the change of the patch has already been implemented (character for character). The revised patch therefore contains only the first hunk.

Still applies with fuzz to D7. We should add a test for it.

Here's the defuzzed D7 patch.

I'll try a test case if my testing setup works right now. It seems to randomly blow up in my face sometimes.

This still holds true for require fields with no data although as we are now working off fields api the apoproach needs to change and arguably this is a task rather than a bug.

Going to move this to field system.

_taxonomy_term_select() doesn't exist anymore, not even in D7: #603702: Die, _taxonomy_term_select(), die!

This is still reproducible in both Drupal 7 and 8. Just create a vocabulary with no terms in it, then add a (non-required) term reference field that uses that vocabulary, and set the widget to either checkbox/radios or a select list.

When creating content, you'll see a widget that has no options besides "N/A" or "None" in it.

That looks pretty ugly. Although in some sense it's a site configuration issue, it is still probably something Drupal should handle better.

Retitling a bit based on #7 and #8 (since in D7/D8 this is not specific to taxonomy).

Hm.. interesting. This is be a possible fix, but I think the real question is: do we really want to hide the widgets in that case? Wouldn't it cause more confusion than showing only the "N/A" or "None" value?

Moving to 8.1.x since it's not a bug.

Back to NR, but it actually needs a usability review.

And what if the field is required ?

Let's try this tag :)

Testing #12 with the scenario described in #10, making the field not required.

1. I guess this patch hides the input element when there's nothing to enter? Because I don't see it on the node form :)
2. When you make this field required you cannot save the node form, getting an error "This value should not be null."
3. Another interesting side effect:

- I initially create the field as not required
- then configure the form display to check boxes/radio buttons
- Go back to edit the field (/admin/structure/types/manage/article/fields/node.article.field_emptyvocab) and without changing anything save settings: BOOM! "Fatal error: Call to a member function uuid() on a non-object in /home/r0re7/www/core/lib/Drupal/Core/Field/EntityReferenceFieldItemList.php on line 131

Could we do something along the lines of the empty pattern we have for listings on admin pages? The table on /admin/structure/taxonomy/manage/no_term_vocab/overview will show "No terms available. Add term.", where Add term is a link.

We want to prevent people from getting into this situation in the first place. Can we detect it and:
- for site building: use the empty pattern with the Add term link?
- for content creation: show "No terms available" but let them save the content item anyway (and store "None" as the value)?

Thanks @yoroy for taking a look at this :)

You are right that we can and should provide separate output for the two situations. However, there are a few problems with the suggested approach:

- for site building: we can use the empty pattern here, but the "Add term/entity" link is problematic because entity reference fields can have multiple target bundles (e.g. vocabs, content types) so we do not know which bundle to use for the 'Add' link

- for content creation: this one is even trickier because having any kind of output from the widget (i.e. a form element or just some simple markup) will trigger all kinds of entity validation code paths, and we'll have to find a way to bypass all of them, but at least in theory I think it's possible :) So, before even attempting to find a way to bypass validations for this case, are we really sure that it is desirable to show the 'No terms/entities available' text even if the content author doesn't have any way to "fix" that?

I think it makes sense to show a 'no items available' message (without the link) for both scenarios because the author might be the builder as well and so would have a way to fix things. Even if the author could not fix it, she or he could at least know and tell somebody else there's something missing.

(This generalized entity concept sounds problematic for turning Drupal outside in! If we can't know what kind of thing some widget is targetting, that will make it very hard to map UI flows to specific user expectations. At least, that's what I am getting from this)

Hmm, maybe hide everything for the content creating part after all, as long as there are no errors shown either.