• Part of Block API #41236.
• Related to Block Bindings API iteration for 6.5 #54536.

N.B. Previously referred to as partially synced patterns.

What problem does this address?

Currently when adding a synced pattern all parts of that pattern are synced across every instance, so changes in any part of the pattern are reflected across as instances of the pattern.

It has been discussed in a number of places (#48458, #50456 ) that patterns would be much more useful/flexible if parts of them, particularly the layout and styling components, could be locked and synced across instances while allowing parts of the content to be updated independently.

An example workflow for a user could be a partially synced 'Recipe' pattern. A user could insert this pattern into multiple posts and any content (Ingredients, Steps) would be local to the post rather than synced in the pattern itself. The user would also be able to go back and modify the design of the recipe pattern, and this should have no effect on their content.

What is your proposed solution?

A number of potential solutions were discussed here with a few proofs of concepts. The current thinking is to use of the proposed block bindings api to implement partial syncing, since there's some overlap in requirements. The block bindings API mostly describes a way to use external data for a block attribute value (e.g. using a custom field for paragraph content). For patterns, child blocks of a pattern block could get and set their attribute values to the pattern block instance itself. This way, different instances of patterns could inject different data into the same pattern.

See the current prototype in #56235.

Tasks

Suggested enhancements/explorations

• Consider how future features like shuffling might work
• Reconsider using Ids to bind blocks, the data stored in the pattern block should be more readable/interpretable - draft PR using name instead of id
• When a pattern is redesigned, there's a chance a user will modify blocks/attributes in a way that they become disconnected from the instances of a pattern (e.g. renaming the block to something different). Explore ways to prevent/warn a user about these risks.
• Change the override attribute name to content - (PR - #58596)
• Patterns: change info to "Overrides enabled"
• Look into storing the block name as metadata in the overrides data (PR - #58715)

Block specific issues

Image Block

Supported attributes: url, id, title, alt

• Adding an image that has a caption set in the media library displays the caption, even when the original pattern has been designed to hide captions. (it disappears after a refresh though)
• Pattern Overrides: Image block doesn't render on frontend when it's saved as a placeholder in a pattern
• Caption is not supported as a block bindings attribute, but can be edited in the UI (when toggled on in the original pattern) (PR: #58916)
• Pattern Overrides: Image id attribute can mismatch the image url attribute, which results in buggy behavior
• Alt and title are supported attributes, but are not editable in the UI (they're hidden by content only mode) (PR: #58998)
• Link is not supported as a block bindings attribute, but can be edited in the UI (PR: Disable overriding links of images inside pattern instances #58660)

Button Block

Supported attributes: text, url

• Link (url) attribute is supported, but related attributes linkTarget and rel are not supported as block bindings attributes, but are still editable in the UI (PR: Support button's link settings for Pattern Overrides #58587)

Heading block

Supported attributes: content

• Heading level isn't supported, could/should it be?

Paragraph block

Supported attributes: content
No known issues

General Bugs

• Lock icons display in List View for a pattern's inner blocks (even though the blocks are still content editable)
• Pattern override: individual binding attributes are saved in the pattern markup and don't auto-update
• While testing Pattern Overrides, I Found conflict with Live Collaboration and offline persistence mode
• Nesting one overridden pattern within another causes nested pattern to crash - (PR: Patterns: Prevent exception if a pattern with overrides is nested in another pattern #58359)

Code quality

• Explore better ways to show/hide block UI that doesn't involve hard-coding references to 'core/block' in the codebase, AKA address where blockEditingMode doesn't quite work for the pattern block (see Patterns: edit source pattern in focus mode in post and site editors #57036 (comment))

Future

• Features like pattern overrides and block bindings have limited control over block UI
• As part of the block binding API, users can denote connections to different sources (e.g. custom fields, other post values, custom data sources). To declare a pattern override, the user also defines connections. Given they're separate UIs, some thought needs to go into what happens when a user attempts to connect a pattern override on a block that's already connected to a custom field—should it overwrite it, should it be prevented, how is the user made aware of the risk/outcome.
• At the moment the API will work for one block at a time. A solution will be needed for lists, galleries or anything that requires a series/array of bound blocks. (see Add new mode to contentOnly locking to allow insertion of new inner blocks #52018 for similar challenges with contentOnly mode). One solution explored here [PoC] Patterns: try partial syncing of inner blocks #56348
• Some exploration might be need around how block deprecations will work (i.e. if a block attribute name changes)
• If a user completely deletes a source pattern, they will potentially lose content everywhere the pattern is used. Are there ways to restore this content, maybe offering a flow similar to block recovery?