<p>Turns out my issue is because I am running 2 loops through <code>entry.timeline</code>: </p>

<ol>
<li>A <em>subset</em> of the field with only <code>subsection</code> blocks to generate a table of contents</li>
<li>The entire field contents with a mixture of both <code>subsection</code> and <code>item</code> block types.</li>
</ol>

<p>Craft 2 was totally OK with me defining a subset and <em>then</em> looping through the entire set, but with Craft 3, if the subset is defined first, it seems to <strong>persist</strong> when the second loop runs, even if the scope of the second loop is defined differently.</p>

<p>So my current solution is to have a template structured like this:</p>

<pre><code>{# Fetch the entire set first even though it will run second #}
{% set timelineItems = entry.timeline.all() %}

{# Fetch the subset second even though it will run first #}
{% set tocItems = entry.timeline.type('subsection').all() %}

{% for item in tocItems %}
    {# do subsetted ToC stuff #}
{% endfor %}

{% for row in timelineItems %}
    {# do entire timeline stuff #}
{% endfor %}
</code></pre>

<p>See <a href="https://github.com/craftcms/cms/issues/2160" rel="nofollow noreferrer">https://github.com/craftcms/cms/issues/2160</a> for more background, and <a href="https://docs.craftcms.com/v3/changes-in-craft-3.html#cloning-element-queries" rel="nofollow noreferrer">cloning element queries</a> in the docs.</p>

CC BY-SA 3.0
2018-04-17T20:39:35.803Z
Just to clarify: that's the normal and expected behavior since `entry.timeline` is a reference to an object of type `ElementQuery`. When you change certain criterias/properties of that object it won't magically reset them afterwards. You would need to clear the property
Robin Schambach
CC BY-SA 3.0
2018-04-17T22:11:56.447Z
Ok, thanks Robin. Because it was a non-issue in Craft 2 it was hard for the uninitiated like me to see that it _would_ be an issue in Craft 3. Is this behaviour explicitly mentioned in the docs? How does one "clear the property"?
Jonathan Schofield
CC BY-SA 3.0
2018-04-17T22:16:21.047Z
I now understand that I was running into this issue: https://github.com/craftcms/cms/issues/2160. And that there is a `clone()` function to address it.
Jonathan Schofield
CC BY-SA 3.0
2018-04-18T08:20:14.100Z
I now see that this issue is well explained in the 'Changes in Craft 3' section of the Docs under [cloning element queries](https://docs.craftcms.com/v3/changes-in-craft-3.html#cloning-element-queries). Easy to miss if you don't know what you are looking for, which is kind of inevitable with a complex product.
Jonathan Schofield
CC BY-SA 3.0
2018-04-17T20:12:08.010Z
2018-04-18T08:21:38.583Z
2018-04-18T08:21:38.583Z
Jonathan Schofield
<p><strong>Update:</strong> Now I know the cause of my problem, I have appended to the original question title to try and help other people stumbling across the same issue.</p>

<hr>

<p>I have a pending support ticket open with P&amp;T on this, but just wondering if anyone else has had a similar experience and might be able to point me in the right direction.</p>

<p>I have a development site running happily on Craft 2.6.3013. As a first foray into Craft 3 I thought I would upgrade it to Craft 3 in a dedicated folder and DB of my local setup.</p>

<p>All seemed to go fine. I worked through and eliminated deprecation errors in my 2 well developed templates. </p>

<p>But one of the templates utilises a Matrix field with 2 block types -- <code>subsection</code> and <code>item</code> -- and only <code>subsection</code> rows are publishing.</p>

<p>The 20 rows originally in the field (in its singles entry) are all there in the back end, and their respective types show up as they should there: 5 for <code>subsection</code> and 15 for <code>item</code>.</p>

<p>But a simplified front end loop of: </p>

<p><code>&lt;ul&gt;
    {% for row in entry.timeline.all() %}
        &lt;li&gt;{{ row.type }}&lt;/li&gt;
    {% endfor %}
&lt;/ul&gt;</code></p>

<p>…only produces the following outcome:</p>

<p><code>&lt;ul&gt;
    &lt;li&gt;subsection&lt;/li&gt;
    &lt;li&gt;subsection&lt;/li&gt;
    &lt;li&gt;subsection&lt;/li&gt;
    &lt;li&gt;subsection&lt;/li&gt;
    &lt;li&gt;subsection&lt;/li&gt;
&lt;/ul&gt;</code></p>

CC BY-SA 3.0
2018-04-12T13:53:04.343Z
With devMode set to true, what does this print: {{ dump(entry.timeline.all()) |raw }}?
Paul
CC BY-SA 3.0
2018-04-12T17:17:13.550Z
I get a super long array with 5 items: `array(5) { [n]=> … { … } }`. ~87k characters in total. I'm not sure what I should be seeing but it's internal structure looks a bit questionable. There is lots of nested `"_nextElement"` and various instances of `*RECURSION*`.
Jonathan Schofield
CC BY-SA 3.0
2018-04-12T17:31:37.577Z
Applying this `dump` to my Craft 2.6 instance, which I still have, I can see `*RECURSION*` in there too, so I guess that is not a cause for concern. Crucially though, the array is 20 items as I would expect.
Jonathan Schofield
CC BY-SA 3.0
2018-04-12T17:34:29.773Z
Strange. Can’t really tell you more without seeing Craft and code ...
Paul
CC BY-SA 3.0
2018-04-12T17:36:41.087Z
Sure. Thanks for the debugging suggestion. Good to see the internal workings! I have sent my db to P&T. Think they are looking at it.
Jonathan Schofield
<matrix><craft3><elementcriteriamodel><block-types>
Missing Matrix row types on output after upgrade to Craft 3 (subsetting and cloning ElementQueries)
# Missing Matrix row types on output after upgrade to Craft 3 (subsetting and cloning ElementQueries)

(Asked by: username_0 on 2018-04-11)

**Update:** Now I know the cause of my problem, I have appended to the original question title to try and help other people stumbling across the same issue.

---

I have a pending support ticket open with P&T on this, but just wondering if anyone else has had a similar experience and might be able to point me in the right direction.

I have a development site running happily on Craft 2.6.3013. As a first foray into Craft 3 I thought I would upgrade it to Craft 3 in a dedicated folder and DB of my local setup.

All seemed to go fine. I worked through and eliminated deprecation errors in my 2 well developed templates.

But one of the templates utilises a Matrix field with 2 block types -- `subsection` and `item` -- and only `subsection` rows are publishing.

The 20 rows originally in the field (in its singles entry) are all there in the back end, and their respective types show up as they should there: 5 for `subsection` and 15 for `item`.

But a simplified front end loop of:

`{% for row in entry.timeline.all() %}* {{ row.type }}
{% endfor %}`

…only produces the following outcome:

`* subsection
* subsection
* subsection
* subsection
* subsection`

**Tags:** matrix, craft3, elementcriteriamodel, block-types
> **Comments:**
> **username_1**: With devMode set to true, what does this print: {{ dump(entry.timeline.all()) |raw }}?  
> **username_0**: I get a super long array with 5 items: `array(5) { [n]=> … { … } }`. ~87k characters in total. I'm not sure what I should be seeing but it's internal structure looks a bit questionable. There is lots of nested `"_nextElement"` and various instances of `*RECURSION*`.  
> **username_0**: Applying this `dump` to my Craft 2.6 instance, which I still have, I can see `*RECURSION*` in there too, so I guess that is not a cause for concern. Crucially though, the array is 20 items as I would expect.  
> **username_1**: Strange. Can’t really tell you more without seeing Craft and code ...  
> **username_0**: Sure. Thanks for the debugging suggestion. Good to see the internal workings! I have sent my db to P&T. Think they are looking at it.  

---

## 1 answers

### Answer by username_0 on 2018-04-17. Score: 1

Turns out my issue is because I am running 2 loops through entry.timeline: 

A subset of the field with only subsection blocks to generate a table of contents
The entire field contents with a mixture of both subsection and item block types.

Craft 2 was totally OK with me defining a subset and then looping through the entire set, but with Craft 3, if the subset is defined first, it seems to persist when the second loop runs, even if the scope of the second loop is defined differently.
So my current solution is to have a template structured like this:
{# Fetch the entire set first even though it will run second #}
{% set timelineItems = entry.timeline.all() %}

{# Fetch the subset second even though it will run first #}
{% set tocItems = entry.timeline.type('subsection').all() %}

{% for item in tocItems %}
    {# do subsetted ToC stuff #}
{% endfor %}

{% for row in timelineItems %}
    {# do entire timeline stuff #}
{% endfor %}

See https://github.com/craftcms/cms/issues/2160 for more background, and cloning element queries in the docs.

> **Comments:**
> **username_2**: Just to clarify: that's the normal and expected behavior since `entry.timeline` is a reference to an object of type `ElementQuery`. When you change certain criterias/properties of that object it won't magically reset them afterwards. You would need to clear the property  
> **username_0**: Ok, thanks Robin. Because it was a non-issue in Craft 2 it was hard for the uninitiated like me to see that it _would_ be an issue in Craft 3. Is this behaviour explicitly mentioned in the docs? How does one "clear the property"?  
> **username_0**: I now understand that I was running into this issue: https://github.com/craftcms/cms/issues/2160. And that there is a `clone()` function to address it.  
> **username_0**: I now see that this issue is well explained in the 'Changes in Craft 3' section of the Docs under [cloning element queries](https://docs.craftcms.com/v3/changes-in-craft-3.html#cloning-element-queries). Easy to miss if you don't know what you are looking for, which is kind of inevitable with a complex product.  

---

