Rewrite of state handling using a whitelist of supported widgets

To avoid too much pain we could be more specific in field_conditional_state_field_widget_form_alter.
Then it should be save to just use $element['#id'] in field_conditional_state_element_process (at least I hope so...).

But there is also a drawback: We possibly have to list a lot of widget types explicitly within field_conditional_state_field_widget_form_alter. At least I didn't find a proper way how to determine the actual input element (and not one of its wrappers) there.

But in the end we could remove a lot of confusing code within the process and pre_render callback.

It's not exactly a critical issue.
"Critical bugs either render a system unusable (not being able to create content or upgrade between versions, blocks not displaying, and the like), cause loss of data, or expose security vulnerabilities."

It's very annoying, that every widget has another array structure (hook_field_widget_form doesn't enforce any standards) and I have no clue how to handle that, without creating a lot of bad code, getting gray hair and having nightmares...

Maybe I have to do more research on how widgets are handled in Drupal, but I fear that there isn't a nice way to get the information we need...

Because of this I think we should add the process handler within the widget_form_alter hook just to the top level of the given element.
And then we should "search" for the actual input element within the process callback.

If anyone has a better solution please let me know...

Its not about the actual HTML output. The problem is, that during the form building process the widgets are differently wrapped.

For example:
Create a content type with a checkbox, a text field, a file field, a select list and a URL field (it's not in core but there are a lot of sites using it).
Then add a

dpm($element);

in field_conditional_state_element_process (devel needed) and go to node/add/helloworld
The differences between these widget types (especially $element['#id']):

• Text field: The id set in $element['#id'] is not appearing in HTML!! The actual input element can be found in $element['value'], but $element['value']['#id'] doesn't exist. In this case the id in HTML is just $element['#id'] . "-value", but it's not that easy all the time, I fear.
• File field: At the top level #entity_type and #bundle aren't set (it won't pass the initial if statement in field_conditional_state_element_process). Instead we have to go to $element[0] to find these information. But the #id is at the top level again and won't appear in HTML as well.
• URL field: The top level #id finally appears in HTML, but it is a wrapper fieldset of the input element (located in $element['value']).
• Checkbox / select list: The #id from the top level of the element array is applied to the checkbox / select list (<= the "good guys").

So we actually have to handle all the widget types differently, right?

I don't think hook_form_alter (or any other form level hook) will do a better job there. We would still have to "find" the correct ID but starting from a higher level within the page array.
hook_field_widget_form_alter at least is called per field, so this should be less pain, than hook_form_alter.

I created a patch. The extra div is now not longer needed. The main changes are:

1.) Now we use a #after_build callback instead of a #process callback, because during #process the element isn't completely build.
2.) _field_conditional_state_get_element_parents returns the path to the actual input element within the $element array and additionally the path to the field information like #entity_type, #bundle, #field_name if they aren't set on the actual element.
Currently all core widget types and the url_external widget type should be supported (except of "Check boxes/radio buttons"). Field collections (or actual any kind of form where one field exists twice or more) are not supported currently.
3.) field_conditional_state_element_after_build only adds the #pre_render callback to the actual input element as defined by _field_conditional_state_get_element_parents and maps the combination of entity type, bundle and field name to the actual used HTML ID ($element['#id']).

Edit: With this patch #2185759: Select list control fields aren't working would be fixed too and #2200361: Incompatible with #type => text_format (ie. long text fields with formatting) at least partially.

Removed useless code in _field_conditional_state_add_states.

I don't expect any reviews, so I will commit the patch at the weekend, because it will probably fix a lot of problems.

Fixed a lot of coding style issues here.
The #pre_render hook should work as expected (at least it does when I tested the patch).

Small change in field_conditional_state_element_after_build.

Actually visibility states have to be applied to the topmost level and enabled/required states to the actual input element. Will do that later today.

Now we have two different pre_render callbacks.

One to add the states visible and invisible and one to add all the other states.

field_conditional_state_element_after_build checks what kind of states are active for the current element and sets the appropriate pre_render callbacks (only if needed).

We have to handle this differently, because the states visible/invisible should show/hide the whole widget and not just the input element. There is not always a difference, but sometimes unfortunately there are (visible) wrappers around the element (URL field for example). So the state must be applied to the topmost level of $element passed to field_conditional_state_element_after_build.
The other states (enabled, disabled, required and optional) only affect the actual input element, so adding them to the topmost level won't work sometimes (URL field and some core widgets for example).

The whole thing is a little bit complex, but I think it's the most stable way of doing this.

I'll add a check for these keys tomorrow, but these notices should currently only appear for some of the not supported widget types.

Which widget types are you using on this form?
Autocomplete fields aren't supported at the moment. Going to add them tomorrow too (they have to be added to _field_conditional_state_get_element_parents).

It will fail on all widgets (not equal to field types!) where the entity_type, bundle and field_name information are not on the top level of the $elements array in field_conditional_state_element_after_build AND which are not explicitly handled by _field_conditional_state_get_element_parents.

Can we create our own documentation pages for FCS? I could write a table of supported widgets then.

You mean a coded whitelist of widgets that are allowed to be control fields?
Sounds like a good idea.

I introduced a whitelist in the new patch. It doesn't really change the behavior of the fcs settings form, because thats not even easy. I created a new issue for that: #2218339: Restrict control field selection to supported control fields.
Unsupported fields are neither usable as control fields nor as controled field.

I fixed a few coding style issues and committed it (patch is attached). Please create new issues for follow ups.