Summary
Category Link blocks in the Navigation block show "Missing Category" in the Site Editor on WP.com Atomic sites when the Jetpack blocks module is active and the navigation contains multiple category links. The front end renders correctly.
Root cause
The Site Editor resolves core/term-data block bindings by firing individual /wp/v2/categories/<id>?context=edit REST API calls for each bound term. When the Jetpack blocks module is active, the editor JS stack loads differently, and the concurrent authenticated REST requests fail with HTTP 428 (Precondition Required) and rest_forbidden_context on WP.com Atomic.
The issue scales with the number of category links. A small number of categories may work fine, but as more are added, the concurrent REST calls begin failing.
Steps to reproduce
- WP.com Atomic site with Jetpack blocks module enabled
- Create a Navigation block with multiple Category Link blocks (these use
core/term-data block bindings)
- Open the Site Editor
- Category links show "Missing Category" in the sidebar/editor
Disabling the Jetpack blocks module resolves the issue.
Expected behavior
Category Link blocks should display correctly in the Site Editor regardless of how many categories are in the navigation.
Evidence
- Console log shows all
/wp/v2/categories/<id>?context=edit requests returning 428
wp_pattern_category and help-center endpoints also fail with 428 (broad auth failure)- Server-side capabilities are correct (
edit_term: true, manage_categories: true)
core/post-data bindings (e.g. post date) work fine since they don't make separate REST calls- Jetpack connection is healthy
- Reproduced on multiple sites
Where the fix likely belongs
This sits at the intersection of three layers:
- WP.com Atomic: nonce/auth rate limiting may be too aggressive for concurrent REST calls from the editor
- WordPress core / Gutenberg:
core/term-data block binding source fires individual REST calls per term instead of batching them
- Jetpack blocks module: loading the full block editor JS stack changes how REST requests are authenticated, triggering the failure
Workaround
Disabling the Jetpack blocks module resolves the display issue without modifying site content.
Related
Summary
Category Link blocks in the Navigation block show "Missing Category" in the Site Editor on WP.com Atomic sites when the Jetpack blocks module is active and the navigation contains multiple category links. The front end renders correctly.
Root cause
The Site Editor resolves
core/term-datablock bindings by firing individual/wp/v2/categories/<id>?context=editREST API calls for each bound term. When the Jetpack blocks module is active, the editor JS stack loads differently, and the concurrent authenticated REST requests fail with HTTP 428 (Precondition Required) andrest_forbidden_contexton WP.com Atomic.The issue scales with the number of category links. A small number of categories may work fine, but as more are added, the concurrent REST calls begin failing.
Steps to reproduce
core/term-datablock bindings)Disabling the Jetpack blocks module resolves the issue.
Expected behavior
Category Link blocks should display correctly in the Site Editor regardless of how many categories are in the navigation.
Evidence
/wp/v2/categories/<id>?context=editrequests returning 428wp_pattern_categoryandhelp-centerendpoints also fail with 428 (broad auth failure)edit_term: true,manage_categories: true)core/post-databindings (e.g. post date) work fine since they don't make separate REST callsWhere the fix likely belongs
This sits at the intersection of three layers:
core/term-datablock binding source fires individual REST calls per term instead of batching themWorkaround
Disabling the Jetpack blocks module resolves the display issue without modifying site content.
Related