search

WordPress / gutenberg

The Block Editor project for WordPress and beyond. Plugin is available from the official repository.
https://wordpress.org/gutenberg/
Other
9.99k stars 4.01k forks source link

Synced Patterns iteration for WordPress 6.7 (Draft) #62566

Open talldan opened 3 weeks ago

talldan commented 3 weeks ago

Succeeds https://github.com/WordPress/gutenberg/issues/59819.

This is currently a draft and needs discussion/refinement

Improved customization flows for synced patterns / Theme bundling of synced patterns

The following issues solve a number of related aims:

  1. Themes can include synced patterns, allowing them to take advantage of pattern overrides
  2. Users can customize theme provided patterns using the same approach as template parts (Customize / Clear Customizations)
  3. Brings more parity between template parts and patterns for a potential future unification (template parts become patterns)

Related issues

Patterns as sections

Connects with the work on section styling and zoomed out editing.

Pattern overrides / Block bindings

Continuation of block bindings and pattern overrides.

TODO: Track anything punted from the 6.6 Beta/RC period. There may also be further UI improvements to pattern overrides to define.

Extensibility

Code Quality

andrewserong commented 2 weeks ago

Thanks for putting all this together! I'm sure many of these features will be complex to implement (and many are quite related), but from my perspective the standout here for me would be https://github.com/WordPress/gutenberg/issues/59272 (Add support for synced theme patterns (with overrides), as it sounds like that would really make the feature impactful for theme developers, or agencies that build a theme that'll be used across a number of clients.

justintadlock commented 2 weeks ago

Just adding a 👍 from me. My goal is to sync every pattern in my theme so that I can keep the design updated on a user's site without them having to reimplement the updated patterns in their posts, pages, and customized templates.

ndiego commented 2 weeks ago

Themes can include synced patterns, allowing them to take advantage of pattern overrides

I just finished an article on the WordPress Developer Blog covering the introduction of pattern overrides. This enhancement is amazing, but it has limited applications for agency developers due to the current limitations of synced patterns.

In the post, I use the example of a Card layout. Here's a screenshot of the finished product with overrides.

override-synced-pattern-preview

While this was created in the Editor, which is great for many types of WordPress users, folks building sites for clients would often like to keep this design in a pattern file provided by the theme. This would allow them to keep the file in version control and serve any future updates to the design through the pattern file instead of having to manually update the synced pattern stored in the database.

Allowed themes to include synced patterns would be a massive win for this user base and dramatically increase the power of patterns and block themes.

fabiankaegy commented 2 weeks ago

I can only second what @ndiego shared above.

Besides the ability to have synced patterns in themes however there is one additional thing that would make this even more powerful. And that is the ability to add custom block overrides in custom blocks.

For example in a custom icon block I want to be able to allow folks to override the icon used. Is that something that can get tracked here or should it get tracked with GbR block bindings feature?

dballari commented 2 weeks ago

I just finished an article on the WordPress Developer Blog covering the introduction of pattern overrides.

Nice post @ndiego, thanks a lot. It will sure be an awesome enhancement.

Allowed themes to include synced patterns would be a massive win for this user base and dramatically increase the power of patterns and block themes.

Doing this is not that difficult if we try to do it the easy and direct way: save them in xml format instead of saving theme as files in the patterns subfolder, and import them in the WordPress installation using the wp import / export tool.

There are two problems here:

  1. For the moment, xml files are not allowed in themes, I do not know why, but they are allowed in plugins (look at the woocommerce v9.0.0 sample-data folder). I believe this could easily be solved: Just like in plugins.

  2. People may thing the import / export tool looses referential integrity. That is, if I have some content that includes a synced pattern in one database (markup: <!-- wp:block {"ref":XYZ), where XYX is the id of the synced pattern) then I would loose it if I export and import to a new database. But this is not true, the import / export tool tries to keep the id every time it’s possible. And just in case and id of a synced pattern changes, we could perform a search replace action on the database, just like what I’m doing in a plugin of mine. Look at lines from 389 to 545 of this file

