[5.0] Static blocks mode for matrix fields #14015
-
|
The main purpose of Matrix fields is to facilitate the building of modular content structures. A colateral function is the grouping of fields in the CP, which can be useful for organizing an entry's field layout (since we have no other way to make "fieldsets" or "wrapping" columns). One can use a matrix with a single block type and an equal min/max setting of allowed blocks, to effectively make a static fieldset (and as a bonus one that can be collapsed/expanded). This kind of works, but, if you go with more than '1' min/max blocks, or want more than one block type, it becomes a little problematic. Since the introduction of the As an example, with the introduction of If I find some time I might add a mockup to clarify the above! Thanks for reading 🙂 |
Beta Was this translation helpful? Give feedback.
Replies: 5 comments 3 replies
-
|
I have come across a similar situation today when working on a new Craft 5 project. I have a set of fields (A section header) that is used across a lot of different block types (Sections). However, as far as I can see the only way to do this is to then create another Matrix field (min:1 max:1) with one EntryType sectionHeader and then include this field in each Entry Type (for each block/section). This works well as it also allows me to use render() in the templates. The issues I have come across are; I would say it is possibly a bug that if you specify min:1 and max:1 and then disable that clock, that the system should error, but currently is passes and then that block is missing. It would be nice to be able to create field groups that solve this problem, that are static (1 only) fields that can be included inside EntryTypes without the need to set them up as another Matrix field. I think this would solve both the issues I mention. 
It also looks like another thread was created about this here: So might be worth merging those.... |
Beta Was this translation helpful? Give feedback.
-
|
To me this is part of a larger discussion about user-permission based read only fields in general (for all field types): |
Beta Was this translation helpful? Give feedback.
-
|
Just wanted to express my interest in this as well. I think just adding a light-switch or checkbox to the entry types field on matrix fields would be great. Maybe that list auto sorts checked entry types to the top. This would really help us as we re-think our content model in Craft 5. Being able to compose entry types with groups of fields essentially would not only allow us to re-use a group fields easier, and allow us to make changes to those groups easier. So for example we have group of fields that we use for SEO (meta tags and such). We have several entry types that rely on those fields. It was kinda tedious adding the same fields/sections per entry type, and it's tedious if we need to add or remove a field from that group. It's not back-breaking, just annoying and a little more prone to errors since we have a very large content model. There's been a couple times already where we missed an entry type or two that was supposed to get an added field for the same "group" of fields. |
Beta Was this translation helpful? Give feedback.
-
|
Assuming that the core idea here is to provide some way to create re-usable "groupings" of fields that act as a single, cohesive unit in the context of an element's field layout, IMO this could possibly be better solved with an improved Table field, that had
(The static part is already implemented, as @thupsi mentions 🙂) Compared to a static Matrix field, a static Table field with the above capabilities could be beneficial for a few reasons:
|
Beta Was this translation helpful? Give feedback.
-
|
I'm going back and forth on this. I think using a table gets tricky when one of the fields you're trying to use is a matrix block, or existing fields. Trying to think of the UI for that, and I think I would much rather, if going the table route, if a row would just reference an entry type which has the existing fields and UI elements. Otherwise using a table seems a little limiting. Ideally i could define a field layout with fields and UI elements (sections, hr, instructions, etc) and have it display on an entry editing page as if I did all that directly in it's entry type. Could be wrong but not sure if the table field is conducive to that? |
Beta Was this translation helpful? Give feedback.
-
|
also wondering if it's actually necessary that extra queries are made? In my mind (and maybe this is dumb), static blocks would be saved in the json content column in I could see a new field just called |
Beta Was this translation helpful? Give feedback.
-
|
Well, the whole deal with Matrix fields is that they create and manage nested entries. If the "Static Matrix" field saved its content to a JSON content column in FWIW, it's already possible to create Matrix fields with a single entry type and min/max entries both set to 1... which will behave more or less like a "static" Matrix field. As an alternative to that, I personally think there's room for a more capable field type that doesn't use nested entries, to meet the use case described here. Yeah, perhaps it would make sense to do it as an entirely new field type altogether, but in my opinion it really sounds like something that could be achieved by powering up the existing Table field – the bonus being that those additional capabilities would benefit non-static Table fields as well. |
Beta Was this translation helpful? Give feedback.
-
|
Craft 5.8 is out, which introduces a new “Content Block” field type, which can be used to create reusable nested field layouts. (#17424) |
Beta Was this translation helpful? Give feedback.
Craft 5.8 is out, which introduces a new “Content Block” field type, which can be used to create reusable nested field layouts. (#17424)