Reply to comment

At work we've been trying to figure out better ways to deal with CCK fields on our sites. The sites we build are very custom build, with much code relying heavily on specific CCK fields.

So far, content type and field setup has been a manual process, with all the problems that brings.

We've dabbled a bit with content_copy, but as it's not able to update the field settings on an existing type, it's of no use past initial setup.

The features module seemed promising for a while, but it also seems to have problems with updating types, and it doesn't fit very well into our development environment.

Some have suggested that it would be nice if CCK fields could be exportables, but the truth of the matter is that fields are fundamentally unsuitable as exportables. Changing a single setting can force CCK to move large amounts of data between tables, so that's not something you'd want to happen because you flushed the cache.

Another thing is that field settings is split in two: global database storage settings, and instance specific display and widget settings.

The instance settings are most appropriately put into modules that define the content types, and which include all of the content type specific code and exportables. Or a module that collects the parts of a 'feature'.

However, there might be multiple modules using the same field. For instance, 'field_image', which is a simple image field, might have difference displays, widget and custom code for the node types story and product. So it's better to put field global settings in a common site specific module.

These thought spurred me to think up a concept I call the Field Gatekeeper pattern. The basic concept is that one or more modules acts as gatekeepers for global field settings, while 'field user' modules define the display and widget settings which get merged with the global settings when they request that they're attached to a content type.

I've created a module which is called, unimaginatively, field_gatekeeper, which I'm trying out on my latest project. It defines a hooks for both gateway modules and field user modules to implement, which allows for easy definition of fields. It also defines drush commands to dump fields from the database, in a format that's suited to copying directly into those hooks, and a command to update all fields used by a module.

If the concept shows worthy, it'll probably end up as the way we do things. And if it shows enough promise, it might end up on drupal.org.