I need to create 10 content types which, apart from their specific fields, will have 4 common fields (e.g name, surname, email, age).

Since I'm using Features I could create the first and copy paste the definitions to the other 9 content types. The problem though is that if the specifications ever change and I need to add or change any of those common fields I'll still need to do repetitive work.

How should I solve this? Is there a module which allows the construction of a "base content type" from which other content types can inherit fields? Or should I just reuse fields?

The following modules don't seem to be active for D7:

  • Bundle Inherit seems pretty decent, there hasn't been any recent activity but there's a stable version (albeit alpha). Have you tried it? – Alex Weber Apr 15 '12 at 4:14

Short answer: I would simple go with sharing these four fields across the content types that you have. This is boring and repetitive work, but I'm not aware of a well-established way to do it otherwise, so this is the safest bet in my opinion. This gained a bad reputation in D6 as it caused performance problems, but in D7 there is no difference.

Longer answer: I did try copy/pasting of features code at one point, it works, but is quite messy and carries a large risk of "getting it wrong" as it's not documented nor entirely obvious what code needs to be updated.

As Joe Beuckman suggests, creating a custom entity is one way of solving this as well. If you add your shared data columns as entity "properties" instead of fields, they will be shared across all bundles of that entity type. A core example of this is the "title" property on nodes. A lot of modules today work in a entity agnostic fashion, but it's important however to note that the entity API was far from finished in D7. There is no general way for example to handle "entity access" which may or may not be a problem.

Also, on the last approach, you may also want to take a look at the Entity Construction Kit (ECK) module. I haven't used it myself yet, but I believe it could be helpful in creating new entities.

  • Note that I've defined my "base page" and then I made heavy use of drupal.org/project/bundle_copy to copy/paste that page and extend with extra fields. Worked fairly well. – cherouvim Jun 29 '12 at 8:57

A non-ideal option, and not truly a base content type, is to use the Field Collection module.

You can create one or more field collections for your common fields, and then attach the collection(s) to your content types.

An upside of this is that you can have a set of collections that don't all have to be added to each content type, but still have common groups.

The biggest downside with them is only the collection itself appears on Manage Display form for the content type, so you have less UI control over how/where fields get rendered. You have to manipulate things with a template_preprocess_node or hook_node_view, which can get messy.


For such situations I have used following solution:

  1. Create base content type (Ex: Question) and add common fields.
  2. Create sub content types (Ex: QuestionText, QuestionMath, QuestionOptions, etc) and add there only specific fields.
  3. Create entity reference from base content type to sub content type (Ex: Question->QuestionMath).

Additional notes on such approach:

  • It plays very well with views.
  • You can reference base content type from other content types (so there is no need to change all reference settings in other content types when adding/changing/deleting sub content type).
  • "The problem though is that if the specifications ever change and I need to add or change any of those common fields I'll still need to do repetitive work." -- You need to change only base content type: one change, applies to all.
  • More burden on node create, update, delete side to ensure data integrity.
  • Biggest downside of such approach is add/edit forms.
  • You get two titles (one for base content type and one for sub content type). Use base content type. Sub content type's title becomes irrelevant (and may be a constant).
  • Display nodes in Panels:
    1. Enable Node Template.
    2. Create a Variant for base content type.
    3. Add base content type fields.
    4. Create a node context/relationship for sub content type.
    5. Create a minipanel for each sub content type.
    6. Add sub content type fields into the minipanel.
    7. Refer to sub content type fields through context provided by base content type.
    8. Add all sub content type minipanels into base content type Variant.
    9. For all sub content type panes add Visibility rule: node: type = respective sub content type. So only one sub content type minipanel is visible at a time.
    10. If you need to change layout for base content type, it applies for all.

EDIT: See Drupal Content SubTyping to get overview of different methods and modules for SubTyping.


What you are looking for is exactly Entities in Drupal 7. You can create an entity with your common fields, then create fieldable bundles for each of your subtypes.

  • 2
    Thanks but will an Entity bypass the whole node infrastructure of Drupal which may contain versioning, localisation etc? I'd like to stay within the "content type" paradigm of D7. – cherouvim Apr 6 '12 at 15:51
  • In Drupal 7, nodes, users, and taxonomy terms are all entities. The node infrastructure is all based on the entity API. – kiamlaluno Apr 10 '12 at 14:08
  • The Entity API lets you tell Drupal about a database table in an abstract way. It doesn't solve the problem of wanting to re-use fields with nodes in a structured way. – paul-m Apr 10 '12 at 17:24

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.