Three fields in chain?

> How can I do that? Is this possible using this module or I need to find a different approach?

I don't know. Try it. It may be it's beyond what the Ajax for this module can do. It would be possible with more advanced JS, but that's out of my area of expertise.

Closed #1835466: Please confirm that the module won't allow more one limited field in a heirarchy as a duplicate.

It may be that the problem is to do with re-attaching JS behaviours, but it would need someone with better JS skills than mine.

I'm not sure re-attaching will fix this but IMO it won't be a satisfactory solution: an ajax reload for each element in the chain is not the best UX.

I think there's a chance to rebuild all elements implied and return the proper ajax commands.

"Related issues" is not working atm. So related: #1986526: Support one field changing 2+ fields

Here's a first approach. It's working nice for my use case (4 fields in chain), but thw whole code involved here deserves a refactoring. I'll wait for feedback before trying to refactor it.

Note: this patch depends on the one at #1986526-17: Support one field changing 2+ fields

Above solution doesn't work when field instances are created in an order different than the order you want in the chain (usually the same order as the weights set for instances in the bundle).

I found this problem when exporting fields with features. They're recreated in alphabetically order and the order by database id is lost.

This may be fixed by a process in two steps in reference_option_limit_form_alter().

How does the creation order and numeric field ID affect things in reference_option_limit_form_alter()?

No, it affects the order of the calls to reference_option_limit_field_widget_form_alter(). In the seval calls to this function, $form_state['reference_option_limit'] is populated, and used afterwards in reference_option_limit_form_alter().

So is that because hook_field_widget_form_alter() is called in field ID order, rather than field weight within the entity bundle?

Sort of. It seems there's no declared order in the code. Instances are retrieved by

_field_invoke_get_instances() -> field_info_instances() -> FieldInfo::getInstances() -> ...

getInstances() method calls field_read_fields() and field_read_instances(), that don't declare any order for the query.

The query can't do that, because the weight of the field instance is inside the serialized data. So it would have to be up to field_info_instances() to do some ordering.

It sounds to me like this could be considered a core bug, as the order the hook is invoked in will be arbitrary.

bug or not, we should work around it. For some strange reason one may want to limit a field's options by a matching field with a higher weight.

Added a fix for the case when there're no match values.

Patch #15 refuses to apply, Also does it support three fields in chain with views?