Overview

This Issue summarizes the key concerns raised in PR #72165 regarding the "shape" of block bindings, particularly around navigation blocks and the removal of the core/entity binding source.

Core Issue: Lack of Explicit Binding Configuration API

The fundamental problem is that the current block bindings system lacks an explicit API for specifying how binding sources should obtain entity data. This has led to several interconnected concerns:

The Current Problematic Approach

Current markup shape:

<!-- wp:navigation-link {"label":"test","type":"page","id":123,"url":"http://wp-src.test/test/","kind":"post-type","metadata":{"bindings":{"url":{"source":"core/entity","args":{"key":"url"}}}}} /-->

Issues with this approach:

1. Implicit assumptions: The binding source hardcodes navigation block detection instead of having explicit configuration
2. Data redundancy: Entity ID stored in both block attributes (id:123) and potentially in binding configuration
3. Redundant/incorrect data: The url field becomes stale when the entity URL changes
4. No migration path: Hardcoded exceptions will become permanent due to existing markup in the wild

Proposed Solutions and Concerns

@scruffian's proposed markup shape:

<!-- wp:navigation-link {"type":"page","kind":"post-type","metadata":{"bindings":{"url":{"source":"core/entity","args":{"key":"url", "id":123 }}}}} /-->

Key improvements:

• Remove redundant url from block attributes
• Make entity ID explicit in binding configuration
• Support multiple bindings from same entity

Alternative API proposals:

1. @talldan's bindingsContext approach:

   bindingsContext: {
       'core/post-data': {
           postType: 'post',
           id: 123,
       }
   }

2. @ockham's providesContext consideration: Using WordPress's existing context system

The Technical Debt Problem

@talldan's warning:

"I can't think of a way that you'll migrate to a proper solution in the future. I think the temporary code will become permanent because you might always have some navigation links in post content that are configured this way."

@getdave's acknowledgment: The hardcoded exceptions will likely become permanent due to existing markup in the wild.

@ockham's perspective:

"We'll always have to support the 'old' attribute format, since people will have that sort markup persisted in their block templates. This is a recurring and well-known problem with GB -- even if we add block deprecations and migrations, they only run if the markup is edited and saved in the editor."

Proposed Solutions

Short-term (6.9)

• Hardcoded exception for navigation blocks in core/post-data and core/term-data sources
• Remove core/entity binding source to eliminate redundancy
• Accept that this code will likely become permanent
• **@jeryj's: Design the simple API but gate it to only Navigation Blocks initially so the gating can be removed if we get it right before the 6.9 release

Long-term (7.0+)

• Design proper binding configuration API
• Consider metadata.bindingsContext approach
• Support explicit entity ID specification in binding configuration
• Address redundancy in markup

Key Takeaways

1. Lack of explicit API - Current approach relies on implicit assumptions rather than clear configuration
2. Data redundancy - Entity ID stored in both block attributes and binding configuration
3. No migration path - Temporary hardcoded solutions becoming permanent
4. Poor markup shape - Redundant and potentially incorrect data in serialized markup
5. Missing binding configuration syntax - No established way to specify entity data source in bindings

The consensus seems to be that while the current approach works for 6.9, it creates technical debt that will be difficult to remove due to existing markup in the wild.

References

• PR #72165 - Remove core/entity binding in favour of post and term data bindings
• Issue #72059 - Eliminate Entity Block Binding Source Redundancy
• PR #71002 - Discussion about binding configuration API