CCK Field UI support for term fields
bangpound - June 14, 2009 - 08:17
| Project: | Content Construction Kit (CCK) |
| Version: | 7.x-2.x-dev |
| Component: | General |
| Category: | task |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Description
This patch lets CCK support term.module fields in nodes. See #491190: Provide a taxonomy term field type for that patch.
(I don't expect this to be committed necessarily, but I do want to make the patch available for others to test with.)
| Attachment | Size |
|---|---|
| cck-term-field-support.patch | 1.8 KB |
#1
This patch requires #491130: cck_field_update_field does not generate the 'data' field before calling drupal_write_record for anything useful to happen.
#2
DO NOT USE THIS PATCH. Use the original one attached to this issue.
#3
This patch adds support to CCK Field UI for taxonomy term fields. A field's allowed values can be the terms in a single vocabulary or the combination of multiple vocabularies.
#4
Thanks bangpound.
To all, note that we need #488542: Tie Field UI pages to any fieldable entity in to make CCK HEAD UI available on taxo terms.
+ $widget_type = $instance['widget']['type'];+ $field_type = $field['type'];
+ $label = $instance['label'];
Those variables don't seem to be used anywhere ?
+ // Get the right values for allowed_values_function, which is a core setting.+ $defaults = field_info_field_settings($field['type']);
+ $settings = array_merge($defaults, $field['settings']);
Shouldn't be needed when #509736: Make sure all settings are present at run time gets in. I think it's safe to remove now, we don't want field-type modules code to be littered with "if(!isset($settings['foo']))" or "merge in default settings"...
That's more a question for #491190: Provide a taxonomy term field type, but I'm not sure having a taxo field span over several vocabs is a good idea. [edit: besides, this patch mentions $settings['vid'] (singular)]
#5
Eek! Thanks for checking this out yched. I thought I had caught all the $settings['vid'] strings that hadn't been changed to arrays. I'll chase these down today.
#6
Here's a new patch.
The 'parent' setting is forced to 0 for now. That's the essential functionality but not the full range of possibility.
#7
Committed so that people can more easily test #491190: Provide a taxonomy term field type. Thanks bangpound !
Note: this form lets you change existing entries in $field['settings']['allowed_values'], but not remove them or or add a new one...
Might be a little tricky :-(
Thus, leaving 'active' for now.
#8
Thanks yched. I'll post a new patch after #491190: Provide a taxonomy term field type lands. The goal of this patch was to let users configure a field for one vocabulary without destroying settings that may have been created otherwise... though I'll admit, it has not been rigorously tested for those stranger cases yet.