The good news is that we have an initial version of CCK for Drupal 5.0. The patch to make this happen was the work of several people, dopry, drewish, yched, edrex, maybe others. Drupal 5.0 introduces several changes, most notably moving the handling of content types into core.
I wanted to start a place here where we can discuss development of CCK 5.0 to take advantage of new Drupal 5.0 functionality.
Here are some of the changes/opportunities/challenges I see so far:
1) You can now add CCK fields to any content type (at least any content type you create and manage using the core content types administration screen). I predict there will be a big wave of interest in CCK when people see they can do that (and a lot of new people who may need support).
2) The 'view' of CCK fields is now a field array that can be manipulated in various ways. This should make it relatively easy to add field level access control, among other things. (See http://drupal.org/node/91030 for discussion to get you started).
Anyway, it would be good to start thinking about how to take advantage of these new opportunities, and maybe prepare for a lot of new users who don't know much about CCK.
Comments
User Documentation
There is not much good documentation about what modules work with CCK and what they do, so I started a handbook page at http://drupal.org/node/92375. I'll work on it when I can, but It would be great if others could help get this resource developed. My thinking is that this would be a resource not so much for developers, but for end users who need to figure out which modules to download and install to accomplish their goals (and maybe also for developers so they don't waste time re-inventing the wheel when there is already a module that does something close to what they need).
Core patches needed
There are a couple core patches that are needed for CCK, and they need to be moved along.
1) A new hook, node_types, has been added to allow modules to intervene when content types are added, changed or deleted. CCK needs this to update its tables and caches. The delete hook has not yet been implemented and needs the patch at http://drupal.org/node/83202 to get finished and committed.
2) CCK content types have not included the body field in the past. The new core handling of content types adds a body field that was supposed to have been optional but ended up being required. There is a patch at http://drupal.org/node/90606 to make sure the body field can be left as an optional field, and that patch that needs to get committed.
Patches have been committed. Thanks everyone!!
Migration code?
Before I start writing it I'm curious if anyone else has already written code to migrate data from a field into the node's body? I've got a description field that I used on a bunch of nodes to replicate the body, now that CCK nodes have a body I'd like to migrate the data in.
I was playing with this body
I was playing with this body vs CCK textarea issue and found some reasons to keep my CCK fields instead making them body fields:
1) You can't control the placement of the body field on the form(except of course using hook_form_alter()).
2) Some of the new features with import/export, formatters, and the ability to select formats for your teasers and node display only work with CCK fields, at least for now.
3) If you use a body field, it is always required. You lose the ability to make it optional.
There may be other differences, those were some I found.
Anyway, you may already be aware of these things, but I thought I'd point them out in case others aren't. Maybe there are some advantages to body fields over CCK fields. If so, I'd be interested in what they are.
I went a head and did it.
I went a head and did it. The biggest reason was getting logical teasers without having to screw around with contemplate and to allow compatiblity with modules like casetracker that expect the body to be filled.
The snippet is up at: http://drewish.com/node/42
Field module upgrade is pretty painless
Just want to let anyone maintaining cck field modules know that the upgrade process for the field modules seems to be pretty simple. The text, number, and userference modules only needed a fix to the path for help and were ready to go. The date module needed updates for new cache handling methods (very simple, just need to name the cache table in the function) and a fix for a placeholder.
The biggest change for field modules will be for those who haven't already updated to the formatters to get that done, but that is needed for both the 4.7 and 5.0 versions.
Problem with beta-1
Looks like I'm talking and nobody's listening :-) That's OK, sooner or later people are going to need info on CCK for 5.0. Just wanted to post a note that the cvs version of CCK does not quite work right with Drupal 5.0 beta-1 because an important patch to the node module did not get in until after that. It does seem to work if you just overwrite the node module in beta-1 with the current cvs version of the node module.
I'm listening
Trust me - although nobody is replying, your posts are NOT falling on deaf ears and I for one appreciate them. I think your work and efforts for CCK in 5.0 are fantabulous (if not a word, it should be!)
Date field on CCK module
I would like to ask you about the date field in the cck module(drupal 5).
I have installed the cck module and the date module for cck. This module works fine.
But....
exists a way or a module to make a search on this date field.For example, i have a content type with an expire date(date field)-----can somebody search for possible dates in the content type , and bring the results that are before the expire date;
Can be searchable the date field;;;;
gtsopour@gmail.com(Greece)
Thanks !!!
G.I.Tsopour
G.I.Tsopour
gtsopour@gmail.com
This can be done by using
This can be done by using the views module with a filter like "expire_date greater or equal to now".
This is more like listing a set of nodes that satisfy a certain criteria than "searching", but with the flexibility that the views module has to offer it should take care of most of your needs.
any node type
what are the challlenges for making cck fields be attachable to module defined node types? would be nice, although many modules are no longer defining own node types so maybe we are OK there (e.g. og, casetracker, event, ...)
It may be that all node
It may be that all node types are now cck-enabled by default because cck can attach fields to any type in the node_type table. I just tested book and blog, which are turned off by default in a clean install. When I turn them on, their types get added to the node_types table and I can add cck fields to them. So I guess the key is to make sure other types get set up in that table, probably by defining hook_node_info().
Exciting, isn't it ? :-)
Exciting, isn't it ? :-)
Field level access control is SWEET!
RE: "This should make it relatively easy to add field level access control, among other things."
This would be awesome. Will this leverage the ACL module, or will this be built into CCK functionality?
Thanks for your work on this. At another point in the thread, you mentioned that you are talking and nobody's listening -- I'm more sitting back in stunned silence :)
What you are doing is amazing.
Cheers,
Bill
FunnyMonkey
Waiting for patches
Thanks for the kind words! It's taking a lot of time, but it sure is exciting to see how powerful this is going to be.
As to how field level access control will be implemented, that's yet to be determined. I'm hoping someone is going to post some patches/proposals after reading through the link I mentioned for ideas to get started.
We will be looking into the
We will be looking into the ACL module for some work fairly soon -- as we get this first round of work done, we'll be thinking about the issue of field level access control -- this is something we'll want to implement at some point, hopefully within the next few months.
Cheers,
Bill
FunnyMonkey