-
Notifications
You must be signed in to change notification settings - Fork 641
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
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
Hierarchical Matrix fields #827
Comments
push. i think structure is sufficient. lets use the nav here for easy demo {% nav matrixBlock in entry.matrixFieldHandle %}
<div>
{% switch matrixBlock.type %}
...
{% endswitch %}
{% if children %}
{% children %}
{% endchildren %}
</div>
{% endnav %} |
@brandon and @mark i have submitted the entry in an entry idea here: #834 |
I think Mark's idea to create new entries from an entries field would be a good solution for anything this FR isn't enough for. So 2x "+1" for these suggestions (sorry, I ran out of real votes)!! |
This is a great idea. I think I even prefer it to the Pandora's box of actually nesting the Matrix fields. |
@mark - that's more conceptually similar to the traditional Matrix-within-Matrix request; it's actually a step further, since not only can you have multiple Matrix fields within the related entries, but you can also have multiple Entries fields within a single Matrix block. Regardless, you may want to post your FR as its own idea ;) |
I like this idea, but isn't that somewhat similar, conceptually, to an "entries" field with a related entry containing a matrix? Personally, I'd rather see the ability to create new entries from an Entries field. This way you could have nested matrix blocks but still retain the existing UI. |
Technically it would be more limiting, since each Matrix block would only get a single set of sub-blocks, whereas if it was possible to have an entire Matrix field within another, then each block could have multiple sets of sub-blocks (via multiple sub-Matrix fields). I’m just not sure if there are many valid use cases for that, or if this hierarchical Matrix idea would suffice 90% of the time Matrix-within-Matrix is desired. |
As long as ultimately the functionality you can achieve is the same, then great!! |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
As an alternative to Matrix within Matrix (#812), it might be nice if Matrix fields were hierarchical, like Structure sections.
The UI for that would be a bit simpler, since a nested blocks would be nested under the entire parent block, rather than crammed into one of the parent block’s fields.
We could even set up some block type rules that restrict which levels the block types are allowed to be used on (or what their parent block types must be, etc.), similar to #853.
The text was updated successfully, but these errors were encountered: