Hi, I have been fighting CCK fields for the last two days again. My general conclusion already was that it is a little too hard to grok, so let us get that solved. Why? Because it is too hard to grok. Looking closer at the field that are there, you will notice that the developers were: a) inconsistent. Very inconsistent. Every module with fields is completely different. b) using fields where they should have used widgets. And using widgets where they should have used fields. c) seem to be overly confused about the 'multiple' thing. How? Documentation. This is a catch22, because how much I would love to make docs, I am too unfamiliar with CCK to write docs. Even some sketchy notes by/from the original designers (why multiple, what was the idea behind fields vs widgets) can help. Are they anywhere? And more technical: Documentation can help us solve some of the issues. But even with docs and examples, this material is very hard to grok. The workflow is like spaghetti, the hooks, using call-by-refs trace back up-to 5(!) hook calls deep! (meaning: hook_foo calls hook_bar, which calls hook_baz etc, 5 of them is the most I counted). Call by reference: Either all of the stuff should be call by ref in all hooks at all points. Or none. Not have $node as called by ref in some $ops (load) but not in others (insert). Hooks vs FAPI. Because the general Drupal-way seems to be towards _altering of FAPI forms, instead of the 'old' hook mechanism, CCK uses many hooks. To alter forms. But not everywhere. These CCK hooks are well documented already, but when it mixes with form alters, you get a messy spaghetti-bowl again. I'd say: either _alters all over the place, or hooks, but never both. Hence I suggest to drop the hook_*() $op == 'form' in favour of form_alters all trough CCK. Fields widgets and the rest. This is confusing. When I read peoples fields-modules my general idea is that no-one really groks this. Eventhough I understand the database architecture behind it , I still think that a) the names are confusing. b) the associated hook ops are badly named. Hence I suggest to take the widgets out of CCK entirely, and stick them in a widget_library.module. CCK-field modules can pick widgets from that library. If they need additional widgets, then they can add them to the library. This way we can do away with the current 'widgets and fields' confusion. And we can enforce people to think slightly better about their fields vs their widgets. Right now, nearly all of the modules with CCK fields have widgets-who-validate-field-data, or fields-whom-dictate-widgets. An additional benefit is that any module can easily re-use fancy widgets without needing the whole of CCK. Another benefit, is that the amount of code that needs to be changed can be minimised. A big downside is the dependency of CCK on the widget_library.module. Who? There are a lot of users, but very few developers for CCK. The main reason, IMO is the very steep learning curve of CCK development. (see above) But I think that enough people are willing to contribute if CCK were a little more accessible. If we can agree on the abovementioned ideas, or provide better ones, then I hope we can get this started with some patches and issues right away. Bèr -- [ Bèr Kessels | Drupal services www.webschuur.com ]