I’m trying to figure out how to create <form> tag patterns for forms which have #tree element in their structure set to true. Particularly I have taken content_display_overview form for example. This form controls cck-fields visibility for a content type (I know that display options for a field can be set via <display> tag. But this is just an example)
Here is a fragment of form tag I managed to write. It is intended to set display options for 2 fields ("f1" and "f2") of Story content type. It runs with no errors but doesn’t seem to affect actual display fields configuration for the content type.
What is wrong with this fragment? May be #treed forms are not supported at all?
<form>
<form_id>content_display_overview_form</form_id>
<args>
<value>story</value>
<value>basic</value>
</args>
<field_f1>
<label>
<format>above</format>
</label>
<teaser>
<format>default</format>
<exclude>0</exclude>
</teaser>
<full>
<format>default</format>
<exclude>0</exclude>
</full>
</field_f1>
<field_f2>
<label>
<format>above</format>
</label>
<teaser>
<format>default</format>
<exclude>0</exclude>
</teaser>
<full>
<format>default</format>
<exclude>0</exclude>
</full>
</field_f2>
</form>
Comments
Comment #1
dan.nsk commentedOk, I have taken a closer look inside the module’s code. It turned out that forms with #tree attributes are fully supported.
Still there is a problem with the fragment mentioned above. All values from the pattern apply correctly to the site config except of exclude values. All cck-fields always become excluded after a pattern run – no matter what was supplied inside of <exclude> tag.
I have examined patterns_sync_form_values() function and found out that the problem with my pattern is in the form definition rather than patterns module.
Look at the content_display_overview_form definition fragment:
It has a checkbox with #options attribute defined. Is this normal? FormsAPI documentation doesn’t provide #options attribute for checkbox input type (http://api.drupal.org/api/drupal/developer--topics--forms_api_reference....)
It seems that #options attribute for a checkbox confuses patterns_sync_form_values() function. As a result, 'exclude' checkbox value gets converted into array instead of scalar and the form gets filled with wrong values.
As far as I understand it there are two ways to fix this problem. First is to correct the form definition itself. The second is to provide protection for such cases in patterns_sync_form_values(). The latter way seems to be preferable.
I have made some changes to patterns_sync_form_values() function and now my pattern works as intended.
Could somebody review this patch? Am I on the right path? I’m not much familiar with patterns module and FormsAPI and afraid these modifications can lead to some other problems.
Comment #2
dan.nsk commentedComment #3
vaish commentedThanks for looking into this issue further and coming up with some solutions.
I think that use of #options with checkbox field should be reported to CCK issue queue. Do you mind doing that?
However, that alone doesn't seem to solve issue with exclude being always checked after patterns execution. I tried removing that line from content_display_overview_form definition and still got all exclude checkboxes enabled. Patterns_sync_form_values function is known to have some issues with checkboxes and this may be just another manifestation of that problem.
This is something I need to take a look into as soon as possible and I'll wait with applying your patch until then to ensure nothing else gets broken in the process.
Thanks,
Vaish
Comment #4
dan.nsk commentedThis is very strange. For me exclude tags worked well without that line in content_display_overview_form (and with no patching of patterns_sync_form_values)
I think what happened here is that you removed only one unnecessary #options attribute from content_display_overview_form() function. But there are two of them – one for groups, and one for fields. And they are identical. Try to remove both of them.
Comment #5
vaish commentedYou are right, I did remove only one line quickly without really looking at the rest of the code. Now that I removed both, pattern is working. Thanks for pointing this out.
I would say then this is clearly issue with CCK module and not patterns and should be solved there by removing unnecessary #options lines.
Are you intending to report this to CCK issue queue? If not, I can do it. Just let me know.
Thanks
Comment #6
dan.nsk commentedOk, I think it would be better if you did it yourself (to keep better track of the problem)