<p>Rather than trying to store multiple stats together in a single block, another option would be to make a "Stat" (singular) block type, which only holds a single stat, and just have authors create as many of those as they need, positioned together.</p>

<p>From your template, when looping through blocks, you can check to see if the current block is the first/last of its type, and add some extra HTML when that's the case, so that consecutive Stat blocks still appear grouped together in the rendered HTML. Something like this:</p>

<pre class="lang-twig prettyprint-override"><code>{% for block in entry.myMatrixField %}

    {# Find out if this is the first/last consecutive block of this
type #}
    {% set type = block.type.handle %}
    {% set isFirstConsecutiveBlockOfType = (loop.first or type != block.getPrev().type.handle) %}
    {% set isLastConsecutiveBlockOfType = (loop.last or type != block.getNext().type.handle) %}

    {% switch type %}

        {% case 'stat' %}

            {% if isFirstConsecutiveBlockOfType %}
                &lt;div class="stats"&gt;
            {% endif %}

            &lt;!-- Stat block HTML --&gt;

            {% if isLastConsecutiveBlockOfType %}
                &lt;/div&gt;
            {% endif %}

        {% case 'quote' %}

            {% if isFirstConsecutiveBlockOfType %}
                &lt;div class="quotes"&gt;
            {% endif %}

            &lt;!-- Quote block HTML --&gt;

            {% if isLastConsecutiveBlockOfType %}
                &lt;/div&gt;
            {% endif %}

    {% endswitch %}
{% endfor %}
</code></pre>

CC BY-SA 3.0
2015-01-21T22:24:21.530Z
I thought of something similar (just grouping them together in the CP), but instead of checking for the first/last block of one type, one could also use a special block type as a separator. This would allow you to also add title, description and other universal blocks types to each group. The special block could have a dropdown field "beginSection" to bring this info to the template.
carlcs
CC BY-SA 3.0
2015-01-22T08:09:07.347Z
I have to say we have implemented a separator block type on a lot of our builds - aside from it being a clean solution for me as a dev it seems to be understood easily by clients.
Josh Angell
CC BY-SA 3.0
2015-01-21T22:03:17.277Z
2015-01-21T22:03:17.277Z
Brandon Kelly
<p>Folks may also want to checkin the Super Table plugin that just came out. It allows you to create table fields that include almost any field type:</p>

<p><a href="https://github.com/engram-design/SuperTable">https://github.com/engram-design/SuperTable</a></p>

<p>Keep in mind, though, that in many cases this may make your CMS/data pretty dependent on a plugin.</p>

CC BY-SA 3.0
2015-04-22T15:41:25.520Z
2015-04-22T15:41:25.520Z
philzelnar
<p>This question was asked prior to the release of the <a href="https://github.com/benjamminf/craft-neo" rel="nofollow noreferrer">Neo plugin/field type</a>. I think this would offer a better approach than the SuperTable (which was/is still awesome), just because I think it's easier to manage and template.</p>

<p>I posted an answer to a similar question with examples <a href="https://craftcms.stackexchange.com/questions/8512/modelling-flexible-content-sections-and-reccomendations">here</a>.</p>

CC BY-SA 3.0
2016-09-08T19:11:44.650Z
Neo is excellent. I think this is the best option.
Alex Kendrick
CC BY-SA 3.0
2016-07-15T22:43:44.160Z
2016-07-15T22:43:44.160Z
2017-04-13T12:51:00.200Z
Ian DeRanieri
<p>An alternate solution that might work is to create separate channels for 'stats' and 'quotes', and then use an <code>entries</code> field within your matrix block to add them to the 'stats' and 'quotes' blocks. Although not as accessible when creating the entry, it seems like it would potentially be a lot easier to manage all around, with no limitations on filedtypes, etc.</p>

CC BY-SA 3.0
2015-01-21T20:19:43.923Z
This is what I'm doing. I use a structure instead of a channel, so you have the option to manually organize things.
Marion Newlevant
CC BY-SA 3.0
2015-01-21T20:23:09.320Z
We thought about this, but in some cases they may need to create say ten+ entries to create a row which seems kind of burdensome. Also, I'd really love for them to be able to see all the content in one shot, rather than having to double-click each related entry to see it's subfields, etc. I can see the perks, but just don't think it's right for our case.
philzelnar
CC BY-SA 3.0
2015-01-21T20:33:33.033Z
In my case it was the lesser evil. I would *love* to see matrix in matrix
Marion Newlevant
CC BY-SA 3.0
2015-01-21T20:04:21.703Z
2015-01-21T20:04:21.703Z
Douglas McDonald
<p>Maybe this is not the best idea for your exact use case, but what about using a Structure section for your entries with two levels. Top level entries would be your "actual entries" and their child entries would be a substitute for your current matrix blocks. In the template of top level entries you then collect the content of the children in sort order, conditionally output the data based on the used entry type of the child.</p>

<p>Not sure if you are able to use live preview with such an approach though.</p>

CC BY-SA 4.0
2020-08-24T18:16:47.700Z
I don't recommend such a solution. It makes content spread in the control panel in completely unintuitive way.
Piotr Pogorzelski
CC BY-SA 3.0
2015-01-21T20:26:25.477Z
2015-01-21T20:26:25.477Z
carlcs
<p>Here's my article that described possible solutions to this problem:</p>
<p><a href="http://craftsnippets.com/articles/matrix-within-a-matrix-possible-solutions-for-craft-cms" rel="nofollow noreferrer">http://craftsnippets.com/articles/matrix-within-a-matrix-possible-solutions-for-craft-cms</a></p>

CC BY-SA 4.0
2020-08-24T19:01:15.870Z
2020-08-24T19:01:15.870Z
Piotr Pogorzelski
<p>I was wondering if anyone has stumbled on a good solution for including matrix-like fields within a matrix block. I’m working on a site where each page's is constructed in one big matrix with several block types (each representing a “row" in the page) like…</p>

<ul>
<li>Introduction</li>
<li>Stats</li>
<li>Quotes</li>
<li>Bios
etc.</li>
</ul>

<p>Blocks like Stats, Quotes, etc. can hold either just one, or several of these items, so right now the subfields look something like this:</p>

<ul>
<li>Block Title</li>
<li>Stat 1: Number</li>
<li>Stat 1: Text</li>
<li>Stat 2: Number</li>
<li>Stat 2: Text …etc. up to Stat 6</li>
</ul>

<p>Rather than having all these fields in view by default, it would (obviously) be best if the user were just adding Stats as rows in an inner table or Matrix. Initially I thought that using Table fields would be the fix, but in several cases I need to include fields that aren’t natively supported in in Tables (like Assets, Rich Text, etc.). </p>

<p>At the very least it would be nice to collapse some of the fields that are likely not going to be needed so they are out of the way (so in the example above, maybe show fields for the first 2 stats, hide field for the next 4).</p>

<p>Has anybody stumbled on a good solution (maybe a Plugin) for either allowing more field types within Tables, adding a Matrix to a Matrix block, or collapsing fields by default?</p>

<p>Also open to other suggestions … seems like a lot of sites take this “stacked rows” approach, so guessing I’m not alone here. Thanks!</p>

CC BY-SA 3.0
2016-12-08T05:42:46.523Z
A similar question was asked here: *[Matrix fields within matrix field](http://craftcms.stackexchange.com/questions/1528/matrix-fields-within-matrix-field)*
Simon East
<matrix><table-field><content>
Solution for Matrix-within-Matrix (or More Robust Table Fields)
# Solution for Matrix-within-Matrix (or More Robust Table Fields)

(Asked by: username_0 on 2015-01-21)

I was wondering if anyone has stumbled on a good solution for including matrix-like fields within a matrix block. I’m working on a site where each page's is constructed in one big matrix with several block types (each representing a “row" in the page) like…

* Introduction
* Stats
* Quotes
* Bios
  etc.

Blocks like Stats, Quotes, etc. can hold either just one, or several of these items, so right now the subfields look something like this:

* Block Title
* Stat 1: Number
* Stat 1: Text
* Stat 2: Number
* Stat 2: Text …etc. up to Stat 6

Rather than having all these fields in view by default, it would (obviously) be best if the user were just adding Stats as rows in an inner table or Matrix. Initially I thought that using Table fields would be the fix, but in several cases I need to include fields that aren’t natively supported in in Tables (like Assets, Rich Text, etc.).

At the very least it would be nice to collapse some of the fields that are likely not going to be needed so they are out of the way (so in the example above, maybe show fields for the first 2 stats, hide field for the next 4).

Has anybody stumbled on a good solution (maybe a Plugin) for either allowing more field types within Tables, adding a Matrix to a Matrix block, or collapsing fields by default?

Also open to other suggestions … seems like a lot of sites take this “stacked rows” approach, so guessing I’m not alone here. Thanks!

**Tags:** matrix, table-field, content
> **Comments:**
> **username_1**: A similar question was asked here: *[Matrix fields within matrix field](http://craftcms.stackexchange.com/questions/1528/matrix-fields-within-matrix-field)*  

---

## 6 answers

### Answer by username_2 on 2015-01-21. Score: 20

Rather than trying to store multiple stats together in a single block, another option would be to make a "Stat" (singular) block type, which only holds a single stat, and just have authors create as many of those as they need, positioned together.
From your template, when looping through blocks, you can check to see if the current block is the first/last of its type, and add some extra HTML when that's the case, so that consecutive Stat blocks still appear grouped together in the rendered HTML. Something like this:
{% for block in entry.myMatrixField %}

    {# Find out if this is the first/last consecutive block of this
type #}
    {% set type = block.type.handle %}
    {% set isFirstConsecutiveBlockOfType = (loop.first or type != block.getPrev().type.handle) %}
    {% set isLastConsecutiveBlockOfType = (loop.last or type != block.getNext().type.handle) %}

    {% switch type %}

        {% case 'stat' %}

            {% if isFirstConsecutiveBlockOfType %}
                
            {% endif %}

            

            {% if isLastConsecutiveBlockOfType %}
                
            {% endif %}

        {% case 'quote' %}

            {% if isFirstConsecutiveBlockOfType %}
                
            {% endif %}

            

            {% if isLastConsecutiveBlockOfType %}
                
            {% endif %}

    {% endswitch %}
{% endfor %}

> **Comments:**
> **username_3**: I thought of something similar (just grouping them together in the CP), but instead of checking for the first/last block of one type, one could also use a special block type as a separator. This would allow you to also add title, description and other universal blocks types to each group. The special block could have a dropdown field "beginSection" to bring this info to the template.  
> **username_4**: I have to say we have implemented a separator block type on a lot of our builds - aside from it being a clean solution for me as a dev it seems to be understood easily by clients.  

---

### Answer by username_0 on 2015-04-22. Score: 17

Folks may also want to checkin the Super Table plugin that just came out. It allows you to create table fields that include almost any field type:

<https://github.com/engram-design/SuperTable>

Keep in mind, though, that in many cases this may make your CMS/data pretty dependent on a plugin.


---

### Answer by username_5 on 2016-07-15. Score: 6

This question was asked prior to the release of the [Neo plugin/field type](https://github.com/benjamminf/craft-neo). I think this would offer a better approach than the SuperTable (which was/is still awesome), just because I think it's easier to manage and template.

I posted an answer to a similar question with examples [here](https://craftcms.stackexchange.com/questions/8512/modelling-flexible-content-sections-and-reccomendations).

> **Comments:**
> **username_6**: Neo is excellent. I think this is the best option.  

---

### Answer by username_7 on 2015-01-21. Score: 5

An alternate solution that might work is to create separate channels for 'stats' and 'quotes', and then use an `entries` field within your matrix block to add them to the 'stats' and 'quotes' blocks. Although not as accessible when creating the entry, it seems like it would potentially be a lot easier to manage all around, with no limitations on filedtypes, etc.

> **Comments:**
> **username_8**: This is what I'm doing. I use a structure instead of a channel, so you have the option to manually organize things.  
> **username_0**: We thought about this, but in some cases they may need to create say ten+ entries to create a row which seems kind of burdensome. Also, I'd really love for them to be able to see all the content in one shot, rather than having to double-click each related entry to see it's subfields, etc. I can see the perks, but just don't think it's right for our case.  
> **username_8**: In my case it was the lesser evil. I would *love* to see matrix in matrix  

---

### Answer by username_3 on 2015-01-21. Score: 2

Maybe this is not the best idea for your exact use case, but what about using a Structure section for your entries with two levels. Top level entries would be your "actual entries" and their child entries would be a substitute for your current matrix blocks. In the template of top level entries you then collect the content of the children in sort order, conditionally output the data based on the used entry type of the child.

Not sure if you are able to use live preview with such an approach though.

> **Comments:**
> **username_9**: I don't recommend such a solution. It makes content spread in the control panel in completely unintuitive way.  

---

### Answer by username_9 on 2020-08-24. Score: 1

Here's my article that described possible solutions to this problem:

<http://craftsnippets.com/articles/matrix-within-a-matrix-possible-solutions-for-craft-cms>


---

