<p>I see this question as two parts: information architecture and templating.</p>
<p>If you're used to something like WordPress where the template has a one-to-one relationship with how the template gets data and how information is routed, ignore everything you've learned.</p>
<h1>Templating</h1>
<p>Let's get the requirement of reusing templates out of the way first. <a href="http://twig.sensiolabs.org" rel="nofollow noreferrer">Twig</a>, Craft's templating language,  lets your reuse templates quite easily.</p>
<p>Not only can you use reuse templates from any page inside Craft, you can also <a href="http://twig.sensiolabs.org/doc/templates.html#template-inheritance" rel="nofollow noreferrer">extend</a> templates from other templates.</p>
<p>Craft then lets you define <a href="https://craftcms.com/docs/routing" rel="nofollow noreferrer">which template</a> is going to be used for each section. You could just set it to a single one and be done with it if your content doesn't change that much from section to section. A single Matrix field could pull off quite a bit across the entire site.  Speaking of...</p>
<h1>Matrix</h1>
<p><a href="https://craftcms.com/features/matrix" rel="nofollow noreferrer">Matrix fields</a> can be used for &quot;site builder&quot; like functionality. Matrix lets you define block types (eg Pullquote, Featured Image with Caption, etc) and then by mixing and matching the blocks, you can &quot;build up&quot; a page. The blocks can also be reordered. That gives authors a lot of flexibility in how they layout the pages.</p>
<h1>Entry Types</h1>
<p><a href="https://craftcms.com/features/entry-types" rel="nofollow noreferrer">Entry types</a> define what content Sections contain but unless you define the same Entry Types across multiple Sections, they're not &quot;global&quot; like Matrix fields would be.</p>
<p>Entry Types are useful if you need to define content (and layout) requirements for entries in the same section. If you curate a blog for example, you might have a &quot;Link&quot; Entry Type that links to other entries or even other blogs. Then you might have a &quot;Blog Article&quot; Entry Type for &quot;regular&quot; content.</p>
<p>In your templates, you have the ability to check which Entry Type the entry happens to be and have your template format it how it should look. The Happy Lager does this inside the <a href="https://demo.craftcms.com" rel="nofollow noreferrer">News</a> section.</p>
<h1>Information Architecture</h1>
<p>In my experience, there aren't any hard and fast rules for using Matrix and Entry types, it really depends on your content and requirements. You could probably pull off what you're asking for with either.</p>
<ul>
<li><p>If your templates are &quot;designed&quot;, meaning the products are always going to live in a certain spot inside a template, then you can probably use a relational field to define the relationship.</p>
</li>
<li><p>If you want your authors to be able to define multiple elements on a page and then pull in the products from anywhere, Matrix is going to be your weapon of choice</p>
</li>
</ul>
<p><a href="https://mijingo.com/products/screencasts/reusable-twig-templates-craft" rel="nofollow noreferrer">Mijingo</a> just introduced a course you might find useful on the subject as well.</p>

CC BY-SA 3.0
2016-08-03T03:10:56.293Z
I'd add that it's probably easier to target a certain field in a fixed template than it would be in a matrix field. If you want to grab all of a certain thing—like all "Product Sheets" in section—I think it'd be easier to target the field directly than to have to look through each block in each entry.
Ian DeRanieri
CC BY-SA 3.0
2016-07-12T16:15:11.577Z
2016-07-12T16:21:42.033Z
2020-06-17T08:56:27.903Z
RitterKnight
<p>I am building a new website using Craft CMS and I have a requirement from the design team that they want to be able to re-use templates across multiple sections. For example define how a product looks like and then be able to add a product from any sections.</p>

<p>I thought implementing this using a Matrix or having a channel/structure section with multiple entry types however I am bit unclear when to use entry types and when to use matrix or maybe there is better way to implement this and I am not aware?</p>

<matrix><entry-type>
Matrix vs Multiple entry types
# Matrix vs Multiple entry types

(Asked by: username_0 on 2016-07-12)

I am building a new website using Craft CMS and I have a requirement from the design team that they want to be able to re-use templates across multiple sections. For example define how a product looks like and then be able to add a product from any sections.

I thought implementing this using a Matrix or having a channel/structure section with multiple entry types however I am bit unclear when to use entry types and when to use matrix or maybe there is better way to implement this and I am not aware?

**Tags:** matrix, entry-type


---

## 1 answers

### Answer by username_1 on 2016-07-12. Score: 4

I see this question as two parts: information architecture and templating.

If you're used to something like WordPress where the template has a one-to-one relationship with how the template gets data and how information is routed, ignore everything you've learned.

# Templating

Let's get the requirement of reusing templates out of the way first. [Twig](http://twig.sensiolabs.org), Craft's templating language, lets your reuse templates quite easily.

Not only can you use reuse templates from any page inside Craft, you can also [extend](http://twig.sensiolabs.org/doc/templates.html#template-inheritance) templates from other templates.

Craft then lets you define [which template](https://craftcms.com/docs/routing) is going to be used for each section. You could just set it to a single one and be done with it if your content doesn't change that much from section to section. A single Matrix field could pull off quite a bit across the entire site. Speaking of...

# Matrix

[Matrix fields](https://craftcms.com/features/matrix) can be used for "site builder" like functionality. Matrix lets you define block types (eg Pullquote, Featured Image with Caption, etc) and then by mixing and matching the blocks, you can "build up" a page. The blocks can also be reordered. That gives authors a lot of flexibility in how they layout the pages.

# Entry Types

[Entry types](https://craftcms.com/features/entry-types) define what content Sections contain but unless you define the same Entry Types across multiple Sections, they're not "global" like Matrix fields would be.

Entry Types are useful if you need to define content (and layout) requirements for entries in the same section. If you curate a blog for example, you might have a "Link" Entry Type that links to other entries or even other blogs. Then you might have a "Blog Article" Entry Type for "regular" content.

In your templates, you have the ability to check which Entry Type the entry happens to be and have your template format it how it should look. The Happy Lager does this inside the [News](https://demo.craftcms.com) section.

# Information Architecture

In my experience, there aren't any hard and fast rules for using Matrix and Entry types, it really depends on your content and requirements. You could probably pull off what you're asking for with either.

* If your templates are "designed", meaning the products are always going to live in a certain spot inside a template, then you can probably use a relational field to define the relationship.
* If you want your authors to be able to define multiple elements on a page and then pull in the products from anywhere, Matrix is going to be your weapon of choice

[Mijingo](https://mijingo.com/products/screencasts/reusable-twig-templates-craft) just introduced a course you might find useful on the subject as well.

> **Comments:**
> **username_2**: I'd add that it's probably easier to target a certain field in a fixed template than it would be in a matrix field. If you want to grab all of a certain thing—like all "Product Sheets" in section—I think it'd be easier to target the field directly than to have to look through each block in each entry.  

---

