4

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
8
+25

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.

| improve this answer | |
  • 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
3

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.

| improve this answer | |
-1

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.

| improve this answer | |
  • 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.