Fix JS settings errors related to forms using arrays to contain their primary elements

I am too getting this error. The issue seems to be that profile2 uses different names for their fields. Instead of having "FIELD_NAME[und][0][value]" like we expect, it is "PROFILE_TYPE[FIELD_NAME][und][0][value]"... example: "profile_main[field_profile_picture][und][0][value]"

why? I am not sure. That is just the way it is...

This will cause an error with the code, because it doesnt know what the value should be.

The problem is actually not unique to profile2, it just happened to manifest there. Any form that uses an array to contain its primary elements will have this problem because the name attribute will contain whatever the array key is. To avoid this I've replaced the regular expression in imagefield_focus.js with a data attribute check and added the data attribute to the appropriate inputs with the field name.

Patch attached.

Updating category because this is actually a bug with imagefield focus.

An issue should only be marked as fixed when the fix has been applied to the project repository. Otherwise, there's pretty much no chance the fix will be included in the next update.

This problem also manifest itself for example when using Inline Entity Form, and presumably also when using Field Collection.

The fix should work if you don't have the same field in the different entities displayed in the same form ; if you have a generic attached both to the base entity and the subentity (let's say a field named field_image, present both on a 'product' node type and a commerce product, with Inline Entity Form displaying both at the same time)

The issues in the queue related to this are all very confusing since they all try to "integrate with X module" whereas the real issue is related to implementation of the drupal_add_js() settings and passing the field identifier to the JS to call the needed settings.

Modules I have seen affected by this issue, from reading issue queue, are:

• Profile2
• Inline entity form
• Field Collections
• There could certainly be more

The fix I propose does the following:

• Use data attributes on the form input element to pass the field's identifier to the JS (from elliottf's patch in #2).
• Replace ugly regular expression in JS with call to the field's data attribute to get the field identifier (from elliottf's patch in #2).
• Change drupal_add_js() for the Drupal.settings data to key the fields on their input id rather than the field name, since some fields may be reused in multiple entity types and show multiple times per page, like in field collections or inline entity forms
• The data attribute assigned on the input fields also reflects the usage of ID rather than field name.
• Do a quick test to see if the JS variable settings is defined before running the operations referencing the object. This avoids JS errors if something went wrong and gracefully degrades to simply using no focus or crop width/height/lock ratio settings.

This should make the widget much more flexible and adaptable to being embedded into a page multiple times. It has worked for me with Inline Entity Form and two entity reference fields two levels deep.

The patch in #6 fixed the issue for me.
I have ImageField Focus 7.x-1.0 + Field Collection.

Thank you nicholas.alipaz

#6 solved the problem for me, saving my day in the process. Thank you!
I'm using IFF 7.x-1.0 + Inline Entity Form in Drupal Commerce.

I can confirm as well that #6 fixes the issue in both Field Collections and Inline Entity Form.

Thanks for all the reviews, now if only we can get the maintainer to pull this into the project.

#6 solved the problem for me also, Thank you.

Thanks to all for your help.
I have committed a slightly different fix.
As each field instance is unique for a given combination of entity type, bundle and field name, it is better not to use field ids that also include unwanted parents and may cause duplicate keys for the same settings.
The committed solution uses these entity_type-bundle-field_name combinations to define the settings keys.

anrikun, glad it got fixed. The entity_type-bundle-field_name combination is a good way to go too I would think. I have not tested that however, so I cannot say if that accounts for a field showing multiple times per page load. Does it account for that? When using id's the form api accounts for the fact that the field is getting loaded into the form more than once and changes the id for each instance.