Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Separate entry types from sections #4724

Open
brandonkelly opened this issue Aug 7, 2019 · 10 comments

Comments

@brandonkelly
Copy link
Member

commented Aug 7, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Aug 7, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 7, 2019

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

This comment has been minimized.

Copy link
Contributor

commented Aug 7, 2019

Very much support this.

@brandonkelly

This comment has been minimized.

Copy link
Member Author

commented Aug 7, 2019

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

@wsydney76

This comment has been minimized.

Copy link

commented Aug 7, 2019

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

This comment has been minimized.

Copy link

commented Aug 7, 2019

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

This comment has been minimized.

Copy link

commented Aug 7, 2019

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

This comment has been minimized.

Copy link
Member Author

commented Aug 7, 2019

@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

This comment has been minimized.

Copy link

commented Aug 7, 2019

@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

This comment has been minimized.

Copy link
Member Author

commented Aug 7, 2019

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. (#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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
6 participants
You can’t perform that action at this time.