Export Unsynced (not synced) patterns to Theme

[pbking]

Using the "Export Patterns" function seems like it is currently exporting an unexpected type of pattern.

Considering that (right now) unsynced patterns are all that can ship with themes, and that since a user can create both unsynced and synced patterns, that the patterns that should be exported are the user created unsynced themes, rather than synced.

Why are we exporting the synced patterns? So that they can be leveraged in templates?

[mikachan]

Why are we exporting the synced patterns? So that they can be leveraged in templates?

Part of the original intention with the initial PR for this was to ensure any references to synced patterns were replaced when a theme is exported, as those references don't work when outside the original WP instance (e.g. as described in this issue in GB WordPress/gutenberg#53806).

However, maybe it would be better for this plugin to export both synced and unsynced patterns on theme save/export, but the behaviour behind the scenes may differ slightly. For example:

Synced patterns:

• Are copied to pattern files in the active theme.
• Any references to the pattern (e.g. wp:block {"ref":62}) in theme templates or other patterns are replaced with a reference to the theme version.
• Original pattern is removed from the database (current functionality) - or perhaps the original pattern should remain as a synced pattern? And then the theme version becomes an unsynced version (which it would be anyway, as you mentioned, themes only currently provide unsynced patterns).

Unsynced patterns:

• Are copied to pattern files in the active theme.
• These patterns won't be referenced in theme templates/patterns as their content is inserted as block markup rather than a reference to a pattern from the database - so there is no need to replace their references.
• Original pattern is removed from the database.

cc @eirichmond @colorful-tones, in case you have any thoughts on this too.

[pbking]

I think that we should wait to export SYNCED patterns until a theme can provide them.

It's beneficial to manage unsynced patterns, even when they aren't used in a template and it would be really nice to be able to use the Editor for that. That said, once the patterns have transitioned from USER to THEME they aren't editable in the editor any more so that also makes things tricky from a pattern management standpoint.

[eirichmond]

For what it's worth, it would be greatly improved by enhancing its role as a theme development tool, which is the way I use this plugin... and leveraging synced patterns for specialised themes.

CBT as a Theming Tool: The CBT plugin should prioritise features that streamline theme creation and export, with a focus on managing synced patterns efficiently.

Synced Patterns for Specialised Themes: Themes for niches like recipes or bookstores could benefit from pre-designed synced patterns, such as ingredient lists or book reviews, enhancing consistency and usability.

Exporting with Theme Slug: As suggested in 53806 To prevent synced pattern references from breaking when used in different WordPress environments, patterns should be exported using the theme's slug instead of database IDs, making them more portable and robust.

This approach will improve theme development, offer a better user experience, and ensure reliable pattern management across WordPress installations.

[Graphnic]

To further expand on this topic, the exporting - and then deletion of - synced patterns has an unintended consequence in the context of building block themes for a specific site, rather than for distribution:

Design components, such as 'cards' used in post loops, should arguably be stored as template parts. The problem with this is that template parts are not available to the user in the Block Editor, only the Site Editor. This is problematic when a post loop is included as part of a page layout (not a template) and the user wants to implement a centrally managed card design, shared also with loops in the Site Editor templates. The only solution to this (that I can think of at least), is to save the card design as 'synced pattern', and use it both in the Site and Block editors alike. It works well, albeit with the disadvantage of the pattern being stored in the DB rather than to disk.

The problem, as I discovered to my peril just before sharing a site with a client for feedback, is that Create Block Theme saves any Synced Patterns used in templates in the Site Editor to disk as standard patterns, replaces the instance in the theme with an unsynced pattern, and deletes the Synced Pattern. Which, to be fair, is what the feature states.

This create three tricky problems:

1. All instances of the pattern in the theme (a card in this example) become unsynced which is bad for maintenance. Only after re-reading the description did I fully appreciate this. My error, but it's really easy to overlook.
2. All instances of the pattern used in the Block Editor (post loops in my example) simply break, as their referenced synced pattern no longer exists. They are not even replaced with an unsynced version of the pattern.
3. We cannot easily 'undo' this once executed, as I discovered to my peril. The accidental checking of this box leads to a lot of rebuilding with no easy way of reverting the action.

[pbking]

@Graphnic that's nearly exactly the problem that I have had with this as well!

To better support my workflow I've been using a modified version of CBT which exports synced patterns as synced patterns... which I keep in a separate folder /synced-patterns and then load with this little nugget.

It's been working pretty well and I'm keen to expand it and make it more available. The problem, of course, is that Themes can't actually ship with synced patterns (outside of adding this bespoke code to allow for it) so adding that kind of functionality to CBT doesn't really work until they do.

[Graphnic]

@pbking It was also cited by another user on Twitter as well. Seems like it is catching folks out. Interesting work around you mention there.

I don't really understand the underlaying purpose of the feature. It feels like it should be some kind of 'pre-flight' checker warning of an issue if theme is to be distributed, rather than an irrevocable architectural change made to the theme. Needs of flashing red lights at very least IMO. I guess the context of CBT is seen more for theme designers looking to distribute themes rather than those of the building one-offs for clients etc.

[pbking]

Yes, exactly. Which is exactly the transition I personally made; from working on Themes to be distributed to currently working on themes for clients, which I now understand to have different needs!

I'm using a specialized build of CBT for my client work which suits the workflow for that a lot better and as soon as I get a break from some of that I hope to contribute it back up into the project.