Answers.Body: <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>
  
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-17T20:39:35.803Z
Answers.Text: 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
Answers.UserDisplayName: Robin Schambach
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-17T22:11:56.447Z
Answers.Text: 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"?
Answers.UserDisplayName: Jonathan Schofield
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-17T22:16:21.047Z
Answers.Text: 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.
Answers.UserDisplayName: Jonathan Schofield
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-18T08:20:14.100Z
Answers.Text: 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.
Answers.UserDisplayName: Jonathan Schofield
Answers.ContentLicense: CC BY-SA 3.0
Answers.CreationDate: 2018-04-17T20:12:08.010Z
Answers.LastActivityDate: 2018-04-18T08:21:38.583Z
Answers.LastEditDate: 2018-04-18T08:21:38.583Z
Answers.UserDisplayName: Jonathan Schofield
Body: <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>
  
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-04-12T13:53:04.343Z
Comments.Text: With devMode set to true, what does this print: {{ dump(entry.timeline.all()) |raw }}?
Comments.UserDisplayName: Paul
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-04-12T17:17:13.550Z
Comments.Text: 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*`.
Comments.UserDisplayName: Jonathan Schofield
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-04-12T17:31:37.577Z
Comments.Text: 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.
Comments.UserDisplayName: Jonathan Schofield
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-04-12T17:34:29.773Z
Comments.Text: Strange. Can’t really tell you more without seeing Craft and code ...
Comments.UserDisplayName: Paul
Comments.ContentLicense: CC BY-SA 3.0
Comments.CreationDate: 2018-04-12T17:36:41.087Z
Comments.Text: 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.
Comments.UserDisplayName: Jonathan Schofield
Tags: <matrix><craft3><elementcriteriamodel><block-types>
Title: Missing Matrix row types on output after upgrade to Craft 3 (subsetting and cloning ElementQueries)
ThreadText: # 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:
  
  `<ul>
  {% for row in entry.timeline.all() %}
  <li>{{ row.type }}</li>
  {% endfor %}
  </ul>`
  
  …only produces the following outcome:
  
  `<ul>
  <li>subsection</li>
  <li>subsection</li>
  <li>subsection</li>
  <li>subsection</li>
  <li>subsection</li>
  </ul>`
  
  **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`:
  
  1. A *subset* of the field with only `subsection` blocks to generate a table of contents
  2. 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](https://docs.craftcms.com/v3/changes-in-craft-3.html#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 username_2. 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.  
  
  ---
  
  