Neutered Nodes: CCK's Dark Secret
10.07.2006
Update 2 (march 1st, 2007)
Thanks to numerous improvements in CCK itself, and drupal 5.0, I now officially disagree with myself in this article. My criticisms last October no longer apply -- CCK now makes everything easier, and I've personally had an easy time pushing changes from development, to stage, to production using CCK. Consider this article a historical curiosity. (More info...)
Update: this is a fairly contentious claim, so be sure to read the discussion in the comments
When planning the development of a drupal site, be wary of using the content construction kit (CCK). While its one of drupal's most powerful modules, its also probably one of the most inappropriately used.
In general, I'd only recommend using CCK when:
- The client being able to define their own content types is a top priority.
- You don't need to alter the node forms.
- You won't be needing to integrate the nodes into other modules.
- And overall, you won't need to do anything special with the nodes.
As I see it, CCK nodes have one, and only one advantage: you don't have to build a module. Ironically, that advantage happens to be CCK's biggest weakness as well.
I haven't used CCK for a project in many months. The reasons are straight forward:
Code Is Actually VERY Useful
Even in cases where I have to define more than 5 content types, I'll always use the custom module route. In particular, here are just a few reasons why I'd rather have a custom module:
Full Control Over the Database Schema
Its nice that CCK builds database tables, but at the same time, you'd be suprised how easy the .install files make it laydown, and change the database -- its a lot easier than say -- trying to write custom queries for the CCK database .
Hard Coded Node Types == Control && Less Things to Worry About
If you've ever had to push changes to CCK node types to a production server, than you'll know what I'm talking about.
CCK is still BETA
And the developers of the module aren't calling it beta for kicks. It doesn't work perfectly, and the developers are the first to admit it.
CCK Node Types Cannot Invoke Drupal Hooks
This is without a doubt, the number one reason to avoid CCK nodes. When you move to CCK, remember all of the hooks that your nodes will never be able to see.
I use CCK as a last resort, because I can't live without the power of the hook system. If you learn these hooks, I promise that you'll find improvements in the speed, ease, and quality of what you develop. Here's just a few hooks that tend to be useful in my node modules:
- hook_block
- hook_filter
- hook_form
- hook_help
- hook_load
- hook_menu
- hook_prepare
- hook_search
- hook_submit
- hook_validate
- hook_view
Until, CCK node types can invoke these hooks, its hard for to not stand by my opinion that they are "neutered" nodes, and should generally be avoided when the requirements go beyond some quick phptemplate theming.
Note that non-web developers should ignore everything I just said. For you, CCK is probably a great module.
Syndicate
Head Drupal Chef at:
Recent comments
- template.php.
<?php$vars['wha
19 hours 46 min ago - newbie question
3 days 12 hours ago - love counter culture.
John
3 days 23 hours ago - Moshe, with all due respect
1 week 3 days ago - this was painted in 1944
1 week 3 days ago - Thanks for the post. Helped
1 week 3 days ago - Thanks for the WYSIWYG
1 week 3 days ago - Thanks for interesting post!
1 week 4 days ago - Thanks for interesting post!
1 week 4 days ago - thanks for your post!
I have
1 week 5 days ago
Comments
CCK's Drupal LOL :P
CCK, using node_realtionship fields is views_fusion etc, :P
I agree. So how *does* one start a custom node type in Drupal 5?
Page and story have been swallowed by node.module. I feel lost and alone without those two friends.
If any one of the following three questions have been answered anywhere, I think I would be well on my way to enlightenment:
* how to create a custom node type module in Drupal 5
* how to upgrade a story-based sample module to 5.0
* where is there a node_example module (or a simple module that will serve as an example)
Neither the handbook nor the "HEAD" node_example api answer these pressing questions of our time. I'm looking at book...
This seems a natural follow-up to reasons not to use CCK!
Guidance enthusiastically sought.
(Apologies if this posts twice... the form doesn't seem to like me today.)
CCK the way in Drupal 5... now how to modulify it
Nick Lewis recanted, been using CCK myself for custom node needs in Drupal 5, but still looking for how to create these programatically so one can have a portable custom module.
Did Drupal 5 change the great CCK vs. custom module debate?
I tried posting this a few times as an anonymous user before registering. I apologize if this shows up as a duplicate.
I am developing a tool called Promise that requires a mix of information from the user's profile, dates, description, and other 'settings' in the Promise content types. Other users are able to commit to these Promises. This work is being done as part of a graduate program in interactive environmental journalism. I've gone through a few development cycles with the students moving from design documents > interface mockups > functional prototypes. I created the prototype of this tool bypassing most of Drupal and just adding PHP to pages. I was planning on fully "drupalizing" Promise as a module, but someone suggested developing it with Views and CCK.
The interfaces we've developed for Promise are fairly complex with Digg like badges, popup calendars, and other javascript to make creating and promoting Promises as easy as possible.
The other constraint I'm dealing with is a desire to let the grad students develop in their own Drupal installs. When the projects are ready they'll be migrated to a beta version of the live site with a snapshot of the users and data. If their project plays well with others, I'll move it to the live site. The workflow will be something like...
projectdev.oursite.com > beta.oursite.com > www.oursite.com
It seems like this would be more difficult to move Views and CCK data than to install a module. Is their information somewhere about how to merge Views and CCK from multiple sites?
We are going to run this on Drupal 5. So what do you think, CCK or module?
___
Kevin Reynen
Integrated Media Coordinator
Reynolds School of Journalism and
Advanced Media Research
University of Nevada, Reno
My Take And A Call For Some Help
I see the benefits of CCK for the avg joe user with little coding knowledge that needs to extend a very SIMPLE page or story type with EXTRA FIELDS. It's fairly quick, cheap and easy. Like a good hooker ;-)..
But outside that, it is no longer really for the avg joe user. At least not in its current state (maybe as it matures in 5.0 and integration is brought in with it's sibling modules that extend it's funcionality that might change). The reason why is that to do anything outside of extending a simple type with extra fields, requires you to understand php, mysql, the drupal db schema, and sql (joins). What you're doing with the ide ain't going to help you if you don't know all of the other stuff.
My thoughts were that CCK was designed so that avg joe user could use the ide to create their custom content type quickly and move on with whatever they want to do. But the minute you need to do anything past the simplicity and especially to do anything that really would require two tables, your gonna need programming knowledge to use CCK effectively. And at that point, i've asked myself what a lot of the other posters have already asked themselves, maybe it's better to just create a module. I have to know all of the innards / hooks anyway. I might as just bite the bullet and write myself new module versus trying to learn the gammut of CCK table relations, and underlying code. And perhaps, my module will be more tightly integrated, perform ONLY one thing but do it well, REQUIRE LESS TABLE LOOKUPS (PERFORMANCE) and as a result more bug-free (assuming a write good code).
At least that's my experience.
And that's where i'm at right now..
fwiw, i'm about a month of long days invested in drupal trying to learn this system inside and out. One very simple task i want is a MORE ROBUST EVENT. One that allows you to attach a venue to the event via foreign key to a VENUE table. More specifically i'd like that VENUE to be applied via a select menu. Extra functionality/difficulty would be having 2 more select menus: 1 by state, which would then drill down and populate the 2nd City Menu, which would populate the VENUE Select on the fly.
SIDENOTE: i can't believe this doesn't already exist as a module in drupal. A two table VENUE to EVENT relationship seems like pretty standard functionality required of a CMS that supports events yes? After all, why should someone have to reenter the same venue (possibly mispelling it) and lets say an associated url to that venue every time they enter a new event? The answer is they shouldn't. But right now, as far as i can tell, that's the best drupal has to offer.. cr
So, i thought let's roll my own. I didn't want to create a module for this. I still don't. But i spent 2 weeks with nodefamily, CCK, using node_realtionship fields, views_fusion, etc to try to get this thing to work. It still doesn't. The maintainer of the module claims i can do what i want but the views_fusion doesn't seem to be pulling the information from the two table the right way eventhough i've "fused" them with nodefamily.
So what do i do, I go in and walk through the drupal db schema and try to figure out the table relationships. I handcode a 5 way join in a php snippet (scrap views all together) to pull the information i need and format how i need. It ain't pretty but it works.
Point is to use cck effectively i need to be a developer. Even then it didn't work (but i think that's because some of the sibling modules haven't matured yet).
My question now is: do/should i write a module for this event_venue thing? and i think the answer is probably yes. I want to get moving on this though because i've mostly spent time getting my foundation in drupal versus getting anything done (creating cms based sites ;-)).
So.. can anyone offer some good tutorials or an example of a module outside of the basic examples on the drupal site? Something tells me i'm just going to have to bite the bullet and dive in (more than i already have).
thanks in advance and sorry for the long post
I was afraid to say anything :)
On several occasions, I've gone down the CCK path with clients, always to turn back and resort to custom modules instead. I don't believe CCK was ever meant to be a way around creating modules but rather a simple way for non-technical users to create custom node types.
I consider the storage of CCK node data to be a black box. It's not to be integrated with, designed around or relied upon for data retrieval except by CCK itself.
If you need a very simple type of node that doesn't already exist, or if you just want to create a simple node type so that you can provide different rules to it (permissions, taxonomy, whatever), then CCK is a reasonable choice.
But if you have any need for functionality that is not built in to CCK, you had better write your own module or hire someone to do so.
And why some do not
I have been working with Drupal now since July and I have figured out a lot of complex things, even have fudged a liitle with PHP with good results. I even understood taxonomy right from the start. But for the life of me, I can't seem to figure out how to do the simplest of things with CCK. It's as if I'm blind and walking into a tunnel at midnight. And nothing I've read thus far breaks it down and sheds any light on it for me.
Well said
I am a newer user of drupal, and in using CCK, questions of the very sort voiced here by Nick have sprung up. I am glad to see that these issues are very real, that others run into them, and that there may be better ways to go about them.
Thanks.
I've had the same nervousness
even though I haven't used CCK a lot yet, but I was never sure if that was just me.
While these new directions like CCK/Views etc are fantastic pieces of work and give a lot of power to non coders, the complexity does make me a bit nervous. Although I do admit it is more an irrational feeling at this stage.
Because Drupal doesn't really have any decent staging functionality (eg for configuration AND content) yet, I find myself wanting to keep the 'database' as simple as possible and put as much logic as I can into the 'codebase' instead. I can keep my codebase version controlled and can easily stage it between different servers etc, whereas I find doing that with the database quite difficult. I realise that Views etc does allow exporting/importing views though which is cool.
Personally I'd find myself wanting to create custom modules for new node types, but still be hankering after leveraging the power of CCK fields in them for some of the building blocks. Is that even possible?
I've got a brain and a half, here's why
Could someone explain to me why CCK seems so hard to me? Here's the part where i've got a brain, i've used it before, i've used flexinode too...sure i can crank out a custom node with either of them.
I even know how to theme them to make them look different and pretty. But when it comes to manipulating them, taking what's inside a custom node, and putting it into list or a block, i literally pull my hair out.
What should i do? It's times like this, that i wonder who wrote drupal, and why it can't be easier. I want to take all my custom nodes, and list them (everything in them) in a block.
I've spent up to a week trying to find examples that weren't filled sql queries, and php snippets, and it's quite frustrating. I researched, and found only 2 books that stop at anything remotely useful ;-)
So this is how desperate i am! I've resorted to posting in this blog, i've half given up on drupal forums as my last two posts have gone unanswered for days.
There just doesn't seem to be much learning/methodology to drupal once you get past a certain point, short of becoming a hacker/programmer.
Parse error: syntax error,
Tell me about it... how's this (improvised... and for 4.7... and this is suspect as I'm only developing against 5.0 these days):
<?php function get_da_shiznat() {$your_custom_field_list = array();
$query = "SELECT n.nid FROM {NODE} n WHERE n.type = 'content_your_custom_node'";
while ($node = $db_fetch_object($query)) {
$your_custom_field_list[] = $node->some_cck_field[0]['value'];
}
return theme('item_list', $your_custom_field_list);
}
?>
My instincts tell me that was way to easy to actually solve* your problem.
NOTES:
*And if this improvised code works, a miracle we have witnessed indeed.
Heh... or
Heh... or rather...
<?phpfunction get_da_shiznat() {
$your_custom_field_list = array();
$query = "SELECT n.nid FROM {NODE} n WHERE n.type = 'content_your_custom_node'";
while ($nodeid = $db_fetch_object($query)) {
$node = node_load($nodeid->nid);
$your_custom_field_list[] = $node->some_cck_field[0]['value'];
}
return theme('item_list', $your_custom_field_list);
}
?>
Or alternatively ....
Perhaps wanting to use CCK widgets is an admission that CCK is indeed the way to go?
You'd indeed be correct...
You'd indeed be correct... sometimes... in certain circumstances... but on the otherhand, there are times, when various considerations should compel you to take the different route. It depends on the context. In most cases. There are exceptions.
I don't think I could be any more clear than that.
A new career?
You would be good in politics. :)
Thanks for the prod in this direction
After much frustration trying to achieve total control of CCK and Views, I'm begining to realise that coding a module from scratch would ultimately probably be much simpler, and more versatile.
Is it easy to use the various cck widgets to control data input with a custom module?
CCK Is As CCK Does
It's important to understand what CCK is and what CCK is not.
CCK allows for easy and quick addition of any number of fields to a given node-type. There are some really cool field modules out there that will do some very cool stuff that essentially can't be done with other modules. Example: imagefield will allow you to attach *multiple* *named* images to a single node in a way that themers have easy access to.
Think of CCK as "page module plus". Clients will always change their mind about what fields they want ("We want a sub-title field!") and CCK makes it painless to add them in without having to muck about with the database.
CCK is NOT a block module. It is not a filter module. It does not do "extra" stuff. And frankly, it does a CRAPPY job of DISPLAYING the content. For this reason you need to create a node-[cck-node-type].tpl.php file for each CCK-defined node type AND/OR use Content Template (a.k.a. Contemplate) module to manipulate the CCK display output.
But to call CCK nodes "neutered" is very short sighted. Are page and story nodes neutered? What about blog nodes? Blogs only offer a little bit of extra functionality over page and story... and most of this can be made up for with Views module.
I'm of the camp that says "CCK does what CCK does" and other stuff can be handled with other modules that use the nodeapi to "fill in" the functionality that is needed. Modules like Usernode and Usernodes (yes... it's true... there are two projects with almost exactly the same name) are a good example of the way that modules can "manage" the behavior of content without having to actually define it. In my opinion these are much more powerful than a simple module like bio.module (mine) that defines the content, but can't be expanded with more fields, should someone need that.
I think CCK is one Lego™ piece for non-programmers to build powerful sites. Views is another piece. Perhaps Contemplate is another. But there are still yet more pieces that need to be built. I think that this is where the focus should be put rather than getting people thinking that CCK is somehow a dead end road.
ALL of the node-types on the MTV UK Site (including news entries, contests, and user blogs) are CCK. And that site is chugging along just fine. US Weekly is another "big" site that CCK heavily. Conversely, we built Participate.net before CCK and it was like pulling teeth to manage all of the content that goes into a single movie campaign.
We at Lullabot are highly invested in CCK so I hope that no one feels like CCK is a castrated animal. It's just fine, thriving, and procreating in the wild.
I'm a not-so-newbie, and I
I'm a not-so-newbie, and I find creating my own modules and node types to be easier to understand than CCK. Honestly, I've installed CCK a few times on different projects, and always ended up uninstalling it and rolling my own. I've just never really understood what it was doing. I like to stay close to the code and the database, if that makes any sense to anyone else. Not to be knocking CCK, mind you. I appreciate all the work that goes into Drupal, whether or not I have any need for the particular module or whatever.
since we're talking about this
your comment about having control over the db schema is a valid one, for me - is it easy to do something like selecting a set of cck nodes where a field is equal to some value, or do you have to go through a thousand joins to find the field type and all that jazz? Is there an API for something like that?
-o
Out of curiosity
Nick, what do you do when one of your hardcore projects requires a custom node with several seperate image uploads?
For instance, I'm not sure if this would qualify as hardcore for you, but what if the project spec required a "car" node-type which, aside from several text fields and dropdowns etc, also contained the following elements:
1. Image: Head on view
- Single image, displayed at 640 x 480 px; links to full size image.
2. File: Technical illustration
- Large downloadable PDF file (with thumbnail)
3. File: Quicktime-VR
- Clickable thumbnail of keyframe, movie opens in pop-up window.
3. Image: 3-quarter view
- Single image, displayed as thumbnail 250 x 250 px cropped; links to full size image.
4. Image: Side profile
- Single image, displayed as thumbnail 250 x 250 px cropped; links to full size image.
5. Images: Additional
- Variable number of additional images (interior, detail, engine, etc). Viewable as a
6. File: Owner's Manual
- Large downloadable PDF file
* Each of these items will need to be displayed in specific locations throughout a pre-determined layout (i.e. an attachments table won't cut it).
How exactly would you approach this?
-Zach
CCK use case
That's exactly the sort of reason why I'd opt for CCK in that case at this point. It takes less time to use CCK to attach a bunch of "advanced fields" to a node type and then use CCK theming to place them wherever than it does to develop all that file handling myself. It's ugly either way, but I have to deal with the file system less the CCK way. :-) If there were an easier way to do that without CCK, I'd be a very happy man. (If someone knows, please tell me!)
As for selecting a lot of CCK-based nodes based on some where condition, that's what the Views module is for. I'd hate to have to go through it myself in SQL. :-(
This is the limit of automation: You only get the automated bits.
In-betweeners
You said: "Its bloody simple to teach them how to mess with the formapi"
I'm presuming this is aimed at people who already know PHP. I'm in between a PHP dev and a total no-nothing about PHP. I have a coding background, so I can hack a bit at PHP, but I'm no where near _knowing_ it. Though I did manage to make a new filter module by hacking at another one. ;)
The reason I'm telling you this is that I'm in the planning stages of a site that will rely heavily on custom nodes. I will want them to be layed out in a particular way both on the input end (because I won't be the only one adding nodes) and on the display end.
Do you think, given that I know very little PHP, that I would be better off trying to work with CCK or learning a bit more PHP to do it in modules? Do you have a tutorial for doing it in a module (please forgive me, I didn't do a search first).
This is an interesting article. TBH, I would like to not be dependent on CCK because it seems to be very slow in coming and the multitude of submodules is confusing. But the thought of doing it all in a language I'm not very good at is daunting. So I'm on the fence and would appreciate a push... :)
Thanks,
Michelle
In your case my
In your case my recommendation would be two fold:
1. Use CCK since PHP coding is a problem for you.
2. Do the best you can with CSS and a phptemplate override of node form.
As I said earlier, most of my fear about CCK is related to hardcore projects with lots of requirements, and dev-to-production workflows.
http://www.nicklewis.org/node
http://www.nicklewis.org/node/842
here's a link on phptemplating node forms.
Thanks
Thanks for taking the time to answer. I'll see what I can do with CCK, but it's nice knowing there's alternatives if I hit a wall.
Michelle
great discussion!
Thanks Nick for starting this discussion, and for everyone who has participated so far. This has helped shed much light on all of the cck vs. custom module question for me.
I'm working on a major site for my organization, and have been struggling with this very question.
peace,
blue
It's easy to write CCK off as a newbie crutch...
It's easy to write CCK off as a newbie crutch... until your custom node type needs the ability to add things like multiple custom image/file fields. Then the programmatic advantages of CCK quickly start to outweigh the joys of reinventing the wheel.
Richer data types
Honestly, one of the things I like most about CCK is not just its web-editability. It's that it has a much richer set of data types available, if you use the extra add-on modules. Want an image? Just throw the image type at it. No need to hassle with the file system code. Want a field that you know is going to be an email address? Just use that field type and you get all of the validation and auto-linking free of charge. If my node is just 5 text fields and an int or two, sure, I can whip that up as a module in an hour, maybe less if I'm well-practiced. But then I need to do my own validation for email fields, my own force-to-int code, my own image handling, etc.
If it were easier to do that with a custom node, if core supported richer data types out of the box, that would eliminate a lot of the need for CCK. Or, rather, it would be yet another part of CCK that squeezed into core, like the "basic node" concept in Drupal 5.
The biggest challenge for me with CCK that I see on the horizon is that I don't know it's database schema, which is going to be a problem when using the new importexportapi module for scheduled updated data, something I have coming up rather soon. That is of course, unless someone's already done up a CCK engine for it. :-)
A couple weeks ago, I needed
A couple weeks ago, I needed to learn CCK's underlying structure and API and started CCK for developers. It's still in flux and I've had no time to incorporate the very excellent comments at the bottom, but it might be worth a read to save you some time.
Also...
AFAIK there is functionality in importexportapi for importing/exporting CCK stuff. It was a bit buggy last I tried it, but this was back around Drupalcon time. :)
XML + CCK = killer app.
XML + CCK = killer app.
Need I say more.
Need I say more.
I sure wish you would. Please point the unlightened in the proper direction for proper convincing.
mixed feelings
I have mixed feelings about CCK. I've used it in conjunction with OG and the relativity module, with wonky results. Overall it's smooth enough to be promising, but it has enough rough spots to be maddening.
It is a quick way to get things going - it is *definitely* good enough for doing a demo, and on a site where the nodes aren't related very strongly it can be very useful. When it comes to the typical production server or public beta, however, I start to agree with Nick.
CCK nodes are not neutered
What you write about CCK types being lost for hooks is simply not true.
Most of the hooks you mention don't have to belong to the code of the associated module. For most of the others, there's hook_nodeapi.
So you can use CCK to have your db storage managed for you, and simply write a *small* custom helper module to add the icing :
- hook_form_alter
- hook_menu
- hook_block
- hook_links
- hook_filters
- manage load, view, validation and submission steps with hook_nodeapi (not sure about 'prepare') - plus if there is something you can't do with hook_nodeapi, you still can consider building your own CCK field (much simpler than building a whole standalone module)
- OK, dunno about hook_search
It's true that there are issues with CCK, the main of which IMO currently does not lie in the code, but in the patch commit pace.
It's true that it cannot fit all complex situations.
But please don't spread FUD, it does not need it - it *works*, it's functional, flexible, and suitable for many ("most" being by nature arguable) use cases.
My viewpoint is as a
My viewpoint is as a developer who's asked to build things that never look like drupal.
I suppose you could use form_alter, node_api, but my experience is its easier to just define hook_form, and use the standard node insert,delete, and update hooks instead. And less prone to unpredictable behavior. I'm not sure if you've ever had to do extensive form_alters on a cck form with more than 8 fields, but I assure you the experience will make you wish you had just made a standalone module.
The nodeapi hook behaves very unpredictably with CCK fields in my experience.
I've also built modules to handle blocks, menus, themed output, and the preprocessing of the output for cck node types. It was a journey indeed, and in the end pretty hackish.
In this new project I'm working on, CCK is no longer an issue, and overall I'm just saying that things are moving a lot faster -- not to mention the modules themselves can be reused. More often than not, a CCK node type does indeed do something useful.
Its a great module, but in my experience it complexifies things, the second your trying to do something hard, that drupal doesn't like to do by default.
And, I don't know... I think
And, I don't know... I think a little bit of FUD is a healthy thing every once in a while. I think CCK is among the top 5 most valuable modules in the contrib -- without question.
What I'm uncertain about, is that it always makes things easier, and if you need a non-existant node type, it is always the best choice.
Especially new developers who would probably have an easier time learning the hook system, rather than form_alter, and nodeapi. We can agree that nodeapi is not the easiest of hooks to learn how to use. (but at least its not like hook_search...)
FUD is not welcome
Yes, it is true that custom modules provide more control. So if you like them, use them. But there is no need to villify CCK like this. You enumerate reasons for your viewpoint but the reasons are so vague as to be useless.
yched is on the money as usual. CCK does what it does and custom code is still needed to finish all your node needs.
In general, it is more helpful to state issues in a positive light like "cck would be more helpful if it did x.y.z". but stating that CCK is a risky choice and giving vague reasons is pretty much the definitioon of Fear, Uncertanty, Doubt. That type of loose logic has no place in a technical discussion IMO. Having said that, this is your blog and I'm not trying to dictate what happens here. Just want to call a spade a spade and say that this post represents weak science IMO. Thats surprising, because I have enjoyed many past articles here.
I don't think the content and tone of this article match the later statement i think cck is one of the top 5 valuable modules in contrib.
FUD? No.
I have to agree with Nick. As a longtime PHP developer with experience in dealing with all kinds of codebases I am finding CCK extremely difficult to deal with. It's not FUD to tell people of the limits of the module.
I'm only trying to help people stay out of trouble...
Villifying CCK... the conventional wisdom seems to be the CCK is a great choice in any situation where you need a special content type, and phptemplate will take care of the rest. My stance is that you need to be careful, and that in its present form, there are going to be cases where it complexifies things, instead of simplifying them. To me, its fairly straight forward: the second I have to code a module to make my CCK node work the way my set of requirements say its supposed to, its probably a wrong choice.
I wish I written this article a more clearly, but I standby my words. I stand by them from personal experience, from problems that friends have had, and the large percentage of questions I get that ask me how to make CCK do something that its not really ready to do yet.
If you read the reasons I give, it will be pretty obvious that I'm speaking to programmers, not end users. On the one hand I want to evangelize great drupal modules. On the otherhand, lots of people -- not all of whom have even begun to understand the hook system, much less how CCK works, have deadlines, jobs, and overall sanity that depends on them not making bad decisions when they plan their first few drupal projects. I don't think it's trashing CCK to warn them that its sometimes easier to code their own module.
More specifically, and technically...
As a programmer I fear complexity. One of my ways around this keeping code consistant, and together. Yched was right, you can make a menu, and block, a menu callback that handles your CCK node type. If I have a press release content type, with blocks and a menu, I also want the controllers for the content type in the same file. That's my personal preference. I also don't like having things like fields, and ndoe types in the database. Probably the biggest reason is there is no good way of transporting changes from dev to production -- and things do get hairy when you try... I would know. These are my biases, and I'll forfeit those grounds. On the otherhand...
Using nodeapi and form_alter to make up for CCK's lack of hooks is a hack
That, and its reliance upon phptemplate for output is the real meat of why I sometimes harbor fear, uncertanty, and doubt (literally FUD... not strategic, marketing related Microsoft FUD... one wonders what I'd be trying to gain) about using CCK for a project.
Yes, nodeapi can emulate validation, load, submit, and every other hook relating to users submitting a node form. But that's not what nodeapi is designed for. If you read the hook's documentation it specifically states:
While technically, the nodeapi is used to alter the behavior of nodes in other modules, the fact that I'm surrounding the hook with a if ($node->type == 'content_press_release) tells me its a hack. I use hacks all the time, but only as a last resort, and by the time I'm alterting my CCK node type like this, I will be complexifying my problem -- not simplifying it. Nodeapi is not an easy hook for me to work with -- maybe I'm incompetent, but there's a lot to be said for finding ways to prevent ones own incompetence.
CCK is great at inserting all sorts of fields into a node form. BUT, its not good at making the result look polished. This isn't CCK's fault -- the developers behind CCK are not psychics, they cannot forsee the "creative briefs" I get, and I don't expect them to. That's why I bite the bullet, and take out spend the extra hour working out inserts, updates, deletes, and installs. I know for a fact that I'll be saving myself the time, and the bugs that are involved in completely rearranging a CCK node form via hook form alter. In once project, I had to override values in more than 60 seperate form keys to get it looking like the psd file. It probably me over 4 hours to get right. It would have taken me an hour at most had I just been using hook_form().
And how the hell am I supposed to teach someone how to do that? Its bloody simple to teach them how to mess with the formapi, but how to effectively alter tons of form elements is something that is not merely hard to teach... but that no one should ever have to learn. Why have a form generated if all you are going to do is alter every element afterwords?
I don't have very many suggestions for CCK. Sorry. Any attempt to allow a module to ovveride CCK seems like a solution worse than the problem. The node hook system is powerful, and a lot of that power comes from the ease and options it puts on programmers. CCK makes a sacrifice of ease, and options by having it configured in a form, and its behavior stored in a database. There are lot of cases were the focus is giving non-programmers unprecidented control, and for that CCK is in a class of its own. But there are other cases where the need for the programmer to control code trump the former... and merely pointing that out is hardly trashing CCK.
Very late to the discussion... re: your nodeapi issues.
its reliance upon phptemplate for output is the real meat of why I sometimes harbor fear, uncertanty, and doubt
why? it's is not reliant on phptemplate, you can use .theme files... if you're brave... I don't really know any active drupal devs who use anything besides phptemplate....
if ($node->type == 'content_press_release) tells me its a hack.
This is your hackery, and not the elegance of a well written nodeapi module that lets you select which nodes it will affect. Often you want to include the options provided by you nodeapi module on the node type settings form. nodeapi does not 'emulate' anything it is a hook into the node life cycle.
CCK is great at inserting all sorts of fields into a node form. BUT, its not good at making the result look polished.
please recommend better baseline XHTML and CSS for us to spit out.
cck's strength is not output. see.. Views, Panels, Contemplate, phptemplate.
good css can go a long ways as well.
In once project, I had to override values in more than 60 seperate form keys to get it looking like the psd file.
You should probably improve your css skills if you have to over ride 60 items on a single form, or write a theme override for the form so you can deal with the forms output instead of its structure. Your site will also probably experience better performance with a theme override as well.
You are correct about CCK being beta, but is getting beyond that. As of Drupal 5 it should become a basic field module that allows you to extend any node type. Theoretically you could add fields to your custom node types. It is not a panacea, but very powerful and a tool people should learn to understand... Its various field mechanisms are improving. People are starting to learn how the pieces go together.
We need to encourage beginner users on hobby projects and advanced users on larger projects to actively use cck and provide helpful feedback in the issue queues so we can move the module forward and improve it.
another reason people use
another reason people use CCK is it's easier to use than creating a custom module - for newbies.
Post new comment