Separate entry types from sections

[brandonkelly]

Sometimes the same entry type is needed across multiple sections. For example a single site could have multiple blogs, each needing the same custom fields.

For those cases, it might be nice if entry types were created separately from sections, and sections simply selected which entry type(s) should be available to them.

[brandonkelly]

Another advantage of this is it would pave the way to moving entries between sections (#946), because it would be easy to know which other sections support the same entry type.

[Mosnar]

I've honestly never found myself needing this feature; however, I do see the technical appeal, and it definitely feels like a step in the right direction, as long as the workflow for assigning entry types to sections isn't degraded by an additional step.

More often than this, I find myself wanting to reuse field layouts & tabs across different elements; however, I definitely wouldn't want to see Craft become like Jira where it's layered in a ridiculous amount of abstraction and overhead when it comes to fields.

[khalwat]

Very much support this.

[brandonkelly]

@Mosnar Yeah in general we are planning to make administrative setup more direct, with inline field creation (#822), etc.

[ghost]

Great, but a bit of flexibility should be added, so that requirements like 'we need a different instruction/placeholder/default value on that field' , 'we can't use this field/blocktype here' etc do not force you to create a new entry type.

Like @Mosnar , what we missed more is the ability to compose an entry type by reusing (and adjusting, like above) predefined field groups.

[stenvdb]

Something like this would also be very handy in commerce! I've run into situations where I need to create a number of product types (based on their unique variant fields), but then I'm copy pasting the product fields for all product types.

[mmikkel]

I'd love this.

Not to steer this issue off topic, but this is actually how I've always wanted Matrix fields to work too, where Block Types would be created separately from Matrix fields, and the individual Matrix field would simply be a "collection" of Block Types to make available in that particular field (sort of how Field Layouts and Fields work).

[brandonkelly]

@mmikkel That’s a really good point. Sortof an alternate approach to #3462, where you’d have one master Matrix field, and each block type would define the conditions that determine when they should be available.

[mmikkel]

@brandonkelly For sure, I think something like #3462 would be a different approach to the same problem and would also be a nice solution.

I think that conceptually, it's possible to think about both Entry Types and Block Types as basically collections of fields ("field layouts", as it were... :P). It'd certainly be awesome to have more flexibility and freedom in how and where those field collections are applied (or, made available) throughout a site build.

[brandonkelly]

I’ve gone down this train of thought before… rather than making Entry Types be a standalone thing, we could go a step further and make a new Content Types concept, which are just named field layouts, that could be selected by any element type that currently has field layouts.

The tricky part is that we want to start allowing element types to define custom UI components that can be included alongside custom fields in Craft 4. For example:

• When editing an entry field layout, you should be able to choose where the Title field ends up, if it has one at all. (Make the "Title" field behave like all other fields in the Admin UI #3953)
• When editing the user field layout, you should be able to choose where the Username, First Name, Last Name, Photo, Email, etc., fields go (or at least groupings of those fields).

That wouldn’t be possible if field layouts are defined centrally.

Perhaps—and maybe this is what you were getting at—instead of defining complete field layouts centrally, we could just make it possible to define “sub-layouts”, which could become available as additional components in field layout designers.

If we did that, there wouldn’t be as much need for giving entry types a many-to-many relationship with sections, though I still wouldn’t be against it.