Conversation
Suggested posts on a single post template need to leave out the post being read. post__not_in scales poorly, so the loop's first page fetches one extra post and drops the current one in PHP. Later pages and pagination counts still use post__not_in so offsets stay exact.
Playwright test results — WP 6.9
Details
|
Playwright test results — WP 7.0
Details
Failed testschromium › elasticpress-toggle.spec.js › ElasticPress Toggle › should show the Use ElasticSearch toggle in the panel |
Playwright test results — WP 7.1
Details
Failed testschromium › elasticpress-toggle.spec.js › ElasticPress Toggle › should show the Use ElasticSearch toggle in the panel |
The database is only reset once per run, so the post and its query loop showed up in the posts per page and query preset specs' listings.
|
Closing in favour of #31, which I've tested and does the same thing more broadly. |
2 participants
Suggested posts on a single post template should leave out the post being read, and the Query Loop block has no way to do that. Sites end up writing their own
query_loop_block_query_varsfilter withpost__not_in, which VIP's code scanner flags because NOT IN queries scale poorly, creating temporary tables and memory load on the database server.This adds an "Exclude current post" toggle to the Extra Query Loop Settings, shown on loops that don't inherit the query. When viewing post A, post A is left out and the loop still shows its full number of posts.
The loop's first page doesn't use NOT IN. It fetches one extra post and drops the current post, or the spare one, in PHP before the results are tracked as displayed. Page 2 onwards and the queries pagination blocks run to count pages still use
post__not_in, because fetching an extra post there would shift offsets and page counts. So only paginated loops pay for NOT IN, and a typical suggested posts loop never does. Loops that usepost__indrop the ID from that list instead.The setting does nothing in editor previews, since there's no current post there. "Exclude already displayed posts" could use the same extra fetch later, but it would need to fetch as many extra posts as are already shown, so I've left it out of this PR.
Why not extend "Exclude already displayed posts"? That setting tracks posts shown by earlier query loops, and the current post on a single template isn't shown by a loop. Counting it as displayed would change what existing loops show on single posts after an update, and it would tie two separate choices together: some loops want no repeats from earlier loops but can show the current post, and others the reverse.