<p>I'm not totally sure I fully understand your question, but what you're describing definitely sounds like a job for Matrix.</p>

<p>Unfortunately I have no experience with Silverstripe, so I can't make any comparisons to Craft or Matrix and similar functionality in that system, but as a basic overview of what Matrix is and does, I'll just quote <a href="https://craftcms.com/docs/matrix-fields" rel="nofollow">the official docs</a>:</p>

<blockquote>
  <p>Matrix fields allow you to create multiple blocks of content within a single field.</p>
</blockquote>

<p>Basically, you can think of a Matrix field as a glorified table of repeating content. If you ever worked with WordPress and Advanced Custom Fields, Matrix is basically the same thing as the Flexible Content field in ACF.</p>

<p>Matrix fields have many use cases, but using them as "layout" builders in modular design is very common, and is (as far as I can tell) what you're looking to achieve here.</p>

<p>A <em>block type</em> in a Matrix field is basically a self contained set of fields. A <em>block</em> is an instance of a block type. After configuring a Matrix field with a selection of different block types (or layouts) such as a WYSYWIG editor, an image gallery, an embedded video, a news feed etc. When a user is editing the entry, he or she can add one or several blocks of each type to the entry, in any order.</p>

<p>For your use case (such as I understand it) let's say you create a Matrix field with the handle <code>pageLayout</code>, and add the following block types to it:</p>

<ul>
<li>Advert (handle <code>advert</code>)</li>
<li>Customer list (handle <code>customerList</code>)</li>
<li>Text and image (handle <code>textAndImage</code>)</li>
</ul>

<p>For each block type, you add the fields you need. Since the block types are sandboxed, you can have a field with the same handles in more than one block type, e.g. an image field called <code>image</code> or a text field called <code>text</code> in both the <code>advert</code> and <code>textAndImage</code> blocks.</p>

<p>It's difficult to advise on specific fields you'd need for the three block types above, but for your <code>advert</code> block type you might need a Plain Text field for <code>URL</code> and an Assets field called <code>image</code>. Assuming your customers are Users or even Entries you might need a Users or Entries field for your <code>customerList</code> block type, and the <code>textAndImage</code> field should probably have a Rich Text and an Assets field. You also might want to give the content editor the option to add a custom heading to each block, in which case you could add a PlainText <code>heading</code> field to each block type.</p>

<p>When you edit your entries, you can create one or several of each of the three block types. You can reorder blocks you already created, remove single blocks or add new blocks of either type above or below existing blocks.</p>

<p>To render your Matrix content, you'll usually work with a Twig <code>for</code> loop to run through all your blocks and render their data.</p>

<p>Using the <code>{% switch %}</code> tag to render different code based on the block type is a good way to keep things readable and clean – here's an example where all the individual block type markup is inline:</p>

