Welcome to Backdrop CMS. There are different schools of thought on this topic. Some create new fields for each content type.
Many like myself have what I consider to be a more pragmatic view:
If the purpose of the field is the same then there is a strong benefit to re-use the field as it will then be much easier to create a View across multiple content types. However, if they are a different purpose, then it makes sense to create new so the field machine name can reflect the purpose.
This is often a matter of opinion, and I have given my opinion (that is shared by others, but not all in the community) with my reason for doing so.
From the "dev" point of view, keep in mind that fields have two types of settings: global settings and instance settings. Instance settings are those that apply only to a specific content type (for example whether the field is required). Global settings apply to a field in ALL content types (for example, cardinality).
Change a global setting for a field will change it in ALL content types. That should help you decide whether you want to use the same or different fields in different content types. If the global settings will be the same everywhere, then use the same field. If not, go for different fields.
When I was a "newbie" in Drupal I often inadvertently changed a global setting for a field (e.g. the cardinality number), creating a lot of issues since I didn't want to change that for every content type. This is not uncommon.
On the surface this is a fantastic idea. It does require significant costs in time and money. I've found that the models are possibly more knowledgeable about Drupal 7 and Backdrop than Drupal...
With the custom search, that sounds like a bug as the module doesn't have a dependency on language. You could though try enabling that module just to get past the update.
There is an...
Posted7 hours 49 min ago by Martin Price | System Horizons Ltd (yorkshirepudding) on:
Block D is from 0900 - 1200 UTC on 2025-04-04. So far, we have a session on privacy and cookies but nothing else. Is there something you would like to talk about? This time block is not great...
Posted8 hours 10 min ago by Martin Price | System Horizons Ltd (yorkshirepudding) on:
Here is an interesting perspective from a site owner that explains why people move to BackdropCMS https://backdropcms.org/showcase/pgsuper-open-source-girder-bridge-design-software#testimony
If you have a "new project" being created from scratch, that isn't already in Drupal, and there is no need to migrate, some of my comments in this post may not be relevant. As an Administrator...
Comments
Hi @rafke
Welcome to Backdrop CMS. There are different schools of thought on this topic. Some create new fields for each content type.
Many like myself have what I consider to be a more pragmatic view:
If the purpose of the field is the same then there is a strong benefit to re-use the field as it will then be much easier to create a View across multiple content types. However, if they are a different purpose, then it makes sense to create new so the field machine name can reflect the purpose.
This is often a matter of opinion, and I have given my opinion (that is shared by others, but not all in the community) with my reason for doing so.
From the "dev" point of view, keep in mind that fields have two types of settings: global settings and instance settings. Instance settings are those that apply only to a specific content type (for example whether the field is required). Global settings apply to a field in ALL content types (for example, cardinality).
Change a global setting for a field will change it in ALL content types. That should help you decide whether you want to use the same or different fields in different content types. If the global settings will be the same everywhere, then use the same field. If not, go for different fields.
When I was a "newbie" in Drupal I often inadvertently changed a global setting for a field (e.g. the cardinality number), creating a lot of issues since I didn't want to change that for every content type. This is not uncommon.