the blessing and curse of cck is the ability to quickly create very complex node types within drupal. it doesn't take very long before the input form for a complex node type has become unmanageably long, requiring your user to do a lot of scrolling to get to the bottom of the form. the obvious solution is to break your form into multiple pages, but there is no easy way to do this. there do exist two proposed solutions to this, the cck wizard module and a drupal handbook entry. however, the well-intentioned cck wizard module doesn't seem to work, and the example code in the drupal handbook becomes tedious to repeat for each content type. to fill the void, i bring you cck witch
cck witch is based on the same premise as the handbook entry : the most natural way to divide a cck form into pages is to use field groups. from there, however, cck witch diverges, taking a relatively lazy, yet effective approach to the problem of multi page forms: on every page we render the entire form, but then simply hide the fields and errors that do not belong to the current step. it also offers an additional feature : when the form is complete and the node is rendered, an individual edit link is provided for each step - allowing the user to update the information only for a particular page in the form, without having to step through the entire wizard again.
if you've now read enough to be curious to see the goods, then please, be my guest and skip straight to the live demo.
using the term "content management system" to describe the drupal cms understates it's full potential. i prefer to consider drupal a web-application development-system, particularly suitable for content-heavy projects.
what are the fantastic four?
drupal's application development potential is provided in large-part by a set of "core" modules that dovetail to provide an application platform that other modules and applications build on. these modules have become a de-facto standard: drupal's fantastic four. our superheros are cck, views, panels and cck field types and widgets. if you are considering using drupal to build a website of any sophistication, you can't overlook these.
previously, we discussed implementing all of the node hooks for CCK content types except
hook_access. unfortunately, there is no
access op for
hook_nodeapi. adding this to drupal core is the topic of much discussion on drupal.org. so far a resolution to the issue has failed to be included in drupal 5 and drupal 6, and is now on deck for consideration in drupal 7.
this is a complicated issue, and the experts are debating with good cause. in the meantime though, if you need to move on, here's what you can do.
a common path followed by advanced drupal developers using cck is the following
- create a content type using cck
- create a supporting custom module to handle advanced customizations. typically, the module is given the same name as the content type
in this custom module, developers then attempt to implement standard drupal hooks like
hook_submit. much confusion then arises as to why the drupal hook is not firing for the cck content type.
the reason is the following.
hook_view only fire for the module that owns the content type. for cck content types, the module that owns the content type is
content (e.g. cck) not your supporting custom module. therefore, drupal leaves your supporting custom module totally out of the loop!