Issues with ajax file upload fields

I'm using Entity Reference field with Prepopulate and Disable Field action in content with an Image field.
When an authorized user goes to the link to create a prepopulated form he sees the right value of Entity Reference in the Form. But if he uploads an image and saves, Entity Reference field is empty.
So, the issue is also for authorized users except user #1.
And for dev. version either.

There's already code to make sure we don't try to capture values while in ajax, in entityreference_prepopulate_field_attach_form():

  if (!empty($form_state['triggering_element']['#ajax'])) {
    // We are inside AJAX, so values can't be taken from URL at the
    // moment.
    return;
  }

It seems to work for me on my use case, so I'll need more info / patch

So, is it done intentionally that Entity Reference Field is emptied if ajax is used?
Sorry, I'm not a coder and can't help with patches.
Just one more notice: if I use "do nothing" action setting, Entity Reference Field can survive file upload.
File upload empties Entity Reference Field when "hide field" or "disable field" action is set for this field.

Confirmed that I have the same issue. Any ideas so far?

Thanks guys!

If there is anyway we can resolve this issue, I would appreciate it. If funding is needed, please let me know.

Any progress on this? I would appreciate some help and am willing to pay for a patch to get this working.

Thank you!

I'm also experiencing this issue. I'll see what I can do in the way of patches or simple test cases.

So it appears that entityreference_prepopulate_field_default_value() was being called during the ajax submission step, but not called again on the "real" form submission. The empty value from the AJAX step was being cached, resulting in the field being empty on submission.

This patch sets $form_state['no_cache'] = TRUE in the AJAX step so that the form is rebuilt on submission. Patch is against 7.x-1.x.

Setting correct status, for testbot.

Testbot, wake up!

I've changed it to $form_state['rebuild'] = TRUE; and committed. Thanks.

I've installed the latest dev version and am still having the same issue.

Confirmed with version 7.x-1.1+4-dev

Tried clearing caches, cron, updates, etc. without luck.

@gthing , Please re-test using latest dev from GIT (as Drupal might not have packaged the fix in the new dev yet)

Grabbed the latest snapshot and updated. Same issue still there.

Amitaibu, I'm unable to test today but $form_state['rebuild'] = TRUE may not work -- see the form_set_cache() call here:
http://api.drupal.org/api/drupal/includes%21form.inc/function/drupal_reb...

I see. Committed #8, thanks.

Confirmed working. Thanks!

I am now having a new issue. I am fairly certain this cropped up with the fix above, and disabling the entity reference prepopulate module makes the problem go away.

I have a field that allows multiple file uploads. The first file upload works fine, while the second file upload causes the form to save, then breaks the upload form from allowing further uploads. Saving the node at that point will cause a duplicate entry error.

Screenshots:
First upload works as normal: http://i.imgur.com/x9wZh.png
Second upload causes form save (message in fileupload form, not at top): http://i.imgur.com/zgOyL.png

I have duplicated this issue on two sites.

p.s. Should this be a new issue?

Howdy, I've been able to duplicate this issue on my installation. I'll let you know if I figure out a solution.

Ok, thanks for the report -- I've reverted the fix until we find a proper one.

But don't be discouraged by that @ezheidtmann :)

Shoot. Are there any workarounds for getting this functionality? Other modules? I'm in a bit of a bind here.

I will put $40 down for a solution by the end of the week. I know it's not much but as I said, I'm in a bind.

I was able to get this to work using the latest version (1.1). It seems that the "do nothing" setting on the field is now working properly and the entity referenced is populated properly (in my case it is an Organic Group).

Hope this helps.

I will offer $100 via paypal to whoever can fix this by Nov 5th. $25 if you can describe a reasonable workaround.

AJAX file upload needs cached form state in order to work - see ajax_get_form(); what #8 achieves is that it simply pulls data cached earlier during the initial build.
(If you move $form_state['no_cache'] = TRUE line outside of if statement, file upload will stop working altogether as there will be no cached data for this form_build_id at all.)

As for the original issue, I was unable to reproduce it on a clean install, using entityreference_prepopulate 7.x-1.1 and core Image field; hence, there probably are missing pieces in this puzzle. Someone who has had this issue might want to try reproducing it on a clean install and then adding modules one-by-one until you get it.

Using 7.x-1.1 with an up-to-date Drupal instance, I couldn't replicate the original issue nor the issue raised in #19. I tried using file and image fields with multiple values permitted.

I did encounter another issue though. If the form has an error during submit, the entity reference field goes blank. If I disable entityreference_prepopulate, the entity reference is retained when the form is submitted with errors.

