<p>When relational fields (entries, assets, etc) are eager-loaded, they either return an array of elements (Craft 3) or a <a href="https://laravel.com/docs/10.x/collections" rel="nofollow noreferrer">Collection</a> (Craft 4). Neither of those are possible to paginate using the <code>{% paginate %}</code> tag, which needs an <a href="https://craftcms.com/docs/4.x/element-queries.html" rel="nofollow noreferrer">element query</a> to work with (i.e. what relational fields return <em>without</em> eager loading).</p>
<p><strong>This means that eager-loading the <code>entry.faq</code> Entries field isn't possible in this case,</strong> and you should ignore this particular recommendation from Blitz.</p>
<p>It's worth mentioning that Blitz Recommendations are just hints; all the plugin does is let you know about any element queries that aren't eager-loaded. It's up to you to evaluate each of those queries to decide if eager-loading is a) technically feasible and b) a good idea in the first place.</p>
<p>Towards that final point, it's important to know that <strong>eager-loading only offers a potential performance improvement when it solves an N+1 issue (see <a href="https://craftcms.com/docs/4.x/dev/eager-loading-elements.html" rel="nofollow noreferrer">the official docs</a> for an example).</strong> This means that eager-loading a <em>single</em> element's relations (like your <code>entry</code> route variable's <code>faq</code> field), isn't actually going to be more performant. In fact, in such cases eager-loading might even be a little bit <em>slower</em> due to the fact that it adds a bit of overhead (and there isn't any gain to make up for it).</p>
<p>Going back to the pagination: if your <code>faq</code> entries also happen to have relational fields themselves (for example, an <code>image</code> Assets field), <em>that</em> could potentially represent an N+1 issue. And if that's the case, you can still use the <code>{% paginate %}</code> tag to query for the <code>faq</code> entries <em>and</em> eager-load those entries' images to avoid the N+1; you just need to make sure that you're eager-loading the right thing, i.e. the <code>faq</code> entries' <code>image</code> field, and not the <code>faq</code> entries themselves:</p>
<pre><code>{% paginate entry.faq.with(['image']) as pageInfo, pageItems %}

{% for faqEntry in pageItems %}
    {% set image = faqEntry.image.one() %}{# N+1 issue avoided due to the entries' image field being eager-loaded #}
{% endfor %}
</code></pre>

CC BY-SA 4.0
2023-04-19T22:27:04.377Z
2023-04-19T22:34:06.780Z
2023-04-19T22:34:06.780Z
Mats Mikkel Rummelhoff
<p>We have this <code>entry</code> with a field called <code>faq</code> which can contain multiple <code>faq entries</code>. We paginate this field with this code:</p>
<pre><code>{% paginate entry.faq as pageInfo, pageItems %}
</code></pre>
<p>Now Blitz Recomendations says we should <code>Eager-load the entry route variable.</code> and the example it gives is:</p>
<pre><code>Eager-load elements of the FAQ field on the auto-injected route variable entry, for example:
{% do craft.app.elements.eagerLoadElements(className(entry), [entry], ['faq']) %}
</code></pre>
<p>So I tried:</p>
<pre><code>{% do craft.app.elements.eagerLoadElements(className(entry), [entry], ['faq']) %}
{% paginate entry.faq as pageInfo, pageItems %}
</code></pre>
<p>which returns this error: <code>[web.ERROR] [TypeError] craft\helpers\Template::paginateQuery(): Argument #1 ($query) must be of type yii\db\QueryInterface, craft\elements\ElementCollection given</code></p>
<p>What am I missing here?</p>

<entry><entries-field><eager-loading><paginate>
Eager-load entry field that is being paginated
# Eager-load entry field that is being paginated

(Asked by: username_0 on 2023-04-19)

We have this entry with a field called faq which can contain multiple faq entries. We paginate this field with this code:
{% paginate entry.faq as pageInfo, pageItems %}

Now Blitz Recomendations says we should Eager-load the entry route variable. and the example it gives is:
Eager-load elements of the FAQ field on the auto-injected route variable entry, for example:
{% do craft.app.elements.eagerLoadElements(className(entry), [entry], ['faq']) %}

So I tried:
{% do craft.app.elements.eagerLoadElements(className(entry), [entry], ['faq']) %}
{% paginate entry.faq as pageInfo, pageItems %}

which returns this error: [web.ERROR] [TypeError] craft\helpers\Template::paginateQuery(): Argument #1 ($query) must be of type yii\db\QueryInterface, craft\elements\ElementCollection given
What am I missing here?

**Tags:** entry, entries-field, eager-loading, paginate


---

## 1 answers

### Answer by username_1 on 2023-04-19. Score: 3 | Accepted answer

When relational fields (entries, assets, etc) are eager-loaded, they either return an array of elements (Craft 3) or a Collection (Craft 4). Neither of those are possible to paginate using the {% paginate %} tag, which needs an element query to work with (i.e. what relational fields return without eager loading).
This means that eager-loading the entry.faq Entries field isn't possible in this case, and you should ignore this particular recommendation from Blitz.
It's worth mentioning that Blitz Recommendations are just hints; all the plugin does is let you know about any element queries that aren't eager-loaded. It's up to you to evaluate each of those queries to decide if eager-loading is a) technically feasible and b) a good idea in the first place.
Towards that final point, it's important to know that eager-loading only offers a potential performance improvement when it solves an N+1 issue (see the official docs for an example). This means that eager-loading a single element's relations (like your entry route variable's faq field), isn't actually going to be more performant. In fact, in such cases eager-loading might even be a little bit slower due to the fact that it adds a bit of overhead (and there isn't any gain to make up for it).
Going back to the pagination: if your faq entries also happen to have relational fields themselves (for example, an image Assets field), that could potentially represent an N+1 issue. And if that's the case, you can still use the {% paginate %} tag to query for the faq entries and eager-load those entries' images to avoid the N+1; you just need to make sure that you're eager-loading the right thing, i.e. the faq entries' image field, and not the faq entries themselves:
{% paginate entry.faq.with(['image']) as pageInfo, pageItems %}

{% for faqEntry in pageItems %}
    {% set image = faqEntry.image.one() %}{# N+1 issue avoided due to the entries' image field being eager-loaded #}
{% endfor %}


---

