[5.0] Static blocks mode for matrix fields

[thupsi]

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 Static Rows option for the Table field I have been thinking that having a similar option for Matrix fields would really help for this kind of field "grouping and organizing". Upon creating a matrix field, a Static blocks option would give us the ability to define a static number and type of blocks with a fixed order.

As an example, with the introduction of Card view for matrix fields in Craft 5, such an option would enable us to have the top level sections of an entry presented as cards (reminder to self to ask for full-width/stacked cards), with no "add new block" button and no option to rearrange blocks. The author would then start with a nice bird's-eye overview of the content and dig into details using the slideout pattern.

If I find some time I might add a mockup to clarify the above! Thanks for reading 🙂

[terryupton]

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).
So rather than having to construct these fields every-time in each block, I thought it was logical to create it as an EntryType sectionHeader (a group of fields) so I could include it within each section/block which are also Entry Types.

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;
Because it is now a matrix filed you can in-fact disable the entry and then there is no heading, breaking the layout. Not ideal.
It looks a bit clunky because it is essentially a nested field.

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:
#14600

So might be worth merging those....

[khalwat]

To me this is part of a larger discussion about user-permission based read only fields in general (for all field types):

#8636

[myleshyson]

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.

[mmikkel]

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 ability to use all/most field types as columns
• the ability to save real relations for any relational field columns (already on the roadmap, I believe)
• an alternative display mode where each column is represented as a row (similar to SuperTable's "Row" layout)

(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:

• no need to create that additional entry type
• field values remain first citizens of the element that owns the field, albeit saved as a JSON structure
• a less complicated content model; no need for what is essentially a superfluous nested entry, the need to query for that in templates, etc
• less AX ambiguity in dealing with drafts etc

[myleshyson]

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?

[myleshyson]

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 element_sites. That would make the field value for matrix field kinda awkward though. Like it's an ElementQuery...but it has values already. IDK maybe that's not the move either.

I could see a new field just called Static Matrix or something, that's basically the same thing as a matrix field but with it's values in the json content column. Sometimes creating a new thing by copying and tweaking an existing thing is much simpler than expanding an existing thing. I'd have to code dive into the matrix field though to see if that would be the case here. That might be a dumb idea too.

[mmikkel]

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 element_sites instead of creating nested entries, you're essentially describing a Table field :)

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.