<p>Sounds like you're looking for <a href="https://craftcms.com/docs/3.x/matrix-fields.html" rel="nofollow noreferrer">Matrix Fields</a>. A matrix field allows you to create repeatable content blocks of varying types. This is different from a simple table (repeater) field since you can define several <em>different</em> block types – for example, one block type <em>List</em> and one block type <em>Text</em>. The editors can then create and arrange multiple block types as they see fit.</p>
<p>Check out the documentation on <a href="https://craftcms.com/docs/3.x/matrix-fields.html" rel="nofollow noreferrer">Matrix Fields</a> to get started.</p>
<p>Note there are also other some plugins available that provide similar field types with some difference. Most notably the <a href="https://plugins.craftcms.com/neo" rel="nofollow noreferrer">Neo plugin</a>, which reuses your existing fields – meanwhile, the Matrix fields requires you to create fields in its own configuration, and separately for each block. Also, the Neo plugin allows you to create nested blocks, which Matrix can't at the moment.</p>

CC BY-SA 4.0
2022-03-15T09:11:12.133Z
Hi thanks for the info - I don't think that allowing any content editor to add new blocks or remove blocks with a matrix field is the correct workflow. I have tried to work out a solution using - Matrix > nested super table - super table > nested matrix - matrix > nested super table > nested matrix.... (these didnt work). I have seen the Neo plugin, which might be the way to go, but I was hoping to figure out what is the off the shelf P&T way to handle this type of issue? Is it just to create multiple fields, if so is there a way to do this faster like a json upload or something
Wally
CC BY-SA 4.0
2022-03-15T09:13:02.013Z
If you know of any docs you could point me to about how to handle workflow in Craft that would be great - i've been looking for a solid answer to this issue for an embarrassing amount of time - so I might have mis understood the way Craft operates
Wally
CC BY-SA 4.0
2022-03-15T09:16:07.530Z
@Wally I don't really understand the problem you're trying to solve. If it's about allowing for reusable content blocks, any combination of Matrix, Super Table and Neo fields will do fine. If it's about having a static content model with multiple fields – well, you just create those fields. Not worth it to go to elaborate setups or plugins just to save on some clicking in the UI. Though I think Matrix would be a good fit for your situation, maybe you just need to rethink your content approach a bit.
MoritzLost
CC BY-SA 4.0
2022-03-15T09:49:16.507Z
Thanks again for the reply - Ok I think its going to be a case of just creating static field types via the UI for each section for each page - I am a bit surprised that such a manual process is required for fields that have already been created (but i've only started to question it when looking at ways to slim down development time) - I have just trialed NEO this solves the ability to reuse already created fields.
Wally
CC BY-SA 4.0
2022-03-15T10:11:46.693Z
@Wally Yeah, using multiple Neo fields limited to one block each to provide sets of content that reuse existing fields sounds like a good compromise. If this solves your question, would you mind marking my answer accepted? Thanks!
MoritzLost
CC BY-SA 4.0
2022-03-15T11:42:05.173Z
You mention avoiding technical debt, but IMO, adding third-party stuff like Neo and Supertable is _adding_ technical debt. For matrix-in-matrix functionality, you can achieve this natively by creating a section to store your reusable components/widgets, and creating entry types in that section for each type of component. Then create a block type in the main body-builder matrix to select a component from that section. This approach makes your components reusable across multiple entries, and is also easy to optimise performance with native eager loading.
James Smith
CC BY-SA 4.0
2022-03-15T14:06:07.947Z
@JamesSmith Could you create an answer with this as a working example please - not sure how to conceptualize this method. I agree in terms of technical debt, I'm trying to avoid the use of plugins (not that I have anything against them) - I'm still a bit confused where there isn't clear documentation regarding a standard design pattern for Craft - I know its power is in its ability to be design agnostic, but a base line of this is good practice this is bad practice would be pretty handy.
Wally
CC BY-SA 4.0
2022-03-15T15:55:33.270Z
It's not really a separate answer to this one already given, merely an extension of it: you can use a matrix field to build up your body of content using different block types - one of those block types could be called "Component" or "Widget" and consist of an Entries selector field where you select an entry from a "Components" section to be output. The component can be reused in multiple blocks in the same entry, or across different entries. Entries in the components section can each be their own Entry Type to allow for unique field sets per component.
James Smith
CC BY-SA 4.0
2022-03-15T16:08:04.157Z
@Wally I think you're missing the bigger picture. Maybe you're used to WordPress ACF which just work a bit different from Craft. To be efficient and future-proof, try to approach your content modeling in a way that makes sense for the system you're working with. In this case, using a combination of Matrix/Neo/SuperTable and/or separate entries as components is a perfectly good solution. If you're struggling to fit this into your existing content model or workflow, maybe you need to rethink the latter points a bit.
MoritzLost
CC BY-SA 4.0
2022-03-16T14:57:25.837Z
Hi all - thanks so much for all the input, I really apricate the help. I'm thinking that my question has not been asked in a clear way or I have tried to add to much detail, so will re-review it (It might just be the case that I'm wrong or there is no way to do what Im looking for).
Wally
CC BY-SA 4.0
2022-03-15T08:55:33.130Z
2022-03-15T08:55:33.130Z
MoritzLost
<p>I'm looking for a way to do rapid development (i.e. not manually using the UI to create one field at a time). So if you have a page which requires multiple similar fields you can quickly add them?</p>
<p>Most of a web pages I build are componentized so all fields are all variations of a base component - (example in screenshot below):</p>
<p><a href="https://i.sstatic.net/lDlQ9.png" rel="nofollow noreferrer"><img src="https://i.sstatic.net/lDlQ9.png" alt="enter image description here" /></a></p>
<p>What you could do here (please correct me if im wrong):</p>
<ol>
<li>create a individual field in craft for each of these sections. So there would be 3 (as two of the fields are being used on different pages) - but:</li>
</ol>
<p>a) If I need to use the same section multiple times on the page i.e. use the base field at the top of the page and bottom of the page then I cannot duplicate it (or just reuse it at the top and bottom), I'd need to create a brand new field - this feels very strange and like my process is wrong as its not DRY and leads to multiple fields - is there any documentation on how you should approach this?</p>
<p>I've seen reference to a wordpress plugin for this type of work:
<a href="https://www.advancedcustomfields.com/" rel="nofollow noreferrer">https://www.advancedcustomfields.com/</a></p>
<p>I'm not comparing caft and wordpress - I don't mind using the UI if thats the indended system and just making alot of fields, I'm just trying to find a answer to if this is the correct system instead of constantly thinking im creating alot of technical debt for a future developer.</p>
<p>Thanks - W</p>

