Share examples of how you hope to use synced pattern overrides

[annezazu]

Pulling from this last week's hallway hangout on WordPress 6.5, I wanted to create a place where folks could share feedback about the ways in which they imagine using pattern overrides to help shape the present and future of this feature.

What is the feature?

Pattern overrides (previously called partial sync patterns) would allow users to ensure a synced layout and style across patterns while allowing each instance of the pattern to have customized content. This allows for consistency in design across different pieces of content. For instance, consider a testimonial pattern in a grid. With the enhanced feature, someone can insert this testimonial pattern into multiple posts, ensuring that the layout and styling components, such as the overall design of the recipe card, remain consistent across instances. Meanwhile, the content, such as Name, Image, and Role, would be local to each instance allowing for individual customization. Additionally, folks would then be able to revisit and modify the design of the overall testimonial pattern without affecting the content in existing instances.

How do you imagine using this? What blocks are a must have for supporting overrides for your workflow?

Currently, just the paragraph block is supported for overriding capabilities with plans to add support for heading, button, and image blocks (help test!). Support has to be added on a block by block basis so it's critical that we add support for the right blocks that are most high impact. Dive into the present and consider what blocks would be critical for you. Jump ahead to the future and share how you imagine using this going forward!

[fabiankaegy]

Thanks for putting this discussion together. I'm not sure I can come up with a solution for what a good MVP is. All I can do is share some of the things I am hoping for out of this feature. Kind of the promise that it had for me from the moment I first heard about the idea of then called partially synced patterns.

Example 1

I would like to define sections like this where I have a group with a background color, some padding, a heading, query loop, and a button.

What I want editors to be able to override is the heading text, Button text & link (ideally including things like the rel attribute) and then also the query options of the query loop block. So that an editor can change the taxonomy filter, for example. But the actual post template within the query should be synced so that I can globally update the styling of cards. Or change the number of columns the grid should have.

In an ideal world, I would even go so far as to defining the content of the post template block as a synced pattern on it's own so that I can always globally update how cards are styled throughout the site.

Example 2

This is a nice example of a card grid from Olliewp (thanks @mikemcalister). The speciailty here ist that I would want to allow users to add / remove individual cards here. But not change the design within them.

Also instead of the image block I would ideally like to be able to use my own custom Icon block for this which allows me to use an SVG from a bundled icon library. (Similar to https://nickdiego.com/projects/icon-block/). But that would mean I as a developer would need to have access to register custom block bindings.

Example 3

Another one stolen from ollie is this pricing section here. Ideally I would want an editor to be able to add / remove additional list items in the list block, and it would be super cool to pair this with the new section specific styles #57537 so that even in the locked mode here a user could still choose between the light and dark style variant. Without for example changing the border radius of the group.

Additional Insights

Something that I originally had in mind here was the ability to manually control which attributes would be exposed to be overwitten. That the foundation of this feature would not be the contentOnly mode but instead that we could essentially allow for any attribute / inner block area to get exposed.

This would kind of allow this feature to replace a lot of custom development work.

Closing Thoughts

I think what I'm trying to share here is that in my eyes I had hoped this feature would be less coupled with the contentOnly mode because I don't think I would only even allow for content to be overwritten. I think the piece that I want to ensure I can sync across all my instance is structure. Whilst still allowing for selected settings / styles to be exposed. With the control for which settings / styles should be exposed living with the pattern author.

I don't want to remove all styling options from someone. On the contrary, I want to highlight the ones that actually allow the client to make meaningful changes between variations whilst also hiding a lot of the complexity from them. That is the main reason why we often fall back to custom block development.

I think the Section Specific styles are a great example. I don't see how those shouldn't be something I can expose to a user on a synced pattern. They can choose from a few preconfigured versions of the pattern. Whilst I can manage those style variations and the general structure in the main synced instance of the pattern.

Oh and as I mentioned before, ideally the source of truth for these patterns that allow overrides would not be in the DB but in a pattern file located in the theme :)

[fabiankaegy]

Another thing we often run into which would be great here is similar to the query loop in the first example we have a custom block called a Post Picker that allows us to display a hand picked post. This block stores the post type and id in attributes and manages the template exactly like the query loop block.

As a developer I would want to use this custom block in a pattern with overrides to only allow someone to change the post type & post id via a post picker.

This already works great in contentOnly mode because I can use the useBlockEditingMode hook or the older role: content in my attribute definition and it just works.

But for this to work here we would need to be able to access the block bindings API to add our custom attributes to the list of allowed bindings.

[bacoords]

I spent some time testing the synced pattern experiment for a project that could really use them and have been thinking about this:

I think what I would want with synced patterns are actually closer to an 'ACF Blocks' approach- essentially a container where I can make any changes to the design/layout, but where there might be a handful of blocks in the pattern that are essentially tied to a specific value (perhaps via a custom field).

