<blockquote>
  <p>The only solution is to create yet another Grid field that uses the same twig code for rendering only to use it again on the same side.</p>
</blockquote>

<p>Do you need to enforce that structure or is it a "soft" restriction (meaning things won't go south if the blocks get turned around)?</p>

<p>If it were me, I would treat Matrix more or less like a site builder.  <code>[some hero image]</code> and <code>[other stuff]</code> could also be blocks in that matrix, alongside <code>full column</code> and <code>half column</code>, you just need the appropriate code to "close up" the grid when necessary.</p>

<p>You would have different blocks (like Grid, Hero Unit, Ad space, etc.) and then when building the page, just insert them in the appropriate spots. </p>

<p>That's the canonical use of Matrix of course. If you need full control over how things are presented you don't necessarily have to build out the page in the order the blocks appear in. If you name various blocks you could filter by block type and then spit out only the blocks that would appear in that area. For example, even if there is only one hero unit, you can specify it should only appear once and then spit out the hero where it needs to go (say at the top).</p>

<p>If you're doing this for a client, it might be helpful to number the blocks so they put the blocks in the intended order to avoid surprises but with matrix it's pretty open ended which might be less likely what you're looking for.</p>

<p>Ideally we should be able to have some "default" blocks and lock 'em in place so they can't be moved or disabled... maybe in a <a href="http://feedback.buildwithcraft.com/forums/285221-feature-requests" rel="nofollow">future version</a> of Craft.</p>

CC BY-SA 3.0
2015-07-29T14:18:26.070Z
Thanks for the answer.Yes, we treat Matrix like a site builder but we have some pretty specific pages that require rigid structure and we don't want the end-client-user to be able to add some blocks we dont want, e.g. with JS data. Also this makes the implementation a bit of a nightmare because it's one giant macro with instead of a few smaller ones: one for grid layout, one for this special data block that's used by JS animation on only one page etc.
user2733233
CC BY-SA 3.0
2015-07-28T22:17:15.993Z
2015-07-28T22:17:15.993Z
RitterKnight
<p>we have a problem over and over again and I wonder if we're missing something. 
Using bootstrap we have a matrix field, let's call it Grid, that has blocks like "full column" "half column" etc. It's extremely usable across all pages. </p>

<p>Now the issue is we can have only one such matrix per template. And a standard page looks like this:</p>

<pre><code>[some title]
[some grid] &lt;- Grid
[some hero image]
[again some grid] &lt;- Grid
[some other stuff]
[even more grid at the end!] &lt;- Grid
</code></pre>

<p>The only solution is to create yet another Grid field that uses the same twig code for rendering only to use it again on the same side. </p>

<p>The solution would be a way to put a field in an entry type but with ability to manually set the handle. So we could put the same field (Grid) and refer to them using topGrid, middleGrid and bottomGrid.</p>

<p>Is there any way to solve this problem?</p>

<p>thanks!
Jan</p>

<entries><matrix><field><field-layout-designer>
Using a field multiple times in a single template
# Using a field multiple times in a single template

(Asked by: username_0 on 2015-07-28)

we have a problem over and over again and I wonder if we're missing something. 
Using bootstrap we have a matrix field, let's call it Grid, that has blocks like "full column" "half column" etc. It's extremely usable across all pages. 
Now the issue is we can have only one such matrix per template. And a standard page looks like this:
[some title]
[some grid] <- Grid
[some hero image]
[again some grid] <- Grid
[some other stuff]
[even more grid at the end!] <- Grid

The only solution is to create yet another Grid field that uses the same twig code for rendering only to use it again on the same side. 
The solution would be a way to put a field in an entry type but with ability to manually set the handle. So we could put the same field (Grid) and refer to them using topGrid, middleGrid and bottomGrid.
Is there any way to solve this problem?
thanks!
Jan

**Tags:** entries, matrix, field, field-layout-designer

---

## 1 answers

### Answer by username_1 on 2015-07-28. Score: 1

> The only solution is to create yet another Grid field that uses the same twig code for rendering only to use it again on the same side.

Do you need to enforce that structure or is it a "soft" restriction (meaning things won't go south if the blocks get turned around)?

If it were me, I would treat Matrix more or less like a site builder. `[some hero image]` and `[other stuff]` could also be blocks in that matrix, alongside `full column` and `half column`, you just need the appropriate code to "close up" the grid when necessary.

You would have different blocks (like Grid, Hero Unit, Ad space, etc.) and then when building the page, just insert them in the appropriate spots.

That's the canonical use of Matrix of course. If you need full control over how things are presented you don't necessarily have to build out the page in the order the blocks appear in. If you name various blocks you could filter by block type and then spit out only the blocks that would appear in that area. For example, even if there is only one hero unit, you can specify it should only appear once and then spit out the hero where it needs to go (say at the top).

If you're doing this for a client, it might be helpful to number the blocks so they put the blocks in the intended order to avoid surprises but with matrix it's pretty open ended which might be less likely what you're looking for.

Ideally we should be able to have some "default" blocks and lock 'em in place so they can't be moved or disabled... maybe in a [future version](http://feedback.buildwithcraft.com/forums/285221-feature-requests) of Craft.

> **Comments:**
> **username_0**: Thanks for the answer.Yes, we treat Matrix like a site builder but we have some pretty specific pages that require rigid structure and we don't want the end-client-user to be able to add some blocks we dont want, e.g. with JS data. Also this makes the implementation a bit of a nightmare because it's one giant macro with instead of a few smaller ones: one for grid layout, one for this special data block that's used by JS animation on only one page etc.  

---

