Should I Re-use Existing Drupal Fields?

Sometimes we’re able to give really clear advice: “Do this!” or “Don’t do that!”

This is not going to be one of those blog posts.

Drupal gives you the ability to re-use fields. If you have an “Image” field, you could choose to use that same field on every content type on your site. However, it’s not always clear whether re-using fields is a good idea. Sometimes it is, sometimes it isn’t.

Here’s an overview of the advantages and disadvantages to consider before re-using Drupal fields.

General advice on re-using fields

You can choose the “Re-use existing field” feature whenever you go to “Structure”, then “Content types” and click “Manage fields” for a content type.

The Drupal.org documentation use to officially recommend that you do not re-use fields:

It is recommended to create new fields, rather than reusing existing ones, unless you have a clear reason to do so.

However, that advice has become more nuanced in recent years, and Drupal officially says that are both advantages and disadvantages.

The Drupal Field UI documentation has a detailed section called “Reusing Fields”:

There are two main reasons for reusing fields. First, reusing fields can save you time over defining new fields. Second, reusing fields also allow you to display, filter, group, and sort content together by field across content types. For example, the contributed Views module allows you to create lists and tables of content. So if you use the same field on multiple content types, you can create a View containing all of those content types together displaying that field, sorted by that field, and/or filtered by that field. There is one main reason to not reuse a field: different permissions. For example, you may need different user roles to have different levels of access to a field, depending on the content type to which it has been added. This can be difficult if you reuse a field.

Advantage: re-using fields can make your simpler

Yes, there can be a speed boost, but the time-savings are very small. A more compelling advantage is that re-using fields can sometimes make site administration simpler. Web Initiative sum this up nicely:

Reuse of fields can also reduce the system’s complexity. Instead of creating and maintaining 10 different fields, Drupal admins maintain only two fields and their documentation. Database administrators only need to improve performance of two extra tables. KISS is always a good principle.

It definitely would be easier to apply permissions, setting and design elements to one re-used field rather than 10 unique fields.

Advantage: some content works well with re-used fields

Back to the Drupal Field UI documentation again:

reusing fields also allows you to display, filter, group, and sort content together by field across content types. For example, the contributed Views module allows you to create lists and tables of content. So if you use the same field on multiple content types, you can create a View containing all of those content types together displaying that field, sorted by that field, and/or filtered by that field.

One comment writer on the Drupal.org documentation makes the same point about Views. They point out that Views can combe content in sophisticated ways. So, if you have multiple different content types, with different date fields, then Views can combine them into a single view. However, they also point out that Views isn’t so sophisticated with sorting. So, if you have multiple different content types, with different date fields, then Views will struggle to sort the content on all those different date fields.

Disadvantage: Re-used fields are inflexible

Brandon Williams on Twitter summed this up nicely: 

at first it’s a good idea, but give it a few weeks, reqs change, you end up creating separate ones anyway

To a large degree, if you choose re-used fields, you are limiting the changes you can easily make to your data later. It is also much more time-consuming to make updates because you need to edit each field individually.

Disadvantage: Re-used fields make data harder to export or migrate

Re-using fields could become an issue when you need to export your data or when you need to migrate to a new version of Drupal or another platform.

Each Drupal field has it’s own database table, as shown below. Extracting that data can be tough. The Features module (the most common way to export Drupal data) struggled for a long time with shared fields, although current versions can handle them more effectively.

This advice is similar to our thoughts on using multi-sites. Whenever you start to build dependencies between codebases or database tables, you add complexity to your site.

Advantage or disadvantage? Performance

The Drupal documentation outlines one possible benefit of re-using fields:

Reusing fields not only makes Drupal run faster, it also makes your project easier to maintain.

This thread on Stack Overflow has a very relevant discusion on performance. It includes this comment:

A real problem however is the number of fields you have. Because currently in Drupal 7, the complete field configuration of all fields, no matter if they’re loaded or not, is fetched from the cache on every single request. I’ve seen sites with 250+ fields, where loading and unserializing the field configuration takes 13MB+ memory.”

So, re-using fields could possibly give small performance improvements by letting us have a lower total number of fields.

However, those small improvements may lost elsewhere. This from Web Initiative again:

[fields] extra complexity to a Drupal system. When creating a new field, the field’s definition is added to the field class table and the field’s configuration is added to the field instance table; meanwhile, a new table is added to the Drupal database to store the field data. Database tables add complexity to the system. In addition, queries of nodes will incur JOINexpressions of tables to field data. Multiple JOINs will impact database performance since MySQL responds poorly to queries with multiple JOINs of tables if not properly configured.

Summary

Sorry that we don’t have an easy answer to this question. This is a question where you will benefit from reading around the issue and understanding the pros and cons. If you’re doing a real site build, it will be worth constructing the site in a test environment to learn more about how these pros and cons impact your site’s needs.