<p>I suspect this isn't so much a problem with the strategy as the implementation of the <code>MatrixBlockModel</code>, which is the object type you're trying to merge with a standard Twig "object" or associative array (not sure exactly what Twig uses, behind the scenes).</p>

<p>If you're trying to provide some defaults for various Matrix fields, those ought to be set within the fields, individually.</p>

<p>Otherwise, I think the solution you need is something like this:</p>

<pre><code>{# ... #}
{% set blocks = entry.matrixBlockField %}
{% for block in blocks %}

  {% set options = {
    'class': 'episode',
    'more': 'Listen to this interview...',
    'slug': craft.request.firstSegment,
    'linkUrl': interview.url
  } %}

  {% include '_includes/blocks/half-block.html' with {
    options: options,
    data: block
  } %}
{% endfor %}
{# ... #}
</code></pre>

<p>In your partial, you have a bit more work ahead of you, but the special behavior of Twig's <a href="http://twig.sensiolabs.org/doc/templates.html#other-operators" rel="nofollow noreferrer">ternary operator</a> should help:</p>

<pre><code>{{ data.field ?: options.fallbackField }}
</code></pre>

<p>I may be misunderstanding the problem, though— is there something about fetching the <code>MatrixBlockModel</code> elements that appears to be going wrong? As a general rule, I try and avoid using any Twig/Craft reserved words/terms for variable names, but I don't think that's the root of the problem here…</p>

CC BY-SA 3.0
2016-11-23T00:03:44.750Z
2016-11-23T00:03:44.750Z
August Miller
<p>I'm trying to pull in the contents of a matrixField block and merge it with some default info — </p>

<pre><code>{% set interviews = craft.entries.section('interviews') %}

{% for interview in interviews %}

    {% set blocks = interview.thumb %}
    {% for block in blocks %}

        {% set options = block|merge({
            'class': 'episode',
            'more': 'Listen to this interview...',
            'slug': craft.request.firstSegment,
            'linkUrl': interview.url,
        }) %}

        {% include '_includes/blocks/half-block.html' with { options: options } %}

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

<p>I get the error: <code>Key "body" for array with keys "id, enabled, archived, locale, localeEnabled, slug, uri, dateCreated, dateUpdated, root, lft, rgt, level, searchScore, fieldId, ownerId, ownerLocale, typeId, sortOrder, collapsed, class, more, reverse, linkUrl" does not exist</code></p>

<p>Why am I getting <code>block</code> with the values of the entry instead of that single block of type <code>thumb</code>?</p>

<p>(where <code>thumb</code> has a field called <code>body</code>)</p>

<p>I had tried <code>{% set block = interview.thumb.first() %}</code> instead of <code>{% set blocks = interview.thumb %}{% for block in blocks %}</code> but was trying to be more explicit to see if it made a difference.</p>

CC BY-SA 3.0
2016-11-23T00:07:01.043Z
To clarify— I think all those properties you see (I assume when trying to call `options.body` in the partial?) are common to _all_ elements in Craft, so it may look like an `EntryModel` but quack like a `MatrixBlockModel`… That's the expression, right?
August Miller
<matrix><include>
Merging options to pass with an include
# Merging options to pass with an include

(Asked by: username_0 on 2016-11-22)

I'm trying to pull in the contents of a matrixField block and merge it with some default info — 
{% set interviews = craft.entries.section('interviews') %}

{% for interview in interviews %}

    {% set blocks = interview.thumb %}
    {% for block in blocks %}

        {% set options = block|merge({
            'class': 'episode',
            'more': 'Listen to this interview...',
            'slug': craft.request.firstSegment,
            'linkUrl': interview.url,
        }) %}

        {% include '_includes/blocks/half-block.html' with { options: options } %}

    {% endfor %}
{% endfor %}

I get the error: Key "body" for array with keys "id, enabled, archived, locale, localeEnabled, slug, uri, dateCreated, dateUpdated, root, lft, rgt, level, searchScore, fieldId, ownerId, ownerLocale, typeId, sortOrder, collapsed, class, more, reverse, linkUrl" does not exist
Why am I getting block with the values of the entry instead of that single block of type thumb?
(where thumb has a field called body)
I had tried {% set block = interview.thumb.first() %} instead of {% set blocks = interview.thumb %}{% for block in blocks %} but was trying to be more explicit to see if it made a difference.

**Tags:** matrix, include
> **Comments:**
> **username_1**: To clarify— I think all those properties you see (I assume when trying to call `options.body` in the partial?) are common to _all_ elements in Craft, so it may look like an `EntryModel` but quack like a `MatrixBlockModel`… That's the expression, right?  

---

## 1 answers

### Answer by username_1 on 2016-11-23. Score: 2

I suspect this isn't so much a problem with the strategy as the implementation of the MatrixBlockModel, which is the object type you're trying to merge with a standard Twig "object" or associative array (not sure exactly what Twig uses, behind the scenes).
If you're trying to provide some defaults for various Matrix fields, those ought to be set within the fields, individually.
Otherwise, I think the solution you need is something like this:
{# ... #}
{% set blocks = entry.matrixBlockField %}
{% for block in blocks %}

  {% set options = {
    'class': 'episode',
    'more': 'Listen to this interview...',
    'slug': craft.request.firstSegment,
    'linkUrl': interview.url
  } %}

  {% include '_includes/blocks/half-block.html' with {
    options: options,
    data: block
  } %}
{% endfor %}
{# ... #}

In your partial, you have a bit more work ahead of you, but the special behavior of Twig's ternary operator should help:
{{ data.field ?: options.fallbackField }}

I may be misunderstanding the problem, though— is there something about fetching the MatrixBlockModel elements that appears to be going wrong? As a general rule, I try and avoid using any Twig/Craft reserved words/terms for variable names, but I don't think that's the root of the problem here…


---

