[mattheu]

The gap

The $context param passed to apply_query_preset passes some data, but it would be great if it just passed the full WP_Block object. (In all honesty, I'm not sure why the old code passes a property called block that contains pagination data. But I don't want to break anything using this)

Reson for this - a preset can't read block context: no termId/taxonomy inside a Term Template, no postId, nothing core puts there. $context['block'] looks like it should be the block and isn't — it is a two-key array of perPage and page.

The fix

Carry the block in the context array that already exists, as block_instance:

$term_id = $context['block_instance']?->context['termId'] ?? 0;

No signature change. The callback is still function ( array $query_vars, array $context ): array, so every preset already registered keeps working without being touched.

Not named block — that key is taken and presets read it, so renaming it is breaking and out of scope. block_instance matches the "Block instance" vocabulary already in the file's docblocks, and says out loud what the older key isn't.

modify_rest_query_for_preset() sets it to null explicitly rather than omitting the key, so the context has one shape in both paths and a preset can read it with ?-> and no isset() check.

$block is null on REST

The editor preview fetches from the collection endpoint rather than rendering the block, so there is no instance to carry. That is inherent, not a gap being papered over: a preset depending on block context behaves differently in the preview from the front end, and the README says so plainly.

post_id now prefers the block's context

post_id was get_the_ID(). It is now $block->context['postId'], falling back to get_the_ID().

In practice these are the same value. Core's post-template sets the context from the global post:

$post_id = get_the_ID();
$filter_block_context = static function ( $context ) use ( $post_id, $post_type ) {
	$context['postId'] = $post_id;

So inside a Query Loop the two agree by construction, and where there is no post context at all — an archive, a header, a footer — the fallback preserves today's behaviour exactly.

They diverge only if something has moved the global post without the block context following: a stray setup_postdata(), or a secondary WP_Query running the_post() without a reset, before the loop renders. In that case the block context is the correct post and the old behaviour was the bug.

It is its own commit (Presets: take post_id from the block, not the global loop) if you would rather weigh it separately.

Testing instructions

• npm run test:php — exit 0. Runs the existing exclusion planner tests (27 checks) plus the new tests/php/query-presets-test.php (10 checks), which drives the real inc/query-presets.php against stubs: the block reaches the callback through $context['block_instance'], is null on REST with the key still present, a preset can read termId off it, $context['block'] is still pagination metadata, and post_id prefers block context over the global.
• Negative controls, both run: deleting 'block_instance' => $block fails 2 checks; reverting post_id to get_the_ID() fails 1.
• composer install && vendor/bin/phpcs — exit 0.
• Playwright e2e is unchanged and was not run. No fixture added to tests/mu-plugins/test-query-presets.php: the block instance has no frontend-observable effect query-presets.spec.js could assert without inventing one, so an unasserted fixture would be noise.

No version bump (the release workflow stamps __VERSION__), no built assets.

🤖 Generated with Claude Code

[github-actions]

Playwright test results — WP 7.1

 26 passed

Details

 26 tests across 8 suites
 1 minute, 50 seconds
 dad51f3

[github-actions]

Playwright test results — WP 7.0

 26 passed

Details

 26 tests across 8 suites
 1 minute, 54 seconds
 dad51f3

[github-actions]

Playwright test results — WP 6.9

 26 passed

Details

 26 tests across 8 suites
 1 minute, 31 seconds
 dad51f3

[roborourke]

@mattheu is this one still something you can pursue? Sounds like a useful update

[mattheu]

@roborourke This is ready to go actually. I'd like to get it in as it would let me simplify some code I have on a project.

Whilst I don't love that we now pass both 'block' which is an array of data e.g. pagination (legacy behaviour) and block_instance which is the actual block, this does maintain backwards compatibility. A quick scan of our Github repos it doesn't look like anyone is using this, but I realise there are projects not within our org so I think it's safest to do it like this.

[roborourke]

nice to have the extended docs as well, cheers Matt