Reusable blocks: Rename to 'Patterns' and add option to also add a non-synced Pattern #51144
Conversation
glendaviesnz
added
the
[Feature] Patterns
|
Size Change: +2.11 kB (0%) Total Size: 1.4 MB
ℹ️ View Unchanged
|
|
Flaky tests detected in d477199. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/5317864454
|
This comment was marked as outdated.
This comment was marked as outdated.
...s/reusable-blocks/src/components/reusable-blocks-menu-items/reusable-block-convert-button.js
Outdated
Show resolved
Hide resolved
This comment was marked as outdated.
This comment was marked as outdated.
glendaviesnz
changed the title
This comment was marked as outdated.
This comment was marked as outdated.
glendaviesnz
requested review from
ryanwelcher,
juanmaguitar,
fabiankaegy and
ndiego
as code owners
This comment was marked as outdated.
This comment was marked as outdated.
Sorry, something went wrong.
...s/reusable-blocks/src/components/reusable-blocks-menu-items/reusable-block-convert-button.js
Outdated
Show resolved
Hide resolved
|
@talldan, @SaxonF, @jasmussen, @youknowriad, @mtias, @aristath it would be good to get feedback on this approach to adding the ability for users to add non-synced Patterns by using the existing The key things to consider are:
|
...s/reusable-blocks/src/components/reusable-blocks-menu-items/reusable-block-convert-button.js
Outdated
Show resolved
Hide resolved
|
There is an alternative to storing the sync status in the There are pros and cons of both approaches:
One question that would need to be considered if taking the approach of storing the sync status in the instance block attributes would be whether toggling to |
|
@glendaviesnz thanks for the summary. If we did go the |
That would be option C in the table above and I think that could be implemented all at once, or the instance values could be added in later easily enough, but only for existing synced or new patterns, ie. there would be no way to layer this back over |
|
What about using the post_status field on the stored wp_block instead of a postmeta? That would also make filtering patterns in query more performant. Or should there be a case where patterns are in a drafts/published status? |
| 'sync_status', | ||
| array( | ||
| 'auth_callback' => function() { | ||
| return current_user_can( 'edit_posts' ); |
There was a problem hiding this comment.
Shouldn't this use the meta capability somehow?
There was a problem hiding this comment.
The auth callback has been removed in the backport to core as the relevant checks for user permissions for the given post type are already done, I assume this includes the relevant postmeta permissions - have copied this question over to that port to check.
|
Note re categories for custom patterns: We thought about using the existing pattern categories by storing the slug in an additional We explored ways of integrating this with the existing core pattern categories, eg. prepopulating the new taxonomy with the core categories, but there were issues with this if users deleted or edited them, and blocking edit removed most of the advantages of using a custom taxonomy. The best option we got to was a mix of a custom taxonomy with the user's custom categories, that is merged with the core categories, with the core categories being pulled into the user's taxonomy only if they assign that category to one of their patterns. There is a PR with this approach here. It was decided that more design/development/testing time was needed to come up with the best solution for adding custom categories to patterns, and there was not sufficient time/resource to do this ahead of 6.3 so this work was pushed to post 6.3. |
|
When this is picked up again for WP 6.4, I would like to suggest a more fitting name for the taxonomy. E.g. instead of 'wp_pattern' maybe 'wp_pattern_category'? |
|
Just to clarify, only the custom categories were punted to 6.4. The addition of unsycned patterns, and renaming of reusable blocks to synced patterns is still down for 6.3 at this point. |
…n-synced Pattern (WordPress#51144) --------- Co-authored-by: Saxon Fletcher <saxonafletcher@gmail.com> Co-authored-by: Daniel Richards <daniel.richards@automattic.com>
Dev noteReusable blocks have been renamed to Patterns in 6.3. For backwards compatibility, the default behavior of the The Pattern block also has a second option in 6.3 which is 'unsynced'. When 'unsynced' the block will behave the same as the existing theme and plugin patterns, ie. the patterns blocks will be inserted as standalone blocks, and any edits affect only that instance. In order to track the synced and unsynced status a new postmeta field has been registered for the Because the synced Patterns do not require the new postmeta field we don't anticipate any impact on plugins that may modify the existing reusable block bahavior. The only impact we anticipate is to any plugins that manipulate the DOM based on selectors that depend on the text |
What?
Renames the Reusable blocks to Patterns. Also adds the option to convert a block or collection of blocks to a non-synced Pattern. This then behaves as imported Patterns do in that once inserted they can be edited completely independently of any other instances of the Pattern. The synced version of the Pattern works as the existing Reusable blocks do in that editing one instance updates all instances.
Why?
#50028 requires the ability of users to add new patterns and edit/duplicate existing patterns from the UI as part of the new Pattern Library functionality in the site editor. It made sense to reuse the
wp_blockCPT to implement this and to merge with Reusable blocks.How?
Adds a
wp_block.sync_statuspost meta property to thewp_blockCPT.N.B. - This PR only renames Reusable block in the UI, and the minimal critical places in code, in order to keep the PR as small and reviewable as possible. Follow-up PRs will rename all references in the code to reusable block to avoid future confusion.
Testing Instructions
/wp-admin/edit.php?post_type=wp_blockand check that the existing blocks haveSync Statusset toSyncedin the right post properties panelCreate a patternmenu option/wp-admin/edit.php?post_type=wp_blockand make sure the synced and unsynced Patterns show. Edit Patterns from this page and check that toggling the sync status in right panel works as expectedScreenshots or screencast
turtles.mp4