reference option limit does not work with file field widgets on same node

> After adding a file field to this content type and then uploading an attachment

Do you mean that the edit form gets refreshed? I've seen similar problems with forms updating via AJAX.

I have the following errors when file is uploaded.

Notice: Undefined index: field_centro en reference_option_limit_form_alter() (línea 309 de K:\xampp\htdocs\sitio\sites\all\modules\reference_option_limit\reference_option_limit.module).
Warning: Invalid argument supplied for foreach() en reference_option_limit_form_alter() (línea 309 de K:\xampp\htdocs\sitio\sites\all\modules\reference_option_limit\reference_option_limit.module).
Notice: Undefined index: field_centro en reference_option_limit_form_alter() (línea 351 de K:\xampp\htdocs\sitio\sites\all\modules\reference_option_limit\reference_option_limit.module).

and ilegal option when i try to save the entity.

any help??

It's probably because the form is getting refreshed and reloaded when you upload.

Just to clarify: how do you upload the file? Do you press the 'Upload' button or just browse it and then save the whole form?

I think the same as you, but i don't know how to fix it. yes, i press the upload button.
I have the errors above the field and not in the begin of the page.
Here are screenshots
thanks.

help please...

I think the same as you, but i don't know how to fix it. yes, i press the upload button.
I have the errors above the field and not in the begin of the page.
sorry if I repeat the post, but I really need solve this problem, I love this module and I need It
thanks a lot

Please don't keep posting the same comment.

Yes, there is a bug here.

Unfortunately, I suspect this is going to be a complex thing to fix. I don't require this functionality in any of my paid projects, and I don't have enough free time to fix it in my personal time.

If you really need this soon, you either need to fix this yourself, or hire a developer to do it for you.

I found a simple fix for the issue on my setup that was preventing file/image fields from submitting properly due to the form refresh.

I changed the following line from:

