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.
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.
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.
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.
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.
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.
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”.
“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
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
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.
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)
– 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
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.
Excellent article! Thanks for the work and research on this. Saved me a lot of time on making decisions about this issue 🙂
If you use Features for deployment, god help you if you reuse fields across entity types…
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!
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.
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.
thanks for this good article.