Say your pattern has a number of blocks and decisions about layout & design. But for some of those blocks, they're clearly assigned to a specific custom field value on the post (or a maybe an attribute stored on the pattern-level, though this feels like a great use-case for postmeta).

So then in theory you could completely change, move, redesign, reconfigure that synced pattern, but because you've defined some of the internal blocks to pull that specific meta value from the individual post object (and your pattern itself defines the default values), you can basically do anything to the pattern itself. And then only the content of those specific blocks are editable in the post.

A basic example could be a CTA pattern. I want the design to be synced, I might want some of the blocks to be locked at the pattern (maybe a contact form or button), but then I want the user to be able to modify the content of the heading and paragraph text or an image block. Then globally I want to be able to completely rearrange, reorder, redesign the pattern, but ensure the post-specific values can still be pulled properly.

I understand there are other use cases for this. So maybe the actual best way to approach this specific use case I'm outlining is to just put more support behind the Block Bindings API, which could theoretically enable this type of functionality? #54536

[talldan]

@bacoords I think what you're describing should be possible with pattern overrides, though they don't save data to custom fields. Instead the data is saved with the attributes of the pattern block instance.

For 6.5 there should be support for headings, images, buttons and paragraphs, that should arrive in the Gutenberg plugin soon.

Bindings for custom fields should also be possible in a pattern for 6.5 (again for the same blocks), but I think what will be missing for 6.5 is being able to edit the custom field values from the block UI.

[bacoords]

Thanks for the clarification. It's good to hear that the patterns themselves will be able to store attributes- I think that's what I was wondering. It'll be interesting to see how those attributes are defined, if there is any control or UI for that.

[gregsullivan]

The dream scenario for me would be for this feature to work with patterns added by a theme. I create patterns as PHP files in the ./patterns folder of the themes I create. If I could use pattern overrides, that would allow me to update all instances of the pattern (aside from the overridden elements) simply by updating the PHP file.

(These are patterns using template locking to keep them consistent throughout the site.)

This would eliminate multiple existing pain points:

• During development, I can't refresh to view changes to the pattern, as a new version needs to be added to see the changes.
• Once in production, changes to a pattern that need to be reflected in all existing versions need to be applied to the database as well, which is error prone at the best of times.

One other ongoing issue that I've been unable to resolve has been removing the ability to change the heading level even within a contentOnly template lock. I'd like to be able to decide a heading should be, e.g., h2, and not have editors be able to change that heading level.

[fabiankaegy]

I can second everything that was said here. That is the dream development setup for patterns.

[fabiankaegy]

The reason why this is preferred is that we usually work with at least 4 different environments at a time. And keeping the databases synced, especially syncing changes up is not really possible. So the only way to work with this is by pushing code up the environments.

[gregsullivan]

I've run wp search-replace in each environment, but doing so has always felt high risk and requires carefully tailored strings for matching and for replacement. I only really feel comfortable doing this on smaller sites.

I've created custom blocks and used ACF blocks solely to avoid this problem with patterns; otherwise, patterns are preferable in every way.

[mikemcalister]

Great thoughts here. Anything we can do to improve the development workflow for patterns effectively improves the overall WP workflow for builders. We're going to be spending a lot of time with patterns going forward.

[SaxonF]

I would hope we can support both code and no-code versions of this workflow. Similar to how using Create block theme plugin you can build and export a theme, you should be able to do the same for patterns (if needed).

[mike-henderson]

As others have mentioned, being able to register pattern overrides in the theme with the /pattern directory is key. This would allow us to continue to track our patterns in git and push out updates with our themes.

Another pain point with patterns is how to manage updates. Currently the task is put on the site editors/users to reinsert the pattern and update the content if a pattern style or structure changes. The copy block styles option helps with this lift, but it is not an intuitive workflow.

Optional blocks in a pattern should also be considered. Currently we tell users to delete the blocks they are not using in a pattern instead of leaving blank with the placeholder text. If left blank, certain elements will still render the html tag on the front end, potentially presenting an accessibility issue. A solution would be to make certain blocks optional and have them not render on the front end.

I’m also very interested in how pattern overrides will work with section specific styling. Currently, in order to create multiple variations of a pattern, we are replicating the same pattern file and have a separate pattern file for each color variation. This creates a litany of pattern options in the block inserter. Ideally, section specific styling would overcome this issue, and pattern overrides would support the option for multiple styles on one pattern file.

I can provide specific examples if more clarification is needed, thank you!

[landwire]

Having patterns managed in code is crucial!
And what @mike-henderson stated about marking some blocks as optional, so that they do not render in the front when nothing is added, is also a good point. In my opinion this should be the default behaviour. So if nothing is added to a block in a pattern, then that block should not be rendered in the front end.