So with solution to this two problems, there is nothing that would keep us from including synced patterns in themes. Just in the synced-patterns subfolder in xml format or in the assets/xml subfolder.

ndiego commented 2 weeks ago

Doing this is not that difficult if we try to do it the easy and direct way: save them in xml format instead of saving theme as files in the patterns subfolder, and import them in the WordPress installation using the wp import / export tool.

This is an interesting approach, but I strongly suggest that synced patterns operate the same way unsynced patterns do in theme folders. They should be basically identical except for a few block attributes. While this approach may be more complicated to architect, the end result would be a simpler theme development experience.

dballari commented 2 weeks ago

This is an interesting approach, but I strongly suggest that synced patterns operate the same way unsynced patterns do in theme folders.

Yes, you are probably right. The only detail is that, one thing is the definition of a pattern, which is best as a html file in the patterns subfolder. The other thing is that, by definition, a synced pattern only becomes synced when created by the user, from the editor and is always in the database. In the html pattern file you can’t specify if that will be the case of not. That's why I just thought of suggesting a different way to define something which has to become synced (that is, which is meant to finally live in the database, not in the theme folder). But, of course, maybe I'm understanding things in a little different way.

youknowriad commented 2 weeks ago

I've been thinking about this issue and the different use-cases mentioned here (also in relation to the unification of patterns and template parts) with the goal about simplifying the concepts in the process and unifying everything. I believe the more we consolidate, the better is for theme and plugin authors to understand what's possible and for users to understand how to use the features.

So with this in mind, here's a proposal:

What needs to be done to achieve this?

An iterative process is needed in order to achieve the above without breaking change while offering a migration path to this "consolidated" pattern-based approach.

  1. First we need to allow the core/block block to reference a pattern using a "ref" instead of an "id". One decision that need to be made here is whether we should use the template part approach (wrapper for both frontend and editor) or the reusable block approach (wrapper only for the editor). I'm definitely for the template part approach for its simplicity and consistency in terms of styling (no hacks to make it work).
  2. Doing 1 means we can add a flag to the PHP API to register patterns (and the file API) to define whether a pattern should be treated as synced or unsynced by default.
  3. There's probably some work to be done on the REST API, to be able to fetch the patterns using the same REST API regardless of where they come from. Rather than using the default CPT REST API that only retrieves user saved patterns, an approach similar to the templates and template parts API is probably needed (smart IDs, merging of patterns from different sources probably using the pattern registry class). This item might need to be addressed first depending on whether it's a blocker or not.
  4. Legacy handling of template parts (can be registered as patterns from now one, they just have special slugs maybe)
  5. Unify site editor UI.
  6. Consider whether to soft-deprecate the pattern block reference a pattern using an ID.

Aside I created a very similar proposal for style variations and I believe that if we do things properly, the three concepts (patterns, style variations and templates) will end up behaving exactly the same way:

talldan commented 2 weeks ago

There's probably some work to be done on the REST API, to be able to fetch the patterns using the same REST API regardless of where they come from.

This is something that will be important to get right. If the plan is to unify patterns/template parts in the future, then it'll make sense for this endpoint to return template parts, but it'll be challenging to have it work that way from the start until all the smaller details are solved (areas, origins, sources etc.). Perhaps developing an experimental endpoint in the plugin first is the way to go.

I mentioned in a comment that it might be good to try and help migrate the navigation block to use slugs first, and hopefully learn from that what the right solution is for patterns - https://github.com/WordPress/gutenberg/issues/55911#issuecomment-2065742960.

youknowriad commented 2 weeks ago

On the endpoint, I agree it's important to get right.

I was thinking that we can probably explore "just" copying what we already do for template and template parts's endpoint and just use the "patterns registry" as the "source". The DataViews page in the site editor for "patterns" mix and matches between using the template part REST API and patterns which seems like an opportunity to try and test (unify) that endpoint.