Add content type name as a part of a new field name suggestion

[alanmels]

Description of the need

When adding a new field to a content type, it automatically generates the field's machine name by using its title prefixed with field_:

In order to distinguish similar fields and to avoid mess in database, we always manually add the content type's name:

Proposed solution

I believe if the prefix consisted of field_ and content type's machine name like so field_listing_, it would only increase the usability and comfort of developing.

[argiepiano]

For me, a drawback of doing this is the fact that Backdrop lets users add the same field to different content types. This is a common practice. Having the content type prefix would confuse things.

[stpaultim]

I have the same practice, which I adopted very early on in my Drupal career. This feature would be a nice thing for me. I'm not sure I see any downside to doing this, but am curious what others think.

This might encourage a "best practice" (at least in my opinion) that many new site architects don't think of.

I certainly don't feel strongly about this issue, but I would support this change pending feedback from others.

For me, a drawback of doing this is the fact that Backdrop lets users add the same field to different content types.

I don't think this is an issue, because it only effects NEW fields. Adding an existing field is a different option, so I'm not sure how this would confuse things at all.

[argiepiano]

I don't think this is an issue, because it only effects NEW fields. Adding an existing field is a different option, so I'm not sure how this would confuse things at all.

It would confuse things because when you add an existing field to another content type, the machine name of that field would contain the prefix of the first content type it was added to.

[alanmels]

I see @argiepiano's point and had two immediate thoughts on this:

1. If a field carried the content type's name originally it was created for, even if used on other content types, it would not effect functionality. In some cases knowing how the field was created originally might be even useful.
2. I don't want to add another complexity layer, however we might come up with two types of fields: one generic with simpler machine names, and the other - content type specific carrying everywhere its name.

Just as @stpaultim I have no strong opinion on this, so let's just see what other Backdrop users feel about this.

[olafgrabienski]

In most cases, I also mention the content type in the machine name of a field, and I like the idea. But I also see the point of shared fields where in my opinion it doesn't make sense to add a content type prefix.

Another drawback of the prefix: the machine name length is limited to 32 characters; with another prefix many of these characters are lost:

• field_ - 26 characters remain
• field_listing_ - only 18 characters remain

Also, some languages like German use often long terms which lead to automatic generated prefixes like field_veranstaltungsort_ (instead of field_venue_), which doesn't let enough space for the actual field name.

That said, I like the idea to give 'best practice' information regarding field machine names. Maybe as help text?

[kiamlaluno]

I think the machine-name lenght-limit and the fact fields can be shared between content type are two reasons to avoid to automatically add the content type machine name in the field machine name.
I would rather prefer to have a setting to enable this behavior, and have it disabled by default.

Yet, the described behavior does not seem to fix any issue and the content type machine name can be still manually added to the field name. It is not like the field_ prefix which is added to avoid name conflicts between programmatically added fields and fields added from the UI.