Main Content

Don't Ever Forget About CCK

Drupal CCK

Don't Forget About CCK

For what it does in the very basic sense -- providing a simple GUI with which to create and manage content types, and adding the necessary fields to tables in the DB -- CCK underneath the hood is actually pretty complicated and very smart. For example, if two types use the same CCK field, CCK will dynamically shift the data that had been in that field into a separate table and drop that field from the table for the content type. If you’ve played with RDBMS at all, you understand why, for the sake of organizational concerns, a look-up table might be needed, but you probably don’t anticipate CCK doing it for you without telling you. This is why we must never write a SQL query that directly addresses a table owned by CCK. Fortunately, CCK supplies function for figuring out where the data is, so this isn’t that difficult of a rule to follow.

You may have already learned by now to just use node_load and node_save to take care of your dynamic data flipping. Amongst other things, it keeps CCK in check and fires every hook. Or does it? After learning this much, you may learn that many people also claim that the real way to make absolutely sure that everything behaves exactly the same as when you submit the node edit form is to, well, submit it. That is, you use a call to drupal_execute to submit the form, and then you can be absolutely sure it’s exactly the same. After all, what if another developer on the site has written a hook_form_alter to do one more thing with the information submitted when a node is created from the form? Of course, you need to know a bit more about Drupal to make this method work, namely the form API. And in most cases, there’s almost nothing to change when switching between the two methods.

Sometimes you do have to worry about it, and it’s not even on your radar to think about it. Instead, you write your code as though preparing the $node object for a call to node_save is all you have to worry about. But then it blows up and doesn’t work. So you Google your problem and find that the other solution authoritative people have mentioned is to make sure things are ready for node_save. Specifically, I’m referring to a project that I thought would take me all of a couple days and ended up requiring more than a week. I was supposed to pipe data from Webform fields into a content type... on another Drupal site. We’re developing both sites, so a co-worker recommended that I use db_set_active, which, to be fair, is the first thing to come up if you search for “drupal multiple db”. The problem is that even in framing your question, you have forgotten that this is Drupal, and its ways are not exactly like those of PHP. In short, you have already forgotten about CCK. Drupal hooks aren’t stored processes in the database, nor are they crons that run and look to see if something has changed in the table. But you can still google this method ad nauseam and see a bunch of ideas that look like they will get you want you need, and towards the end you’ll realize that the best you will be able to do is get a look at the schema on the other site, write a huge, ugly control block to make sure all the cck fields are getting populated, and write the data in that way, and you’ll still have to do crazy stuff like lock the database to make sure you can write in a valid nid and vid.


After having freshened up your eyes, you realize that you were asking the wrong question and a search for “save content to another site” will lead you to eventually investigating XMLRPC and the Services module. Upon setting it up and giving it a few runs with your ‘script page’, you figure you’ve got the hang of it and you’re practically salivating at the coming call to the node.save service. All the CCK hooks are going to fire on this one, and we’ll be home free.

This example leads directly to a corollary to the practical advice I’ve been trying to drive home: Don’t forget about CCK Date. I don’t want to rag on this module too much. To be sure, handling dates with a computer is always going to be harder than you think. After all, calendars are a part of life that people intuitively get. But any time the programmatic creation of nodes is not working as you expect it to, check to see if CCK Date has been anywhere near your site or your content types. It’s not even fair to say that CCK Date is the source of these problems either; any time it is involved in a head vs. desk altercation, it is because there is some disagreement about what the proper way of handling nodes is.

To return to my example of an acute corner case, the default node.save service packaged with the Services module calls drupal_execute, and you might in the course of your Googles come across a thread where Karen S. tells you to make sure node_save will work, and you can find a bunch of other ones with the same advice. It is important to learn to just dive into the code and see for yourself. Drupal documentation is spotty and stale and dangerous to rely upon. Learn how to use ack from the commandline and go find the answer. You will learn more and in the end, you only stumble through threads looking for answers because you hope someone has done exactly that and that they are going to share their answer with you. Sometimes they haven’t or the comment just pertains to a previous version of one of the modules implicated in your problem. You really have to change the node.save procedure to just use node_save instead of drupal_execute.

This Blog was written by William Milton, a Drupal Web Developer with Promet Source.