Compatibilty with date module

After further research, the Date module does use the #required property for all its form elements. However, it is done by a #process function, which is called after hook_form_alter() where Conditional Fields looks for #required.

At the hook_form_alter() stage when Conditional Fields runs, a date field is sort of a super field that can consist of multiple normal fields; at the #process stage it expands the super field into all its constituent fields.

I found this diagram really helpful for visualizing the sequence: http://drupal.org/node/165104

I am now wondering if Conditional Fields's hook_form_alter() code should instead be executed at the #afterbuild stage, so it deals with the final, processed form (hook_form_alter() could register a #afterbuild callback.) Will need to think about it more...

I hereby offer a $5 bounty to anyone who can fix this issue within two months. Payment would be via PayPal.

The money probably is not commensurate with the work, but perhaps it will provide some extra motivation to someone who was already thinking about fixing it.

Postponing all compatibility with non-core cck modules to future releases.

Please try the latest releases of both modules and update this issue.

Please report here any incompatibility with date module.
Please note that work on compatibility issues with non-core cck modules is postponed after the release of Conditional Fields 1.0 (but patches are welcome of course).

I'm still seeing this behavior with the Date and Location modules. Both field types have nested fields with their own #required attributes, but conditional_fields_node_editing_form doesn't seem to recurse.

I should note that the date and location fields are being used within field groups, and it is the field group that has the conditional field setting (i.e. when another field has the right value, the field group becomes visible).

Using Conditional Fields 6.1-dev (Aug 15 2009) and Date 6-2.3 Initial testing is showing that i am able to set a date field as a conditional field that is properly triggered. I tried saving the field triggered and not triggered and so far is appearing to work properly.

Will test further and will report of any strange behavior.

If the Date field is required I am getting an error message saying the date field is required even though the date field is not triggered and thus is unavailable.

If the date field is not required then it looks like it is working properly - at least thus far in my testing...

I'm willing to make a financial contribution to getting the this issue fixed and the date module compatible with conditional fields. Let me know if your interested.

I've done some work on this. I have not extensively test this, so please use with care. I think it should for the most part work however.

Small change

Missed the returns in the after build. They now return the form, instead of nothing.

Last patch has a typo on both _form_validate() lines which causes the required checking to not work. #conditional_date_fields should be #conditional_controlled_fields.

Updated patch attached.

I've done a bit more testing, and I think this is working quite well now with the last patch. It doesn't seem to affect anything else, and appears to make date fields work as expected.

The patch itself could probably be re-factored a little bit to reduce duplicate code and checking of conditions, but I don't quite have the time to do that at the moment.

Sorry for so many unanswered posts and renditions of this I believe this one is the right patch now. :) The last one would work, this one just cleans up a variable that was made which was never used.

PATCH SUMMARY

• Changed the node editing form alter to be run in an #after_build. This should catch any modules which expand their fields in a #process callback.

After build callback (Was form alter).

• Adds a copy and a reference of each controlled field in the afterbuild for use in validation callbacks. (See below)
• If the controlled field type is 'date', then set the field to be validated right away in the afterbuild, and check the validation later ourselves. (This avoids duplicate validation errors being output).

Validation callback

• If the controlled field is not triggered, use CCK's default value callbacks to get the default values. If it is a date field, then do some extra work to handle the default value, and finally set it not only in form state, but also in #value on the elements so that if there is a validation error, the form is rebuilt correctly. (This was the reason for the by ref copying).
• If the controlled field type is a date, then validate the field now (This was the reason for the copied value above, along with the by reference). We have to do this, as part of the date validation routines use #value on the elements to check, so we had to update it before validation could go on.
• Finally, check the required property on date now that it's value has been reset

Having written that, I'm not 100% sure on the logic behind needing to re-validate the date fields manually. I know as I was putting this patch together there was a reason for it, but now that it's finished, I might need to recheck if that is actually required.

Ok, so I just checked what I wrote above, and it turns out I was right, the logic is wrong. Here is what I hopefully think will be the last patch. :)

SUMMARY

• Form alter made into an after build
• In after build, a reference to each controlled element is placed in $form
• In validation, if the field is not triggered, CCK Default value gathering is now used
• If the field is a date type, then we use a custom process to get the default value
• We set the default value in $form_state AND on the element copy in form. We have to do this as if there is a validation error, then #value on the element is used to rebuild the form, not $form_state

Realized that XOR logic was a bit miffed.

Corrected.