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.

reuse drupal fields

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.

media_1392150946256.png

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.

Author

  • Steve Burge

    Steve is the founder of OSTraining. Originally from the UK, he now lives in Sarasota in the USA. Steve's work straddles the line between teaching and web development.

0 0 votes
Article Rating
Subscribe
Notify of
14 Comments
Oldest
Newest
Inline Feedbacks
View all comments
pepperstreet
10 years ago

Good read… Comprehensive article! For sure an underrated topic and drupal feature. Glad, to find some infos and other opinions for clarification/confirmation. Valuable infos about “Views” capabilities.

Shared! 😉

999csharp
10 years ago

For me, as a beginner to Drupal, I will alway choose to Add new field. I wouldn’t even want to imagine what it would be like if I ran into issue later on that cannot be reversed if I had copied an existing field. Sorry.

Nancy W.
Nancy W.
10 years ago

First, each field creates TWO tables if you use revisioning. Then, if you delete a field that contains data, that deleted data will be put into another new table.
This all goes back to the age-old adage “Know how you will use the data.” I find it to be rather convenient to have the bundle type included in the field data tables because that can make coding easier (eliminating a JOIN on node) if you have get to things through the field.
On the other hand, you may have images, for example, in several content types, but the settings are different, such as the cardinality.

Greg Boggs
Greg Boggs
10 years ago

I’ve taken the initiative to update the Drupal documentation for field reuse to more accurately convey the advantages of field reuse which were previously only mentioned as comments on the page.

steve
steve
10 years ago
Reply to  Greg Boggs

Thanks Greg. For people reading this later, this page has Greg’s changes: [url=https://drupal.org/node/1577260]https://drupal.org/node/157…[/url]
In short, Greg offered more of the pros rather than just the cons.
Amongst other changes, this line was cut out … “It is recommended to create new fields, rather than reusing existing ones, unless you have a clear reason to do so”.

Dave Hansen-Lange
Dave Hansen-Lange
10 years ago

“From a performance point of view, you don’t want to have a gazillion

fields on your Drupal site. If a content type (or other entity) has a

lot of fields, saving the content will result in a lot of database

writes that might take time. Also, the field configuration itself might

take a lot of memory to load from the cache (and that is done pretty

often).”
This is talking about the total number of fields per bundle, regardless of whether those fields are shared or not. So it’s not really relevant to this discussion.
“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;”
The performance impact of a few extra rows in `field_config` table (or not) is insignificant.
“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.”
This is another performance issue that occurs on any bundle with many fields regardless of whether they are shared. So again, not really relevant here.

Dave Hansen-Lange
Dave Hansen-Lange
10 years ago

I think the best way to approach the problem is to disregard all of the technical stuff and just think about it from a content point-of-view. Are the two things the same? If yes, use a shared field; if not, don’t. Common examples:

– Title (I’m a fan of title_field)

– Body

– Creation Date (we commonly use a separate date field for this to display publicly, leaving $node->created for administrative use).

– Teaser thumbnail

– Search Result Extract

headfirst
10 years ago

I’m with Dave on this one – your decision should be based on whether the content has the same meaning and should have the same configuration across multiple entity types.

Heitor Althmann
Heitor Althmann
9 years ago

Excellent article! Thanks for the work and research on this. Saved me a lot of time on making decisions about this issue 🙂

Danny
Danny
9 years ago

If you use Features for deployment, god help you if you reuse fields across entity types…

Shena Garg
Shena Garg
9 years ago

An excellent post on a comparatively less-discussed topic in Drupal community. I see the merit in either case; however, I would rather go what Nancy has advised in her comment!

Kristen Pol
Kristen Pol
9 years ago

One thing to note is that if you have a lot of fields then the token list gets out of control and you have to add some custom code to limit the token depth or use something like Token Tweaks. Typically, I will reuse a field if it has pretty much the same meaning (and has same configuration) across the content types / entities. I try to reuse fields if possible (given these constraints). Features hasn’t been an issue when using 2.x.

steve
steve
9 years ago
Reply to  Kristen Pol

What an interesting comment, thanks Kristen
I hadn’t thought about the Token issue before, not having built a site with enough fields to cause the issue.
It’s funny how hard it is to forsee these problems until you’ve done the right kind of real site-builds.

erata61
erata61
8 years ago

thanks for this good article.

14
0
Would love your thoughts, please comment.x
()
x