I've done some more testing and it looks like the original issue show up only if you set the pre-populate field to "hide." Setting it to "do nothing" makes it work as expected. Rolling back to 7.x-1.1 fixed the issue raised in #19.

In my case I would like to hide the field, but I supposed I could do that in CSS.

If anyone can reproduce the bug with that tidbit I'll still offer the bounty because it would be cool to have this bug fixed.

Unable to reproduce the original issue with 'hide' either. (tried with 'disable' earlier)

Are you using core Image only, or is there something else in play (multiupload modules etc.)?
What other fields are there on this content type?
What other modules could be interfering?

It seems the original issue might depend on some common module (as several more people are having it), but we still do not know what the trigger is.

Hi Drave Robber,

I was able to reproduce the original issue with just ctools, entity, entityreference, and entityreference_prepopulate in addition to core. To the default "article" content type, I added a file attachment field and an entityreference field with entity type set to "node". I will try to reproduce with the latest HEAD if I have time today.

I finally reproduced the initial issue.

There is one more condition: the entity field must be required. If it's not required, it saves all fine and dandy. Weird.

@Drave Robber: Thanks a lot! Finally able to reproduce...

Please find attached a patch fixing this issue. (Patch against 7.x-1.1, as I understood 7.x-dev introduced another bug, cf @gthing)

The issue was that on form rebuild on AJAX, #access was set back to true (while it was set to false on this bug use case (field hidden)), and my guess is that subsequentely it asks again for the default value, and the $_GET arg being not here, we end up with an empty value.
I must admit I don't have the full logical explanation on why it works now, I just did that in an hurry last half hour ;)
It also keeps on working in the field-not-required scenario.

Enjoy!

Tested. Still having the original issue with field required and set to hide.

A patch is attached. It works under all three "Action" options on my development server.

As I see it, the issue is that when the form was being rebuilt via AJAX, entityreference_prepopulate_get_values_from_url did not have the initial $_GET parameters available to populate the reference fields so they were empty. When the form was ultimately saved, the original values were not accepted because either #access = FALSE or #disabled = TRUE for those fields.

What I did to fix this is store the relevant $_GET parameters in persistent storage when the form is first loaded. Each time the form is rebuilt via AJAX, the original parameters are now available. This was fairly tricky, since a unique identifier wasn't available in the form builder or the entityreference_prepopulate_get_values_from_url function. I had to create an after-build function, and then populate persistent storage (I chose sessions, but you could just as easily use the db) there.

Feedback is most welcome... I'm tired and may see issues with this tomorrow, but I wanted to get in under gthing's deadline :P.

@MEsch ,
Thanks for working on this.

(I chose sessions, but you could just as easily use the db) there.

I think it's best to use the $form_state itself in the after build, and then in entityreference_prepopulate_get_values_from_url() call ajax_get_form() if we are inside an AJAX request.

Minor: you have trailing spaces (use Dreditor to see them).

Does not fix for you? It does for me ;)
So that could be that you are in a sub-usecase of this bug..

Oh well. If @MEsch solution works, that's great.

@MEsch, thanks for writing that. I'm going to re-write to use form_state and test. Stay tuned!

@MEsch, your patch has whitespace errors and does not apply. I'm applying your changes manually, but please do take care to avoid this in the future. see: http://drupal.org/node/707484

Does #35 this patch 1.1 or should I apply it to the previously patched module?

gthing: I believe it applies to 1.1, but I've only tried against 7.x-1.x, where it fails.

I couldn't get it to apply to 1.1, 7x-dev, or the previously patched module.

Patched again, patch deploys on my development server. Patch applies to 7.x-1.1.

@MEsch

Tested against 1.1 and found it working in all of the above use cases. Huzzah!

PM me your paypal address

this isn't the cleanest solution but this works for me. thanks, MEsch.

#43 works for me!

#43 works fine on 7.x-1.1 version and with a required ER field. Thanks

This one uses chached form. Applies to 7.x-1.1.

Looks like there are two approaches being worked on in parallel here. Both patches need work, though. The one in #49 doesn't apply to 7.x-dev and seems to require that $langcode be passed to the edited function, and the patch in #43 has coding style issues.

I'm not sure which approach is conceptually better, though.

Looks like another issue of both patches is that they don't cater for Ajax requests using GET, see: http://api.drupal.org/api/drupal/developer!topics!forms_api_reference.ht...

