Hiding a field using form modes should not remove it from the form object

@alexpott, we specifically didn't use #access => FALSE in the 'hidden' widget patch (#1465774: Provide a 'Hidden' field widget) in order to prevent bugs like this #1205822: File(s) silently deleted when #access=false.

Hidden fields are completely removed from the form object making form alters unnecessarily difficult.

I'm wondering what does that mean exactly.

The patch includes hidden fields in the form by using an arbitrary widget (the default_widget for the field type) and setting #access FALSE.

Not too fond of the idea. If the widget is changeable / hideable to begin with, it means form_alters can't rely on the structure of a specific widget anyway - you can only assume $form[$field_name]['widget'] at best, not what's inside. So why should we bother putting anything in there (default widget or anything else) ?

The big idea behind EntityFormDisplay is that it's the object that is passed through all the form build callstack to let code build the form according to what has been configured.

I'd say form_alters need to do the same (the EFD is in $form_state), and do their stuff based on how the form is configured; It feels weird to pretend the form contains stuff that aren't there to work around that ? (which, as explained in #6, you can only do to a very limited extend anyway)

Also note that hook_form_widget_alter() lets you alter what's *inside* a widget, and solves the question of "is the widget actually present or not ?" (the hook is not fired if the field is hidden in the form).

So form-level form_alters are only needed for cross-field alters, which mitigates the issue described here ?

Yes, I'm worried about this as well/don't really see why we need it.

Fun example: Let's say you have an entity reference to nodes and you have one million nodes. The default widget for entity reference is a select AFAIK. So if you hide it, it would render it like that, load 1million nodes (or try to), put them in a select, and then not show it.

Right, that is a great idea :p

The default widget for entity reference is a select AFAIK.

Someone must have lied to you, it's entity_reference_autocomplete :)

So form-level form_alters are only needed for cross-field alters, which mitigates the issue described here ?

I still don't really get what's issue described here by that one sentence from the IS...

Well, problem is that the $form array will look different based on the used widget and widget settings anyway, so we cannot remove the burden of the form alter to respect possibly different form structures per form mode and/or its display configuration. It's not only about being there / not there :/