<field><workflow><layout>
Whats crafts best practice when having to reuse fields
# Whats crafts best practice when having to reuse fields

(Asked by: username_0 on 2022-03-15)

I'm looking for a way to do rapid development (i.e. not manually using the UI to create one field at a time). So if you have a page which requires multiple similar fields you can quickly add them?

Most of a web pages I build are componentized so all fields are all variations of a base component - (example in screenshot below):

[![enter image description here](https://i.sstatic.net/lDlQ9.png)](https://i.sstatic.net/lDlQ9.png)

What you could do here (please correct me if im wrong):

1. create a individual field in craft for each of these sections. So there would be 3 (as two of the fields are being used on different pages) - but:

a) If I need to use the same section multiple times on the page i.e. use the base field at the top of the page and bottom of the page then I cannot duplicate it (or just reuse it at the top and bottom), I'd need to create a brand new field - this feels very strange and like my process is wrong as its not DRY and leads to multiple fields - is there any documentation on how you should approach this?

I've seen reference to a wordpress plugin for this type of work:
<https://www.advancedcustomfields.com/>

I'm not comparing caft and wordpress - I don't mind using the UI if thats the indended system and just making alot of fields, I'm just trying to find a answer to if this is the correct system instead of constantly thinking im creating alot of technical debt for a future developer.

Thanks - W

**Tags:** field, workflow, layout

---

## 1 answers

### Answer by username_1 on 2022-03-15. Score: 1

Sounds like you're looking for [Matrix Fields](https://craftcms.com/docs/3.x/matrix-fields.html). A matrix field allows you to create repeatable content blocks of varying types. This is different from a simple table (repeater) field since you can define several *different* block types – for example, one block type *List* and one block type *Text*. The editors can then create and arrange multiple block types as they see fit.

Check out the documentation on [Matrix Fields](https://craftcms.com/docs/3.x/matrix-fields.html) to get started.

Note there are also other some plugins available that provide similar field types with some difference. Most notably the [Neo plugin](https://plugins.craftcms.com/neo), which reuses your existing fields – meanwhile, the Matrix fields requires you to create fields in its own configuration, and separately for each block. Also, the Neo plugin allows you to create nested blocks, which Matrix can't at the moment.

> **Comments:**
> **username_0**: Hi thanks for the info - I don't think that allowing any content editor to add new blocks or remove blocks with a matrix field is the correct workflow. I have tried to work out a solution using - Matrix > nested super table - super table > nested matrix - matrix > nested super table > nested matrix.... (these didnt work). I have seen the Neo plugin, which might be the way to go, but I was hoping to figure out what is the off the shelf P&T way to handle this type of issue? Is it just to create multiple fields, if so is there a way to do this faster like a json upload or something  
> **username_0**: If you know of any docs you could point me to about how to handle workflow in Craft that would be great - i've been looking for a solid answer to this issue for an embarrassing amount of time - so I might have mis understood the way Craft operates  
> **username_1**: @Wally I don't really understand the problem you're trying to solve. If it's about allowing for reusable content blocks, any combination of Matrix, Super Table and Neo fields will do fine. If it's about having a static content model with multiple fields – well, you just create those fields. Not worth it to go to elaborate setups or plugins just to save on some clicking in the UI. Though I think Matrix would be a good fit for your situation, maybe you just need to rethink your content approach a bit.  
> **username_0**: Thanks again for the reply - Ok I think its going to be a case of just creating static field types via the UI for each section for each page - I am a bit surprised that such a manual process is required for fields that have already been created (but i've only started to question it when looking at ways to slim down development time) - I have just trialed NEO this solves the ability to reuse already created fields.  
> **username_1**: @Wally Yeah, using multiple Neo fields limited to one block each to provide sets of content that reuse existing fields sounds like a good compromise. If this solves your question, would you mind marking my answer accepted? Thanks!  
> **username_2**: You mention avoiding technical debt, but IMO, adding third-party stuff like Neo and Supertable is _adding_ technical debt. For matrix-in-matrix functionality, you can achieve this natively by creating a section to store your reusable components/widgets, and creating entry types in that section for each type of component. Then create a block type in the main body-builder matrix to select a component from that section. This approach makes your components reusable across multiple entries, and is also easy to optimise performance with native eager loading.  
> **username_0**: @JamesSmith Could you create an answer with this as a working example please - not sure how to conceptualize this method. I agree in terms of technical debt, I'm trying to avoid the use of plugins (not that I have anything against them) - I'm still a bit confused where there isn't clear documentation regarding a standard design pattern for Craft - I know its power is in its ability to be design agnostic, but a base line of this is good practice this is bad practice would be pretty handy.  
> **username_2**: It's not really a separate answer to this one already given, merely an extension of it: you can use a matrix field to build up your body of content using different block types - one of those block types could be called "Component" or "Widget" and consist of an Entries selector field where you select an entry from a "Components" section to be output. The component can be reused in multiple blocks in the same entry, or across different entries. Entries in the components section can each be their own Entry Type to allow for unique field sets per component.  
> **username_1**: @Wally I think you're missing the bigger picture. Maybe you're used to WordPress ACF which just work a bit different from Craft. To be efficient and future-proof, try to approach your content modeling in a way that makes sense for the system you're working with. In this case, using a combination of Matrix/Neo/SuperTable and/or separate entries as components is a perfectly good solution. If you're struggling to fit this into your existing content model or workflow, maybe you need to rethink the latter points a bit.  
> **username_0**: Hi all - thanks so much for all the input, I really apricate the help. I'm thinking that my question has not been asked in a clear way or I have tried to add to much detail, so will re-review it (It might just be the case that I'm wrong or there is no way to do what Im looking for).  

---

