Presets: carry the block instance, and the right post id, in the preset context

[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.

Behaviour change: post_id now follows the block

Worth reading rather than skimming — this is the one thing in here that can change an existing preset's output.

post_id was get_the_ID(), which reads global loop state. It is now $block->context['postId'], falling back to get_the_ID(). The block context is what core resolved for that specific block; the global post is whatever the outer loop happens to be on. On a singular template they agree. Where they diverge, a preset keying off post_id will now get a different post — the one it should have had, but a different one.

It is its own commit (Presets: take post_id from the block, not the global loop) if you want to 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, 53 seconds
 9f99e05

[github-actions]

Playwright test results — WP 7.0

 26 passed

Details

 26 tests across 8 suites
 1 minute, 50 seconds
 9f99e05

[github-actions]

Playwright test results — WP 6.9

 26 passed

Details

 26 tests across 8 suites
 1 minute, 33 seconds
 9f99e05