It is possible to use the same field on more than one entity - for example, an image field can be used on both users and a node type. You do this by using the row add existing field in the list of fields.

When reusing fields, only parts of the configuration, such as help text, may be changed for each node type or entity. Others must be the same for all entities where the field is used, such as number of values to store.

Reasons Not to Reuse Fields

The main reasons to use a new field are you get increased flexibility for field configuration, and shared fields can make it more difficult to export selected parts of the configuration on your site. (See the section on exporting configuration in Appendix 1 for more information about why configuration export is useful.)

Reasons to Reuse Fields

Reusing fields not only makes Drupal run faster, it also makes your project easier to maintain. There are times to use a separate field. If you need a field on one content type to be single value instead of multi-value, then you'll want to add a new field. When an image field is shared between content types with an easy to remember name like field_hero_image, your custom code is easier to write and maintain, your views are easier to build and you have fewer UI changes to make if you have to update a field configuration.

Note: As of version 2.x, Features now supports exporting field bases separately from field instances so sharing fields with features is no longer an issue.

Comments

rafamd’s picture

Some have arrived to the conclusion that having too many fields can hurt performance big time...

Itangalo’s picture

The points made in the linked post are good – I've updated the tip. Thanks!

sarojg’s picture

"TIP: From a performance point of view, you don't want to have a gazillion fields."

Is there any reference for what is an excessive number of fields? As a newbie, I have no scale for this.

Andre-B’s picture

another tip: having a lots of fields will cause problems with many different modules as well. The Token GUI for instance will make you browser lag for minutes if you try to edit url aliases for example. This behavior can be seen on all the pages where token will be loaded and displayed (including devel - dpm() etc.)

There is no performance benefit in splitting this data across multiple table when using InnoDB (MyISAM is different because of table locking). So - if you know you will have a lot of similar content types with similar fields (which configurations will be also the same, maybe differ in labeling only) reuse your fields!

It might also ease up template creation because of similar node attributes.

follow me on Twitter: https://twitter.com/ABaumeier

bkline’s picture

There are use cases in which field re-use is preferable. One of these is the need to sort nodes of different content types in a view. For example, a site with content types for general event, scientific event, public event, holiday, announcement (with deadline) may have a requirement for a pane which displays the next three upcoming events or deadlines or holidays. Drupal views have reasonably sophisticated support for grouping and combining filtering conditions, but the support for sorting is less capable of handling complexity. If the date fields to be used for sorting the nodes for these content types are not shared you will have to create separate sort rules, which will mean that the content type whose rule comes first will always sort last (because the nodes of the other content types won't have a value for that rule's field, so an ascending sort puts them at the top of the list). If the next five events/deadlines/holidays are:

  1. Deadline April 15
  2. General event April 16
  3. Deadline April 17
  4. Scientific event April 18
  5. Public event April 19

then the nodes for April 15-17 should show up in the pane. But if the rule for the deadline field is first in the sorting configuration the other nodes will push both of the deadline nodes off the displayed list altogether. Supposing the order of the sorting rules to be

  1. date field for deadline
  2. date field for holiday
  3. date field for scientific event
  4. date field for general event
  5. date field for public event

the pane will show:

  • Public event April 19
  • General event April 16
  • Scientific event April 18

If all of these content types use a shared field for the date used for sorting then the requirement can be met.

pinkonomy’s picture

What about to upgrade to Drupal 8?
I think Drupal 8 won't support sharing fields.
Would this make upgrade hard to do?

dqd’s picture

please verify with links (sources)

The Change Notice from that issue you probably refer to says

Fields are now bound to a specific entity type (they are still shareable between bundles).

Thanks to all for all the contributions and efforts here and everywhere else on Drupal.org!
You all rock! ~ dqd (formerly diqidoq)

askibinski’s picture

Drupal 8 changelog:
https://www.drupal.org/node/2078765

So, in Drupal 8, you can still share fields between various node types, but you can't share a field between a user and a node (for example).

Albert Skibinski - Homepage

eloivaque’s picture

Field Config cardinality
in case anyone is interested.

Example: field_dates, is posible to be multiple field on article content type, and reuse with single field on page content type, and the information is saved on same database table.

Botafoc.cat -> Drupal 8 base distribution. Focused on making a base distribution of drupal. The idea is compile the typical modules and configurations that is in vast majory sites using drupal.

bfuzze9898’s picture

Is it possible to enable reusable fields for custom entities (non-node, generate:entity:content)?