Anyway, here's a patch in the style of #43, as I think it makes more sense to use the form cache. It fixes the problem with translatable fields, which required adding an extra parameter to 2 functions to be able to pass $langcode. It may be possible without that, because the entity object also contains the language. Not sure what is preferable.

I'm not sure why the patch in #43 mentions that a field may not be in the root of the $form array. I tested using the field_group module, and it just works. But please do review.

+++ b/entityreference_prepopulate.module
@@ -197,18 +191,20 @@ function entityreference_prepopulate_field_access($op, $field, $entity_type, $en
+function entityreference_prepopulate_get_values($field, $instance, $langcode = 'und', $flat_array = FALSE) {

Why do you set a default vale for langcode? Anyway it should be LANGUAGE_NONE, not 'und'

+++ b/entityreference_prepopulate.module
@@ -251,6 +249,17 @@ function entityreference_prepopulate_get_values_from_url($field, $instance, $fla
+  // When in an AJAX request, get the field values from the form cache

Missing dot in end of line. Also would be nice to have more comments about what the problem is and why we chose to solve it like this.

+++ b/entityreference_prepopulate.module
@@ -251,6 +249,17 @@ function entityreference_prepopulate_get_values_from_url($field, $instance, $fla
+    $default_value = $form[$field_name][$langcode][0]['target_id']['#default_value'];

better surround this with an !empty() to prevent notices. It seems pretty fragile. At this state won't we get the default value in the $form_state?

Setting correct status.

I'll be working on this.

This patch also works for OG, using a recursive function to extract all the #default_values from the cached form.

Please let me know if it works for you.

I haven't tested the patch yet, I will do so when I get back to work on monday, but here is a preliminary review.

+++ b/entityreference_prepopulate.module
@@ -251,15 +249,27 @@ function entityreference_prepopulate_get_values_from_url($field, $instance, $fla
+  if (isset($_POST) && !empty($_POST['form_build_id'])) {

I see you copied an error I made, the superglobal $_POST is always set, so this test is redundant.
Also, the patches have so far haven't addressed AJAX requests using GET, as rare as that might be. IMO it should be, otherwise this issue might come up again in the future.

+++ b/entityreference_prepopulate.module
@@ -355,3 +365,32 @@ function entityreference_prepopulate_create_node_links($entity_type, $entity_id,
+function entityreference_prepopulate_extract_default_values($element, &$target_ids = array()) {
+  // Check if we reached the element that is the actual reference to the target
+  // ID.
+  if (isset($element['#default_value']) && !empty($element['#field_name']) && og_is_group_audience_field($element['#field_name'])) {
+    if (empty($element['#default_value'])) {
+      return;
+    }
+    $target_ids = array_merge($target_ids, is_array($element['#default_value']) ? $element['#default_value'] : array($element['#default_value']));
+    return;
+  }
+
+  foreach (array_keys($element) as $key) {
+    if (element_child($key)) {
+      entityreference_prepopulate_extract_default_values($element[$key], $target_ids);
+    }
+  }
+
+  return $target_ids;

If you are passing the $target_ids array by reference, why are you returning it?

@a.ross, Thanks for the good review. I've attached also the interdiff.

> Also, the patches have so far haven't addressed AJAX requests using GET, as rare as that might be.

That's indeed sounds pretty rare -- I know Views for example changes $form['#method'] = 'get' on it's exposed filters, but that's not the case when submitting a new entity. Anyway, I think it's ok if it will be a follow-up patch if needed.

Hi,

I'm new to this issue and apologies if this patch duplicates work already done, but sometimes it's good to have a fresh set of eyes on things.

My approach was to use the $form_state cache to hold URL pre-populated values and then re-read them from there in the situations where they cannot be read from the URL, such as requests to /ajax.

I am wondering if part of the problem is coming from using '#access' when disabling the form elements. I wonder if there is anything better we could do here?

Alright, back to work and tested the patch first thing. Patch is not working yet for me, I'm not using OG. A few comments:

+++ b/entityreference_prepopulate.module
@@ -197,18 +191,20 @@ function entityreference_prepopulate_field_access($op, $field, $entity_type, $en
+function entityreference_prepopulate_get_values($field, $instance, $langcode = 'und', $flat_array = FALSE) {

LANGUAGE_NONE ;)

+++ b/entityreference_prepopulate.module
@@ -251,15 +249,27 @@ function entityreference_prepopulate_get_values_from_url($field, $instance, $fla
+  if (!empty($_POST['form_build_id']) && empty($_GET[$field_name])) {

Unless you set stuff in the $_GET array yourself, there's no need to test for it here. Testing $_POST should be sufficient. You're also testing $_GET[$field_name] below.

+++ b/entityreference_prepopulate.module
@@ -355,3 +365,32 @@ function entityreference_prepopulate_create_node_links($entity_type, $entity_id,
+  if (isset($element['#default_value']) && !empty($element['#field_name']) && og_is_group_audience_field($element['#field_name'])) {

This only works when using OG (which I'm not using). But something else is wrong. When I add module_exists('og') I get this error: "Field [field_name] must be populated via URL."

Haven't tested, but from review:

+++ entityreference_prepopulate.module	(working copy)
@@ -128,7 +128,16 @@
+        $form_state['entityreference_prepopulate'][$instance['entity_type']][$instance['bundle']][$field['field_name']] = $values;

I like this approach :)

+++ entityreference_prepopulate.module	(working copy)
@@ -249,6 +258,24 @@
+      if ($flat_array) {
+        throw new Exception('I guess we needed to check for this after all');

Remove

+++ entityreference_prepopulate.module	(working copy)
@@ -249,6 +258,24 @@
+      $cache[$identifier] = $form_state['entityreference_prepopulate'][$instance['entity_type']][$instance['bundle']][$field_name];

Don't return here, just assign it to $ids -- to let it be processed along the function

Also make sure ti create a diff that can be applied (git diff)

@a.ross see #61 and #64

Working on it

Are you sure that the cache should be passed on to the rest of the function? I think it already went through there when the $ids were first cached in the $form_state, does it have to be done again?

Patch works for me, here's a git diff with some slight modifications.

> Are you sure that the cache should be passed on to the rest of the function?

Yes, as we want it to reach entity_access() and $items[] = !$flat_array ? array('target_id' => $id) : $id;

Alright, I get it. Here's a patch that fixes that issue. I had to restructure the if clauses a bit, I think I got it right, but please do review.

I was getting this problem with a custom AJAX behaviour on a form element.

Confirming that the patches fixes the problem for me.

+++ b/entityreference_prepopulate.module
@@ -249,17 +256,24 @@ function entityreference_prepopulate_get_values_from_url($field, $instance, $fla
+  $form_build_id = isset($_GET['form_build_id']) ? $_GET['form_build_id'] : isset($_POST['form_build_id']) ? $_POST['form_build_id'] : NULL;
+  if (!empty($form_build_id)) {
+    $form_state = array();
+    $form = form_get_cache($form_build_id, $form_state);

One thing though -- do we really need to get the form back out of cache?

I have some custom prepopulation code for another part of the same form, which is also affected by this problem, and what seems to be working is putting it in the $form_state when I can find it in the URL, and then just retrieving it from that next time around.

That patch does store the values in $form_state, but that variable isn't passed to the function where the values are retrieved. We could fix that, however.

I'm currently hiding the file upload button so that files don't get Ajax-uploaded. Works as a temp fix but would appreciate a patched release.

A temp fix is not to hide or disable the field in the field configuration (i.e. action = do nothing) and do it in a hook_form_alter as follows:

<?php
  if (strpos($form_id, '_node_form') && isset($form['field_myfield'])) {
    $lang = $form['field_vam_project']['#language'];
   // Hide the field value.
    $form['field_myfield'][$lang]['#attributes']['style'] = 'display: none;';
   // Hide the field title.
    $form['field_myfield'][$lang]['#title'] = '';
   // If required get read of the required indicator (only safe to do if your fallback protects you)  
    $form['field_myfield']['und']['#required'] = FALSE;
  }
?>

I am using a modified version of the above where the value is copied to the title before it disabled.

Thanks to all involved for looking at a proper solution and hope this gets resolved soon.

@Amitaibu, do you think this is this ready to go in?

Committed, thanks all!

I getting error with the latest DEV could it be related to this patch ?

    Notice: Undefined variable: ids in entityreference_prepopulate_get_values_from_url() (line 280 of /home/sw3b/www/ng/sites/all/modules/entityreference_prepopulate/entityreference_prepopulate.module).
    Recoverable fatal error: Argument 1 passed to EntityReference_SelectionHandler_Views::validateReferencableEntities() must be an array, null given, called in /home/sw3b/www/ng/sites/all/modules/entityreference_prepopulate/entityreference_prepopulate.module on line 280 and defined in EntityReference_SelectionHandler_Views->validateReferencableEntities() (line 134 of /home/sw3b/www/ng/sites/all/modules/entityreference/plugins/selection/EntityReference_SelectionHandler_Views.class.php).

Please open a new issue for that unless you're sure it was caused by the patch in this one.

I can confirm the error reported in 78 above is caused by this patch. I received it today after patching. See below:

Notice: Undefined variable: ids in entityreference_prepopulate_get_values_from_url() (line 280 of /var/www/ubind7/sites/all/modules/entityreference_prepopulate/entityreference_prepopulate.module).
Recoverable fatal error: Argument 1 passed to EntityReference_SelectionHandler_Generic::validateReferencableEntities() must be an array, null given, called in /var/www/ubind7/sites/all/modules/entityreference_prepopulate/entityreference_prepopulate.module on line 280 and defined in EntityReference_SelectionHandler_Generic->validateReferencableEntities() (line 193 of /var/www/ubind7/sites/all/modules/entityreference/plugins/selection/EntityReference_SelectionHandler_Generic.class.php)

The odd thing about this error is I only receive it on one of my content types. Any ideas?

Also getting this error when trying to create an og group node that where the group audience field is prepopulated via the url, and the field is set to be hidden. 1.2 does not have this problem.

@a.ross, can you check that please? :)

It appears to me that the error is occurring on content that doesn't have an ajax load now. All content types with a load are working.

Hm, that's funny. In my testing environment, it works for regular users, but it doesn't work for admin users. The difference between the two is that the field isn't actually hidden from the admin user. I guess in that instance, the values can just be taken from the form submit and don't need to be taken from the form cache. Something must be happening in this case that prevents the values from being stored in the $form_state in the first place. Amitaibu, do you have a suggestion?

A bit unrelated, but I found another potential issue, which is that in this construct:

  // Check if the IDs are valid, and get filter out the ones that are not valid.
  $handler = entityreference_get_selection_handler($field, $instance);
  if (!$ids = $handler->validateReferencableEntities($ids)) {
    return;
  }

... you would want to do this before returning (or at least that was what happened before the patch):

$cache[$identifier] = FALSE;

The patch that follows is just a workaround, not necessarily a real fix. It does prevent the error in my case.

Work for me thanks a lot !!!

the only thing i notice is for user who has not admin permision it loop back again on my side

On my end, it works for both regular and admin users. Can you describe the problem in more detail?

It does a loop has describe at the top of the issue and a message appear saying that no item has been selected and i must select on value to continue.

Do you mean the error message you posted in #78?

#75 is not mine but the error i was getting in #78 and with the DEV is solve by your patch for my admin.

On another side the users who only have permission to creates nodes have the same problem describe before the latest dev version. it does a loop. After that if i select the reference manually it work. But when it is prepopulate it does not work.

Sounds like the value isn't stored in the form_state. Are you using OG?

Not for that node creation. On another section of the site yes but not for that.

Ok, what are the settings of that entityreference field? I need to be able to reproduce the problem in order to fix it.

Field title: Gallery
Fiel name: field_gallery_entityreference
Entity Reference
Select list

The Entity reference prepopulate checkbox is mark and the field is on disable. Apply action is not mark. Fall back is to do nothing and the permission for the skip access is set to Administer content. Og context none.

I also have a view to generate the list of entity and restrict to the entity the user and only the user have access. If you want acces to my dev site just let me know in private message. maybe it could be easy that way for you.

In general i'm using Upload Nodes (sandbox) to upload multiple images into a gallery. Without prepopulate module everything work great. Just let me know if you want a copy of the module or have another question or test to do.

Is the patch in 85 a fix for the error we've been discussing or is that a work around for the new potential issue you found?

Thanks for the quick work.

The patch in 85 gets things working for me with an OG group audience field set to prepopulate from the URL, on a content type that does *not* have any kind of ajax field.

I've changed it a bit, so we don't call the selection handler if there are no IDs.
Committed, thanks.

@Sw3b I can't reproduce the problem you're having with those settings. It would seem likely that there is a conflict with the other module you mentioned. And since it's a sandbox project I don't think we can do a lot about that issue.

@tjhart, the patch included both.

Latest commit causing errors:
#1916496: IDS problem with latest dev version

@Amitaibu, the reason I used empty() instead of an implicit cast to boolean, is that the cast will cause a notice when the variable is undefined, which was what was happening here. This should do it:

Committed, thanks.

Please don't bump the priority -_-

Oops, sorry crosspost

#102: entityreference_prepopulate_ajax_submission-1502972-102.patch queued for re-testing.

Patch failed earlier testing ... is 102 the committed patch?

Well of course it will fail, since it's already committed.

haha thanks smarty. Wasn't paying attention.

Also didn't see the status change ... It's been one of those mornings.

What a morning without coffee? :)

I can use some coffee .. ok i'm still having a problem. With the ajax load it works but for the other content it is still failing to load from URL. I receive this message: Field Groups audience must be populated via URL.

Any ideas?

Alright, I have been able to reproduce the problem. What happens here is that when the form is submitted, a POST request is sent, containing the form_build_id. The prepopulate values are available in the $_GET superglobal as usual, though, so no need to get it from the form_state. In fact, when we try to get the form out of cache in this case, it's empty! So that's where the problem arises. Attached is a proper fix. I also added a bit of documentation to make it clear what the various if/else constructs mean. I also took the liberty to correct an unclear sentence (the last line in the diff), sorry about that.

Applied against latest dev

Gah, something went wrong there. Try again.

I have checked #119 patch.

After submitting entity with entityreference_prepopulate field I am getting next message: Field Plan Document must be populated via URL. PHP notice gone.

On create page field works great. I mean disable or hide actions work.

Sorry, #120 is wrong comment. After applying #119 there is no errors after submitting node.

Alright, good news! Thanks for testing

@a.ross Thanks for turning this around for us! We will report back as soon as we've applied the patch.

TJH

We are having issues applying the patch to the 7x 1.2 branch. Will this patch work there or is it specifically for dev?

Which patch order should we attempt to the base 1.2 version to correctly patch the error?

We finally were able to apply the patch manually. Since we hadn't followed the sequence of previous patches it was getting rejected. Test look good so far. Thanks a.ross

@tjhart, glad it's working for you, but the patch should apply to the latest -dev really.

bump

Can this be committed? 3 people have tested the patch, including me, and there haven't been any problems yet. Thanks

Committed, thanks.

a.ross, can you ping me on IRC, I'd like to ask you something.

Hi,
the patch works great. But it's missing the code to make it work when "og context" option is active.
I have a file/image upload form in a group panel page, so I use og_context to prepopulate.
I've created a small patch, I'll upload it to review (probably needs refactoring).

a.ross, this one is yours... :)

I can't really dive into this because I've got a deadline to meet and we're not using OG, so it'd cost me a bit more time than usual. But the patch looks ok at first sight.

I have the same problem:

• When I submit a node with a pre-populated og_group_ref field, it works fine.
• When I have an image/file field in the node and I just select the image and save the node, it works.
• When I have an image/file field in the node and I select the image, upload it and save the node, it doesn't work.

I updated to the latest dev version and applied the patch from #130. But it doesn't fix the problem.

I do some debugging and found the problem in the following function:

function entityreference_prepopulate_og_field_default_value($entity_type, $entity, $field, $instance, $langcode) {
  if (empty($instance['field_mode'])) {
    return array();
  }
  if ($items = entityreference_prepopulate_get_values($field, $instance)) {
    // Filter out the items that don't match the field-mode.
    $gids = array();
  ...

When i remove the part with the check if (empty($instance['field_mode'])) it works:

function entityreference_prepopulate_og_field_default_value($entity_type, $entity, $field, $instance, $langcode) {
  // if (empty($instance['field_mode'])) {
  //  return array();
  // }
  if ($items = entityreference_prepopulate_get_values($field, $instance)) {
    // Filter out the items that don't match the field-mode.
    $gids = array();
  ...

When I upload the image in the node, the function is called with a field_mode default, when i save the node after upload, the function entityreference_prepopulate_og_field_default_value() is called again but field_mode is not set.

I hope this information helps to fix the problem.

Same problem here, latest dev and patch 130 do not fix the issue

Same as tatyana — latest dev and patch from #130 did not solve the problem. If I comment out the lines referenced in #134 (which obviously the commenter is not suggesting as a solution, but I thought I'd try it to see what happens), the entityreference field does retain the group reference.

However, I'm using Auto Nodetitle to pull the group name into the content title, and with this configuration the group name does not get pulled through into the title, so I get the token instead (e.g., my title is "[node:field-organization] 2012-13 Project Application"). If I don't upload a file, then the auto nodetitle works fine.

I've done some module cleanup in #1958800: AJAX causes entityreference_prepopulate_get_values_from_url to fail, which should also fix the OG problem, so if people can test that patch it would be great.
Marking this issue as duplicate

Attempting to solve this thing over in #1958800: AJAX causes entityreference_prepopulate_get_values_from_url to fail.

$form_state['no_cache'] = FALSE;