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.
It’s really interesting that clearing out the menu_links table and reinstalling the Admin Bar module did the trick. Menu corruption is such a common headache when moving from D7 to Backdrop,...
Restore Newsletter Subscriptions from a Dev Website
In my last comment, I described a way to restore newsletter subscriptions from a database backup. The method involved directly editing...
Posted11 hours 22 min ago by Olaf Grabienski (Olafski) on:
I am considering migrating my drupal 7 website to backdrop.
Hi @seamus, I would like to offer my professional services for migration to BackdropCMS.
Please connect If...
Posted1 day 6 hours ago by Deep Vyas (deepvyas) on:
Restore Newsletter Subscriptions from a Database Backup
One of my websites was affected by the Simplenews issue, and there were many incorrectly disabled newsletter subscriptions of '...
Posted1 day 8 hours ago by Olaf Grabienski (Olafski) on:
This is the report about the recently discovered bug: https://github.com/backdrop-contrib/simplenews/issues/83.
First, how do you know if your site is affected? In other words: Are there...
Posted2 days 7 hours ago by Olaf Grabienski (Olafski) on:
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.