By design, in subsequent ajax calls we do not have the context of the original request.
This currently is solved for the case that fields are attached and populated in the original requests (as soon as #1958800: AJAX causes entityreference_prepopulate_get_values_from_url to fail is committed).

There are use cases when this is still broken by design: Think of e.g. a form with ajax file upload, where bundle is determined and fields can be polulated only *after* file upload in the ajax call.

Proposed resolution

Prepolulate plugins should
* in the original call gather the information they need and store in $form_state.
* in a later ajax call they can retrieve it there and use it

An example implementation can be found in #2400979: Ajax breaks prepopulation.

Remaining tasks

User interface changes

API changes

Original report by @jemisond

Setup: I have a node type that is content related to an organic group. One of the fields is the og_group_ref and another Entity Reference field (Topic) is for a View of taxonomy terms related to that group. Topic is a required field, entity reference prepopulate, Action=Hide field (but not applied to edit), Fallback=do nothing. Another field is an Image type, with multiple values allowed.

Issue: When editing the node, changing any of the fields except for the Image field has no issue- the node saves fine. But if I remove one of the images or try to upload a new one, the node will not save- I get "Topic filed is required" error and the select list for the Topic field is now empty. Or sometimes I get "An illegal choice has been detected. Please contact the site administrator." error and the error details are "Illegal choice 30298 in Topic element." (Yet 30298 *IS* a valid choice- that is the taxonomy id of the option I selected.)


axel.rutz’s picture

Title: prepopulated entity reference lost when editing (AJAX issue?) » Prepolulation broken when fields are attached in ajax
Issue summary: View changes