Fix block editor rendering: query decoding and StrictMode

[adrianmomorales]

Summary

Two fixes for ACF block rendering in the Gutenberg editor:

1. Decode $query when sent as JSON string (acf_ajax_fetch_block)

The block editor JS may serialize the query parameter as a JSON string, but acf_ajax_fetch_block() assumes it is already a PHP array. On PHP 8.4 this causes a fatal TypeError at line 1099:

Cannot access offset of type string on string

The $block and $context parameters are already decoded with json_decode() (lines 1040-1046), but $query is not. This adds the same treatment.

2. Enable StrictMode flag in localized block editor data

The block editor JS already has code to handle React 18 StrictMode (mount → unmount → remount), gated behind acf.get('StrictMode'):

// acf-pro-blocks.js — V.setState()
(this.subscribed || acf.get('StrictMode')) && super.setState(e);

But the flag is never set — acf.get('StrictMode') always returns null. Without it, when React StrictMode remounts a block component, this.subscribed is false (set during unmount) and super.setState() is skipped. The block form HTML is fetched successfully but never rendered — the block shows an infinite spinner.

This adds 'StrictMode' => true to the localized data in acf_enqueue_block_assets().

Steps to reproduce

1. Use WordPress 6.9+ (React 18 StrictMode in the block editor)
2. Register any ACF block with acf_block_version: 2 and mode: edit
3. Insert the block in the editor
4. Block shows infinite spinner (fix 2), or on PHP 8.4 a 500 error (fix 1)

Test plan

• Insert an ACF block in the editor on PHP 8.4 — should render form without errors
• Insert an ACF block in the editor on WordPress 6.9+ — should render form without infinite spinner
• Verify block preview mode works correctly
• Verify block frontend rendering is unaffected

🤖 Generated with Claude Code

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @adrianmomorales.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[kraftbj]

Thanks for catching both of these — the query decoding fix follows the existing pattern nicely, and enabling the StrictMode flag is the right idea for WP 6.9+. A couple of items to address before merging.

[kraftbj]

This fix follows the existing pattern for $block and $raw_context above — nice.

Could you add a PHPUnit test for this? Something like a test in tests/phpunit/ that calls acf_ajax_fetch_block() (or the relevant helper) with query as a JSON string and verifies it gets decoded to an array without error. The $block and $raw_context decoding paths above would also benefit from tests eventually, but covering this new path would be a good start.

[kraftbj]

This enables the StrictMode code path on all WP versions. In acf-pro-blocks.js, the setState gate is this.subscribed || acf.get('StrictMode') — so setting this to true means setState is always called regardless of subscribed state, even on WP < 6.9 where React StrictMode is not active.

Would it make sense to gate this on WP 6.9+? Something like:

'StrictMode' => version_compare( $GLOBALS['wp_version'], '6.9', '>=' ),

That way the behavior on older WP versions stays unchanged, and we only opt into the StrictMode path where React actually uses it.