backport Rename Reusable blocks to Patterns#4646
Conversation
|
Any thoughts on how to best test this? I did look at adding a unit test to |
tellthemachines
left a comment
There was a problem hiding this comment.
Changes LGTM! Just one small nit below.
Testing locally, I'm seeing the changes in /wp-admin/edit.php?post_type=wp_block.
| @@ -282,26 +282,26 @@ function create_initial_post_types() { | |||
| 'wp_block', | |||
| array( | |||
| 'labels' => array( | |||
There was a problem hiding this comment.
I was going to say this one could have a @since 6.3.0 note too, but then I checked the create_initial_post_types doc block and there were no additions of the sort for previous changes, so I guess we might as well be consistent and leave it out 😅
| * | ||
| * @return void |
There was a problem hiding this comment.
| * | |
| * @return void |
WP-Dev doesn't include @return void annotations.
| * | ||
| * @since 6.3.0 | ||
| * | ||
| * @see https://github.com/WordPress/gutenberg/pull/51144 |
There was a problem hiding this comment.
| * @see https://github.com/WordPress/gutenberg/pull/51144 | |
| * @link https://github.com/WordPress/gutenberg/pull/51144 |
Nit but I think @see is intended for internal function and hook links.
| * | ||
| * @return void | ||
| */ | ||
| function wp_register_wp_block_postmeta() { |
There was a problem hiding this comment.
| function wp_register_wp_block_postmeta() { | |
| function wp_register_initial_post_meta() { |
WP registers all the post types in one function (along with statuses), create_initial_post_types, so I'm leaning towards using a generic function name to allow for additional meta data to be registered in the future.
Obviously if this changes then the equivalent is needed in default-actions.php -- would this cause problems in GB?
There was a problem hiding this comment.
That makes sense. Done. I am not sure if it affects GB. @tellthemachines do you know if we need to update the GB gutenberg_wp_block_register_post_meta to gutenberg_register_initial_post_meta to match this change?
There was a problem hiding this comment.
Do we want to stick with the create_initial naming pattern? We did most recently in create_initial_theme_features.
There was a problem hiding this comment.
Yeah, that makes sense to me. Sorry for the bad steer, Glen.
There was a problem hiding this comment.
no worries, have changed to _create_initial_
There was a problem hiding this comment.
do you know if we need to update the GB gutenberg_wp_block_register_post_meta to gutenberg_register_initial_post_meta to match this change
I don't think so, but we'll need to preserve the existing code in GB in the compat folder for use with previous versions of WP.
| 'show_in_rest' => array( | ||
| 'schema' => array( | ||
| 'type' => 'string', | ||
| 'properties' => array( | ||
| 'sync_status' => array( | ||
| 'type' => 'string', | ||
| ), | ||
| ), | ||
| ), | ||
| ), |
There was a problem hiding this comment.
| 'show_in_rest' => array( | |
| 'schema' => array( | |
| 'type' => 'string', | |
| 'properties' => array( | |
| 'sync_status' => array( | |
| 'type' => 'string', | |
| ), | |
| ), | |
| ), | |
| ), | |
| 'show_in_rest' => array( | |
| 'schema' => array( | |
| 'type' => 'string', | |
| 'enum' => array( 'fully', 'unsynced' ), | |
| ), | |
| ), |
This schema entry is incorrect. It's using the properties keyword which would only be used when registering a meta key with a type of object.
We should add an enum keyword that describes the possible values the meta field can contain.
There was a problem hiding this comment.
Thanks @TimothyBJacobs. It was initially set as an object, but we reverted to a string, but didn't update the schema correctly. I have updated and set the enum to array( 'partial', 'unsynced' ) as at this point there won't be a fully option as the fully synced blocks don't set the post meta in order to maintain backwards compat with existing reusable blocks. We will be adding a partial option post 6.3 though. Should we add that now, or should I just leave the enum as array( 'unsynced' ) for now?
There was a problem hiding this comment.
We will be adding a partial option post 6.3 though. Should we add that now, or should I just leave the enum as array( 'unsynced' ) for now?
No, we shouldn't add it until it becomes available as an option.
at this point there won't be a fully option as the fully synced blocks don't set the post meta in order to maintain backwards compat with existing reusable blocks.
Have ya'll considered setting the default to fully in register_post_meta? What does the client send when they want to set the reusable block to the equivalent of "fully"?
|
I would say exposing this value through |
That makes sense @TimothyBJacobs, but would require changes to Gutenberg which I think is about to have the RC version cut. Can we keep it as is for the first beta and update it after that is out? It is a minor implementation detail and doesn't affect the underlying data structure so doesn't seem like it will have any impact to do this as a follow up. What do you think? |
|
Yep that seems fine to me. |
felixarntz
left a comment
There was a problem hiding this comment.
@glendaviesnz Nothing crucial to add to previous reviews, LGTM!
Just two tiny documentation standard nit-picks that would be good to address.
Co-authored-by: Felix Arntz <felixarntz@users.noreply.github.com>
Co-authored-by: Felix Arntz <felixarntz@users.noreply.github.com>
|
Thanks for the reviews everyone! |
Co-authored-by: Peter Wilson <519727+peterwilsoncc@users.noreply.github.com>
peterwilsoncc
left a comment
There was a problem hiding this comment.
LGTM, thanks Glen!
| 'title', | ||
| 'editor', | ||
| 'revisions', | ||
| 'custom-fields', |
There was a problem hiding this comment.
Is custom fields support actually needed?
There was a problem hiding this comment.
In my testing the postmeta sync_status field was not returned without this.
There was a problem hiding this comment.
We are however going to look at returning it via REST as a top-level sync_status field rather than as post meta so we may be able to drop custom fields support if we go that way.
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.
From: WordPress/gutenberg#51144
Trac ticket: https://core.trac.wordpress.org/ticket/58577
Testing
Full testing would require GB plugin 16.1 installing.
This Pull Request is for code review only. Please keep all other discussion in the Trac ticket. Do not merge this Pull Request. See GitHub Pull Requests for Code Review in the Core Handbook for more details.