<pre><code>{% for block in entry.pageLayout %}
    {# Inside here, `block` refers to a single block in the Matrix field #}
    {% switch block.type %}
        {% case 'advert' %}
            &lt;figure class="advert"&gt;
                {% set image = block.image.first() %}
                &lt;img src="{{ image.getUrl() }}" /&gt;
            &lt;/figure&gt;
        {% case 'customerList' %}
            &lt;ul class="customerList"&gt;
                {% set customers = block.customers %}
                {% for customer in customers %}
                    &lt;li&gt;{{ customer.name }}&lt;/li&gt;
                {% endfor %}
           &lt;/ul&gt;
        {% case 'textAndImage' %}
           {% set image = block.image.first() %}
           &lt;img src="{{ image.getUrl() }}" /&gt;
           &lt;p&gt;{{ block.text }}&lt;/p&gt;
    {% endswitch %}
{% endfor %}
</code></pre>

<p>Of course, to keep things even more tidy, you might opt for an approach using template partials, where you put the markup for each block type in their own template (e.g. <code>templates/blocks/advert.html</code>), and use the <code>{% include %}</code> tag to render them inside the Matrix <code>for</code> loop:</p>

<pre><code>{% for block in entry.pageLayout %}
    {% switch block.type %}
        {% case 'advert' %}
            {% include 'blocks/advert' %}
        {% case 'customerList' %}
            {% include 'blocks/customerList' %}
        {% case 'textAndImage' %}
           {% include 'blocks/textAndImage' %}
    {% endswitch %}
{% endfor %}
</code></pre>

<p>In fact, if you name your templates after your block type handles, you may get away with not having a <code>{% switch %}</code> tag at all:</p>

<pre><code>{% for block in entry.pageLayout %}
    {% include 'blocks/'~block.type %}
{% endfor %}
</code></pre>

CC BY-SA 3.0
2016-08-08T12:39:17.057Z
2016-08-08T12:39:17.057Z
Mats Mikkel Rummelhoff
<p>I'm totally new to Craft (having previously developed on Silverstripe) but have read through the basic docs, have a local version installed and have set-up a HelloWorld plugin.</p>

<p>What I am now wondering is how to produce a flexible layout that provides editors with "drag &amp; drop" components each in, for instance, Bootstrap style rows.</p>

<p>For instance a page layout that allows components for 
- an advert
- a list of customers
- a block of custom text with a custom image etc. etc. 
(e.g. <a href="https://www.salesforceiq.com/" rel="nofollow">https://www.salesforceiq.com/</a> which is Craft driven I believe). </p>

<p>The editor provides the relevant content for each custom component and can drag &amp; drop them around to change their order as required &amp; that order is reflected on the front end.  And those types of pages can appear anywhere in the site structure.</p>

<p>I'm guessing the answer is a section with a Matrix field, but I'm struggling to make the leap on how that can allow it to call on a set of custom fields that each call on custom templates?</p>

<p>Any help greatly appreciated!</p>

<matrix><plugins>
Drag and drop-able "components"
# Drag and drop-able "components"

(Asked by: username_0 on 2016-08-05)

I'm totally new to Craft (having previously developed on Silverstripe) but have read through the basic docs, have a local version installed and have set-up a HelloWorld plugin.

What I am now wondering is how to produce a flexible layout that provides editors with "drag & drop" components each in, for instance, Bootstrap style rows.

For instance a page layout that allows components for
- an advert
- a list of customers
- a block of custom text with a custom image etc. etc.
(e.g. <https://www.salesforceiq.com/> which is Craft driven I believe).

The editor provides the relevant content for each custom component and can drag & drop them around to change their order as required & that order is reflected on the front end. And those types of pages can appear anywhere in the site structure.

I'm guessing the answer is a section with a Matrix field, but I'm struggling to make the leap on how that can allow it to call on a set of custom fields that each call on custom templates?

Any help greatly appreciated!

**Tags:** matrix, plugins


---

## 1 answers

### Answer by username_1 on 2016-08-08. Score: 2

I'm not totally sure I fully understand your question, but what you're describing definitely sounds like a job for Matrix.
Unfortunately I have no experience with Silverstripe, so I can't make any comparisons to Craft or Matrix and similar functionality in that system, but as a basic overview of what Matrix is and does, I'll just quote the official docs:

Matrix fields allow you to create multiple blocks of content within a single field.

Basically, you can think of a Matrix field as a glorified table of repeating content. If you ever worked with WordPress and Advanced Custom Fields, Matrix is basically the same thing as the Flexible Content field in ACF.
Matrix fields have many use cases, but using them as "layout" builders in modular design is very common, and is (as far as I can tell) what you're looking to achieve here.
A block type in a Matrix field is basically a self contained set of fields. A block is an instance of a block type. After configuring a Matrix field with a selection of different block types (or layouts) such as a WYSYWIG editor, an image gallery, an embedded video, a news feed etc. When a user is editing the entry, he or she can add one or several blocks of each type to the entry, in any order.
For your use case (such as I understand it) let's say you create a Matrix field with the handle pageLayout, and add the following block types to it:

Advert (handle advert)
Customer list (handle customerList)
Text and image (handle textAndImage)

For each block type, you add the fields you need. Since the block types are sandboxed, you can have a field with the same handles in more than one block type, e.g. an image field called image or a text field called text in both the advert and textAndImage blocks.
It's difficult to advise on specific fields you'd need for the three block types above, but for your advert block type you might need a Plain Text field for URL and an Assets field called image. Assuming your customers are Users or even Entries you might need a Users or Entries field for your customerList block type, and the textAndImage field should probably have a Rich Text and an Assets field. You also might want to give the content editor the option to add a custom heading to each block, in which case you could add a PlainText heading field to each block type.
When you edit your entries, you can create one or several of each of the three block types. You can reorder blocks you already created, remove single blocks or add new blocks of either type above or below existing blocks.
To render your Matrix content, you'll usually work with a Twig for loop to run through all your blocks and render their data.
Using the {% switch %} tag to render different code based on the block type is a good way to keep things readable and clean – here's an example where all the individual block type markup is inline:
{% for block in entry.pageLayout %}
    {# Inside here, `block` refers to a single block in the Matrix field #}
    {% switch block.type %}
        {% case 'advert' %}
            
                {% set image = block.image.first() %}
                
            
        {% case 'customerList' %}
            
                {% set customers = block.customers %}
                {% for customer in customers %}
                    {{ customer.name }}
                {% endfor %}
           
        {% case 'textAndImage' %}
           {% set image = block.image.first() %}
           
           {{ block.text }}
    {% endswitch %}
{% endfor %}

Of course, to keep things even more tidy, you might opt for an approach using template partials, where you put the markup for each block type in their own template (e.g. templates/blocks/advert.html), and use the {% include %} tag to render them inside the Matrix for loop:
{% for block in entry.pageLayout %}
    {% switch block.type %}
        {% case 'advert' %}
            {% include 'blocks/advert' %}
        {% case 'customerList' %}
            {% include 'blocks/customerList' %}
        {% case 'textAndImage' %}
           {% include 'blocks/textAndImage' %}
    {% endswitch %}
{% endfor %}

In fact, if you name your templates after your block type handles, you may get away with not having a {% switch %} tag at all:
{% for block in entry.pageLayout %}
    {% include 'blocks/'~block.type %}
{% endfor %}


---

