entity_ref field type performs ajax rebuilds in its "instance settings (sub)form".

In order to do so, ConfigurableEntityReferenceItem::instanceSettingsForm() currently needs to fetch $form_state['instance'] instead of using the usual APIs for the method ($this->getFieldSetting(), $this->getFieldDefinition()), because in current HEAD, those are "the official state of the $instance as it exists in the config store", not "the $instance being edited / rebuilt".

That is because Field UI's FieldEditForm and FieldIstanceEditForm build a FieldItem object in order to call its settingsForm() / instanceSettingsForm() method, but this FieldItem object is based on the $field / $instance from config.

Instead, this FieldItem should be built on the $form_state['instance'] being iteratively built.

Comments

yched’s picture

Assigned: Unassigned » yched

Patch coming, hitting a few roadblocks :-)

swentel’s picture

Issue tags: +Field API

Tagging, marked #2084371: Settings form does not work when moving from hidden to content as a dupe of this.

- edit - amateescu reopened it, just to be sure

yched’s picture

Hm, the causes might be similar, but those are different code areas in separare forms, so I'd like to keep this one focused on the "field / instance settings forms". +1 on keeping two separate issues ;-)

amateescu’s picture

Issue summary: View changes

I just went over those roadblocks after writing a patch to convert the field_config edit form to an entity form. I think I managed to overcome them properly in #2448357: Config entity forms need to have access to an updated entity object at all times.

amateescu’s picture

BTW, the two issues to convert "field storage" edit and "field edit" forms to be entity forms are here:

#2446869: Convert the "Field storage edit" form to an actual entity form
#2448503: Convert the "Field edit" form to an actual entity form

amateescu’s picture

yched’s picture

awesome