This is an experimental module which allows you to inherit fields from one content type to another.

For example, an "article" might be a complex base content type with 40 CCK fields. To create a special case, I've found myself adding collapsed fieldsets to the article form. This causes problems with form validation though, because most of the time, I expect these fields to be completely empty, so making them required isn't an option--but in the special case, they are required and annoy users by giving no feedback. This method also detracts from usability by cluttering the form.

A real world use case: On, we aggregate content via RSS. When a new item arrives, we add it to a database as an item of CCK type "rss_article." This type shares the same couple dozen fields as our main article type, but since it has a handful more, to avoid adding complexity to the main article type, we have to create a new type and clone the fields (rather than sharing all two dozen of them). With this module, we can simply set the rss_article type to extend the article type. Much faster to develop (one click to set the parent content type), and much easier to maintain. No schema changes--everything just works. What's more, if all "article" data is stored in some child content type that extends the base type, views can mix these types with impunity. Further, Drupal will display node-article.tpl.php for a node of type rss_article if node-rss_article.tpl.php isn't available.

The basic feature of inherit is recursion in hook_nodeapi and hook_form_alter. At present, there are only a few ways to integrate the node creation forms (put the parent fields in a fieldset, put the child fields in a fieldset, or merge the forms by weight). Because views is agnostic to content types (it only really cares about what tables to use, what the field name is, and how to join to it), inherit works with views right out of the box. Inherit implements hook_views_data_alter only to add child node types to their parents' fields.

All the scary stuff in inherit has to do with tricking CCK. This would be mostly solved if CCK implemented a hook to bind fields to a content type (at present it will only read this data from the database). Also, CCK caches field structures as content:{nid}:{vid} rather than content:{content_type}:{nid}:{vid}. This is an issue because CCK ends up storing rows in two tables--one for the parent, one for the child, but both with the same nid and vid so the cache collides. This caching issue is the biggest performance drain, but there is a way to maintain a separate cache and switch out the CCK cache before it recurses hook_nodeapi. inherit.module is commented everywhere that would benefit from a change to CCK. But: it works anyways.

There are several performance improvements in the pipeline, but inherit is pretty fast as it is--it only recurses nodeapi for CCK and for inherit itself (chaining inheritance, e.g, super_special_article > special_article > article). I have not yet benchmarked inherit against other methods.

Please don't install this anywhere important unless you really know what you're doing.

Project Information

  • Maintenance status: Unknown
  • Development status: Unknown
  • Module categories: Content
  • Downloads: 1,116
  • Last modified: November 27, 2014
  • shield alertThis project is not covered by the security advisory policy.
    It may have publicly disclosed vulnerabilities. Use at your own risk!