[policy] Bundle / field name / view mode theme suggestions can conflict

Cross-posting from #2808481-62: Introduce generic entity template with standard preprocess and theme suggestions

So.. how do we get to the point of making a descision here? I think we have all the options laid out:

a) No prefixes, like on existing theme suggestions => status quo, with all the advantages (shorter) and disadvantages (not self-explaining, possible conflicts)
b) Full prefixes, bundle-, view-mode-, .. (longer but somewhat self-explaining and no risk of conflicts)
c) shortened prefixes, b-, v-, (shorter, not really self-explaining anymore unless you know the abbreviations, no conflicts)

Personally I'm fine with a or b, I really don't care. Not sure if c) isn't actually harder to understand than a) and whether it is worth doing that just to avoid conflicts.

So the beef I have with b) or c) (or in other words with the reasoning behind this issue) - regardless of the actual experience for themers - is that it would be introducing a one-off for entity templates. There are, however, numerous template suggestions which can conflict, and which currently suffer from the same issue. So not only would we be introducing an inconcistency between current entity templates (node, user, ...) and the new generic entity template - which I think is acceptable as the former can be seen as the deprecated BC-layer of the latter - but we would be introducing an inconcistency between the generic entity template and every other template.

Other conflicts we currently have:

• block__$provider / block__$base_plugin_id / block__$derivative_plugin_id / block__$id
• field__$field_type / field__$field_name
• field__$entity_type_id__$bundle / field__$entity_type_id__$field_name

And this is just in core. I didn't check but I am sure that there are more in the world of other uber-generic modules like Panels / Display Suite / Layout Plugin / Search API / ...

However those should be changed by adding new suggestions for those as well and deprecate the old suggestions.

The theming community in #twig (slack) overall (though it was a non-representative poll) was for long and descriptive names by a large margin.

Only a few for the shortened names and only another few for keeping the old convention with conflicts.

The theming community in #twig (slack) overall (though it was a non-representative poll) was for long and descriptive names by a large margin.

This was only asked once and getting a few people's opinion who were in that room really doesn't indicate a "large margin".

---

That being said, I am in favor of explicitly long suggestions, only if template discovery was altered to also allow these suggestions to be broken up into folders (as was semi-depicted in #2808481-56: Introduce generic entity template with standard preprocess and theme suggestions).

---

After thinking about the above (folder) comment a bit more, I think the easiest solution would be to allow a 1:1 mapping of __ to a directory separator (/):

node__bundle_foo__view_mode_bar__1234

Would become:

templates/node/bundle-foo/view-mode-bar/1234.html.twig

And, if not found, would search for the original long ass filename (for BC and themers who "like" these.......):

templates/node--bundle-foo--view-mode-bar--1234.html.twig

This gives the ability to dramatically reduce the length of a filename from node--bundle-foo--view-mode-bar--1234.html.twig to simply 1234.html.twig.

Moving forward, I think simply adding directory detection is a good enough compromise to support these ever growing theme hook suggestions.

I would definitely like to avoid using directories as a way to shorten file names. Being able to place templates in directories of my choosing is important to me when working on a theme.

My preferences would be as follows:

Full prefixes but long file names > Abbreviated prefixes and slightly longer file names > Current system where conflicts happen because of lack of prefixes > Directory structure required for template suggestions

Being able to place templates in directories of my choosing is important to me when working on a theme.

Why? This sounds more like personal preference than a logical dispute. We get it, you don't like directories or rather you like naming them arbitrarily. That's fine.

My suggestion above still allows filenames to be 10 miles long if you really want them to be and place them wherever you want.

If this kind of directory support isn't included, however, then y'all are forcing us to use these long winded names.

That's unacceptable.

This simply gives very complex themes (that have many, many templates) the ability to have a folder structure that makes sense.

It's very similar to PHP's PSR autoloading, if you will.

I wouldn't mind if directories are an option if people want to make use of that. If I can have long file names and others can have short file names with directories, that would be cool.

Organizing templates by component is useful. Often it takes multiple templates of different types to get all the templates for a particular component.

as much as I dislike the folder idea, it is consistent with the rest of drupal 8.

If I want to make a new entity type I have to put it in an Entity folder in my module.

Having to put entity templates in an Entity folder in my module or theme seems like the most consistent / least confusing method.

It's a pain in the ass, especially if you're used to putting theme files in your own folder structures (I am)... but it was also a pain in the ass for module developers to have to start putting files into folders as well, and we got over it :P

Marked #2881195: Duplicate template suggestions as duplicate.

Triaged as part of the Bug Smash Initiative.

Closing as duplicate of #1367354: The list of theme hook suggestions for "field" is incorrectly ordered and has namespacing collisions.

If that is wrong, please reopen by setting to 'Active' and add a comment explaining why.

4 years later...

I think this is not a duplicate, but the meta issue of that or maybe better, a policy issue on whether or not we should do prefixes, it also references the entity issue that was essentially blocked on this.

I did make a specific proposal with a few questions in #2752443: Incorrect order and duplicate theme hook suggestions and would appreciate feedback there, but I think this is still an issue that should have its own resolution on whether or not we use prefixes or not, and if all entries should use prefixes or only less common ones, likely guided by the specific examples in the field issue.

I meant to link to #1367354: The list of theme hook suggestions for "field" is incorrectly ordered and has namespacing collisions I think.