Skip to content

Pattern Overrides epic (WordPress 6.5) #53705

@glendaviesnz

Description

@glendaviesnz
Contributor

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

V1 (Completed)

Pattern override tasks

Block Binding Intergration

Bugs

Follow Ups

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)
    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

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

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

  • 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?

Metadata

Metadata

Assignees

No one assigned

    Labels

    [Feature] PatternsA collection of blocks that can be synced (previously reusable blocks) or unsynced[Feature] Synced PatternsRelated to synced patterns (formerly reusable blocks)[Type] EnhancementA suggestion for improvement.[Type] IterationScoped iteration of an effort from a tracking issue or overview issue ideally for a major release.

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @draganescu@youknowriad@colorful-tones@getdave@talldan

        Issue actions

          Pattern Overrides epic (WordPress 6.5) · Issue #53705 · WordPress/gutenberg