if (isset($form_state['values'])) {

to:

if (isset($form_state['values']) && isset($form_state['values'][$field_name_matching])) {

It's a very simple fix but seems to do the trick. Can anyone else test this?

joachim - once tested, can this be applied to an update of the module?

Could you post that change as a patch please?

After further testing I found that my suggestion only fixed the errors that appears while attaching a file/image but did not address the issue of losing the limited options that were already selected before submitting a file/image. It's not pretty but this solution seems to fix both of the issues now. It simply tried to determine if the form is a file/image form in this module's hook_form_alter and then bypasses the rest of the logic if it is.

I am not experienced in making patched, if this appears to be a viable solution then perhaps someone can make the patch...

To fix: insert the following code right after these lines:

EXISTING CODE

function reference_option_limit_form_alter(&$form, &$form_state, $form_id) {

  if (isset($form_state['reference_option_limit'])) {    
    //dsm($form, 'hfa form');
    //dsm($form_state, 'hfa fs');  

NEW CODE TO INSERT

   // Submitted form may be a file field form... let's check
   // if form is a file field form then bypass rest of function
   if (isset($form_state['values'])){
     reset($form_state['values']); // make sure array pointer is at first element 
     $firstKey = key($form_state['values']);          
     $field = field_info_field($firstKey);
     if ($field['type'] == 'image' || $field['type'] == 'file'){
        return;   
     }
   }    

END RESULT

function reference_option_limit_form_alter(&$form, &$form_state, $form_id) {

  if (isset($form_state['reference_option_limit'])) {    
    //dsm($form, 'hfa form');
    //dsm($form_state, 'hfa fs');  
   
   // Submited form may be a file field form... let's check
   // if form is a file field form then bypass rest of function
   if (isset($form_state['values'])){
     reset($form_state['values']); // make sure array pointer is at first element 
     $firstKey = key($form_state['values']);          
     $field = field_info_field($firstKey);
     if ($field['type'] == 'image' || $field['type'] == 'file'){
        return;   
     }
   } 

     reset($form_state['values']); // make sure array pointer is at first element
     $firstKey = key($form_state['values']);          

How do you know the first field in the form is the file field? It could be anything!

BTW, there is help with patches here: http://drupal.org/patch

Right. I've struggled with finding a way to determine if the submitted form is in fact a file/image field form. After working on it for half the day this is the best solution I could come up with. From my testing it does appear that a file/image form will contain a field type value in the first array. I know this isn't pretty and may not work in all setups but it is the only way I could find to make it work and it does fix both issues.

If someone can find a better way to check the $form_state['values'] to find if it's a file/image field then please advise.

First off, it's an entity form, always, because that's what our module works with.

I would dsm($form), and see what's in there. Possible lines of attack:

- IIRC some FieldAPI things have an array that is a list of all the fields
- alternatively get the entity type and bundle from the form, and use FieldAPI to get yourself of all fields on that instance

Next thing is that to do in that circumstance:

   // Submited form may be a file field form... let's check
   // if form is a file field form then bypass rest of function

What does bypassing the rest of the function accomplish?

What does bypassing the rest of the function accomplish?

I should clarify part of the symptom: the second part of the issue happens when a submitted form fails validation and there is a file/image field on the form. reference_option_limit_form_alter() is called more than once. Once for the regular form and then once for each file/image field. The hook_form_alter function is triggered for each of these forms because they each have the 'reference_option_limit' value on them. However, when the function runs on the file/image form it causes the option limited selection that had already been set to be lost (see second image on post #4 above).

By detecting if the form is a file/image field form then we can simply bypass the rest of the function preventing it from losing the previous selection.

I know this isn't graceful but it does seem to work. I've looked at the $form and $form_state objects extensively and haven't found a way to detect if it's a file/image field form yet. I will give it another crack in a couple of days though, as soon as I have time.

Ahh... thanks for the explanation.

Does $form look the same both times?

If $form is different, we maybe need to think about changing the way $form_state['reference_option_limit'] works. For instance, we could store the #parents of the element we want to act on, and therefore be sure to only act when it's there.

Update:

After looking into it further my current solution did not work properly. Besides not being a graceful solution I also discovered that although it did remove the errors and fixed the issue of losing the filtered option that was selected, after submitting a form with a file widget that failed validation it was losing the selective filtering and would then show all of the options available.

I was able to come up with another solution the involved storing the $form_state values in the reference_option_limit variable and only updating them if the $field_name key exists in the $form_state values. This allows easy and fool proof (as far as I can tell) detection of a file widget form.

Now the reference_option_limit_form_alter() function works on the values stored in the reference_option_limit ['values'] element instead of the actual $form_state['values'] element (because those values could be from the file widget) and everything seems to work perfect now.

I will try to get a patch up in the next couple of days.

> only updating them if the $field_name key exists in the $form_state values.

That sounds like a good approach.

I found the time to have a quick look at this. The problem stems from the fact that the file and image widgets quite correctly use #limit_validation_errors on their ajax buttons, but the form rebuild obviously means our form_alter gets called... and #limit_validation_errors, as I learned recently, directly affects which parts of the form input gets processed and put into $form_state['values'].

The upshot is that we should be more careful about our test to see if we're in the AJAX part of the flow, exactly as you suggested earlier on.

Here's your earlier suggested change as a patch.

> After further testing I found that my suggestion only fixed the errors that appears while attaching a file/image but did not address the issue of losing the limited options that were already selected before submitting a file/image.

I can't reproduce that second problem. Here are my steps:

- go to add a new node
- choose a country taxonomy term -> the cities appear limited
- choose a file and click 'upload' -> the file is uploaded. My country and city selection are fine.

To reproduce the second problem you must:

- go to add a new node
- choose a country taxonomy term -> the cities appear limited
- choose a file and click 'upload' -> the file is uploaded
-also make sure a required field is NOT filled in so that the submitted form will fail validation

Now the city limited field will either be completely empty or may have all impossible options (depending if fix was applied).

> -also make sure a required field is NOT filled in so that the submitted form will fail validation

Nope, it's working for me fine with that too -- I have both the node title and a text field required and blank.

Hmmmm. Sounds like you're doing the same thing as me to test but we're getting different results. To be sure, I just downloaded the module again and applied the patch but I still get the symptom.

See the attached screenshots. "Sub Type' is limited by "Main Type". If I select the main type and then select the sub type (limited field) and also upload an image then submit the form that fails validation I then lose the sub type field info.

To produce, I:

-Selected my main type field value
-Selected my sub type limited option value
-Selected and uploaded an image
-Submit form without filling in all required forms
-There are now no options for the sub type

Could you try to reproduce again? Your fix is obviously much simpler but it doesn't work for me. I have a more complicated fix but I'd like to verify that others are seeing the same symptom.

> -There are now no options for the sub type

Ah right. I misunderstood you; I thought the subtype values went missing when you uploaded, not on submit.

So we really have two problems, which are possibly related:

1. Error messages when you hit the upload button on a file or image widget (or indeed, I suspect, any other AJAX process on the form)
2. The values on the subtype go missing if there was a later AJAX process

Problem 2 is going to be caused by something to do with form_state['values'].

One thing I've found is that when you hit upload, only the file or image field's values are sent, because of the #limit_validation_errors on that widget. Which is normal, but we might not be taking that possibility into account.

> -There are now no options for the sub type

Yup, there's some sort of tandem effect going on here.

During the filefield AJAX, there were no form values for our fields, and so we didn't output options for the dependent field in the rebuilt form (you can't see this effect, because only the filefield part of the form is returned by the AJAX).

Then when we validate the whole form, we don't have the options for the dependent field. Hence our form value for the radio button/select in the dependent widget is lost.

In fact, I get:

> An illegal choice has been detected. Please contact the site administrator.

Do you get that too?

I think I've figured it out.

Can you try this patch please?

(See comments in the patch for an explanation of what's going on.)

Joachim,

I try to use your patch but I'm still receiving a message like:

Notice: Undefined index: storage em reference_option_limit_form_alter() (line 361 of /var/www/sites/all/modules/reference_option_limit/reference_option_limit.module).

In my environment I have a file field with unlimited files inside and for each time that I upload and/or remove a file, I receive this message.

Others messages are gone!

Best

Argh, there's possibly a case 4, when the 1st AJAX callback is the filefield. Is that how you're getting that error?

I really don't know what you mean. Can you explain a little bit more?

Thanks

If you upload files before using the ref option limit widgets.

Joachim,

The crazy stuff is: I don't have an option limit widget in this content type. Look the shot.

You have select lists. They work with this module too.

Oh yes,

I'm using the Field Permissions module to show for some roles just the file field to update (and upload) new documents. So, when a user with a specific role edit the node, he just see the file field (documentos). On the edit screen, when he upload a new file and/or remove a file, he see the notice message.

All of the others fields remain with data and can't be updated for this specific role.

> I'm using the Field Permissions module

Argh that's a whole new kettle of fish!

Could you test this patch without that please, and open a new bug report for Field Permissions?

:-)

Sure, I'm doing it tomorrow morning.

Hello,

I make some tests without the Field Permissions module and the problem still there.

When I select a file to upload in my content type and DON'T click at the upload button, the file is uploaded 100% and I don't receive any kind of message. But, if I try to upload more than one file (select a file, click at the upload button and try to upload another one) I receive the message Notice: Undefined index: storage in reference_option_limit_form_alter() (line 361 of /var/www/sites/all/modules/reference_option_limit/reference_option_limit.module) and another one (An illegal choice has been detected. Please contact the site administrator.) because the content type lost the reference from the field.

Cheers,

It's all working for me now, even with a multi-value filed field.

Could you post the *exact* steps for reproducing the problem, *with* the patch applied.

Hello

I think I discovered the problem (I didn't have much time enough to make more tests with this change), When first case is true, you don't have anything stored in $form_state, so when you make an AJAX request which is not from reference option limit (upload an image or remove it), case 3 will execute, and $form_state['reference_option_limit']['storage'] has never been set before. I fixed this putting this line at the end of the first case ("Case 1: First time round."):

    else {
      $match_values[$field_name_matching] = array();
    }
  }
  else {
    $match_values[$field_name_matching][] = $form[$field_name_matching][LANGUAGE_NONE]['#default_value'];
  }
//new line
  $form_state['reference_option_limit']['storage'][$field_name]['match_values'] = $match_values;

This new line removes error message and let you save any change you made with no "Illegal choice detected" message.

I'm new in Drupal, so I still need to learn how to make a patch, besides, I prefer first to test everything before submit any patch.

PD: Sorry if I my English is not good.

That fixed it, HakS!

I have tested this on different content types with multiple image fields and it works nicely.

For others reading this: the patch in #24 needs to be applied to 7.x-1.3 before adding the line HakS suggested.

joachim, please review this and let us know if you'll be pushing this into -dev.

Thank you all for your help.

I still can't reproduce the problem with the original patch. Could someone give me the clear steps to reproduce this please?

joachim,

Right now I don't have all resources to exactly reproduce this problem, however, I'll try to give you some clues.

All this happens before adding the line I suggested:

• When I add content, I try to upload an image of any field, but I get the error message "Notice: Undefined index: storage in reference_option_limit_form_alter()", however, I can save new content without ilegal messages (even using the reference option limit fields)
• But when I want to edit content, when I remove image (error messasge displays) and try to save edited content, illegal operation error message displays
• I am using a Country -> City case, being Country field a required field

If you still cannot reproduce it even with these clues, I suggest to show us what do you have stored in $form_state['reference_option_limit']['storage'][$field_name]['match_values'] when 1st case runs.

Looks like #2006798: Errors in the form with other ajax elements has this covered.

I'm tentatively going to close this.