Don't try to get prepopualted IDs if already retrieved values from cache

Seems to be a duplicate of #1502972: Issues with ajax file upload fields and #1958800: AJAX causes entityreference_prepopulate_get_values_from_url to fail

I'm seeing this too on latest dev of og and prepopulate.

I add a group content type, with audience field set to prepopulate from URL.

I add a filefield to the content type.

When I add a file by AJAX (clicking Upload), then click Save the prepopulate value is lost from audience field.

I have a different use case, where media module caused a fail in an OpenScholar installation. This patch fixes it.

Amitai, the patch doesn't solve the issue. When we're trying to use file/ajax, the group is still being unset by the ajax call.

@MPetrovic, thanks -- I'll re-check

I've experienced the same problem and sshivell's solution (commenting out the return) worked for me.

My use case:

I'm using entityreference_prepopulate to populate the og_group_ref from the current OG context (I am not using the URL's for any prepopulation). I have a field collection with unlimited values, so I get the "Add another item" AJAX loader that loads more and more of these field collections.

As above, if I use that form to load more items with AJAX then my og_group_ref gets unset after a save.

As above, commenting out the ajax check and return at the beginning of the function works for me, because my use case doesn't care about the URL at all.

With that said, I'm sure that check is there for SOME reason... so I'm wondering if really that conditional just needs to be more complex/specific (i.e. if form_attached AJAX && user is prepopulating from URL)... but I'm not sure about what that use-case is, but I do know it wouldn't be for mine. Hope this helps.

Ok, seems we don't need this line. Lets see if testbot likes it.

... correct status

You're sure that the original case that line meant to address no longer exists?

Hi folks,

Can you confirm patch in #9 is working for you.

It does work for me, yes, but again I'm not prepopulating from URL's at all, so I'm probably not a good use case.

> You're sure that the original case that line meant to address no longer exists?

I hope so ;) Couldn't find the reason why it was added in the first place. So committed.

Hi!
I tested this patch with entityreference_prepopulate 7.x-1.5 with following setup:

• Using only URL as provider
• Using redirect as fallback plan

When I applied this patch, my file upload AJAX response is my homepage. I looked closer into network traffic and I got the 302 redirect response for it.

I think this issue is in Drupal's AJAX API rather than just in entityreference_prepopulate module.

I've faced this issue before in other modules and the main issue is that Drupal AJAX system doesn't "inherit" query parameters to AJAX requests. It's also very likely that's by design, but sometimes gives extra headaches for contributors when implementing functionality which relies on $_GET parameters.

It would be ideal to set this from Form API. I haven't put time to figure out an right solution from AJAX point of view but I came with workaround for this by just disabling AJAX functionality.

Add extra process callback for your field because it's processed after hook_form_alter invoke:

/**
 * Implements hook_field_widget_form_alter().
 */
function mymodule_field_widget_form_alter(&$element, &$form_state, $context) {
  $field_name = 'field_your_field_with_ajax_upload';
  $entity_type = 'node';
  $bundle = 'your_og_content_type_perhaps';
  if ($context['field']['field_name'] == $field_name &&
      $context['instance']['entity_type'] == $entity_type &&
      $context['instance']['bundle'] == $bundle) {
    $element[0]['#process'][] = 'mymodule_unajax_file_field_widget_process';
  }
}

Then define your callback which unajax the elements:

/**
 * Field process callback for unajaxifying.
 */
function mymodule_unajax_file_field_widget_process($element, &$form_state, $form) {
  // Remove AJAX from "Upload" and "Remove" button
  unset($element['upload_button']['#ajax']);
  unset($element['remove_button']['#ajax']);
  return $element;
}

I've reverted the commit, and added a comment to make clear why the early return is needed.

Seems the issue isn't with OG core (or at least I wasn't able to reproduce), but is happening with other modules. Has someone found the real cause?

Anyway, I'm working on it.

Update: I believe I was able to reproduce this on a clean installation with a simple Entity reference field, and a "Countries" field, that has some Ajax.

Patch makes sure we don't try to get prepopualted IDs if already retrieved values from cache.

Committed.

amitaibu, the patch on #20 worked for me!
Thanks!