Add: Ability to use creation patterns for other post types besides page #41791
Conversation
jorgefilipecosta
added
the
[Feature] Patterns
|
Size Change: +3.46 kB (0%) Total Size: 1.25 MB
ℹ️ View Unchanged
|
| : [] | ||
| ).concat( | ||
| __experimentalGetPatternsByBlockTypes( | ||
| `core/post-content/${ postType }` |
There was a problem hiding this comment.
This is a very weird construct to me since it seems to imply the post type is a child of the block type. Why can't we go with a separate key for post types? Seems both clearer and more flexible.
jorgefilipecosta
force-pushed
the
add/ability-to-use-Page-creation-Patterns-for-custom-post-types
branch
from
9e4c481 to
375fc44
Compare
There was a problem hiding this comment.
Thanks for exploring this Jorge!
I think that we should have an API that is not so specific to create page patterns, but instead we should explore a way for postTypes in general. What we might also need is a way to show conditionally patterns based on a template or template type(archive, etc..). So it comes to having an API that will handle which patterns are shown based on context.
I'm not saying right now that we should combine these(it would need exploration), but is something to have in mind.
We shouldn't have the example of 'core/template-part/header' in mind because it's about block types and block variations.
Whatever API we will introduce, I believe it should be a new selector that will handle all the restrictions we impose and have a single source of truth. For example block patterns by block type are shown/requested in specific places to suggest a pattern and these patterns should also be filtered by the postType. Makes sense?
| * | ||
| * @see WP_REST_Controller | ||
| */ | ||
| class Gutenberg_REST_Block_Patterns_Controller extends WP_REST_Controller { |
There was a problem hiding this comment.
We need to align with the existing controller in core. This means, I believe we need to move forwards this issue: #40902 and see what we'll need to update. Perhaps something like WP_Theme_JSON_6_1 extends WP_Theme_JSON_6_0 might be needed..
Noting that I didn't check the code here - just some thoughts..
There was a problem hiding this comment.
Hi @ntsekouras In this PR I'm already aligining the endpoint with core (by accident) private $remote_patterns_loaded; is part of this PR. Basically, I copied this class from core, changed its name, and did the changes I needed. I'm using WordPress filters to overwrite the core class with this new Gutenberg one Following this approach we don't need any extends etc. We are free to apply the changes we need. When backporting the class to core we just copy this file back to the core, change its name, and that's it. I left a comment on @anton-vlasenko PR #40902 (review).
|
@ntsekouras @jorgefilipecosta to connect the loop, I proposed a different API for this here: #41398 |
Yes, that was what I was suggesting 😄 |
|
Hi @mtias, @ntsekouras this PR passed by an update to the API. But I can change the property to postTypes if we prefer to unify the concepts and not have two properties. The change is very easy I just need to replace startContentPostTypes with postTypes. The downside is that if a pattern is the start content of a postType I will not be able to use it at all in other postTypes. |
|
Hey @jorgefilipecosta, thanks for presenting these different alternatives. I vote for just introducing I'd rather not rush to commit to a starter-content-related API, and instead make sure we offer simple APIs with clear semantics (like the |
Hi @mcsf, so just to make sure we are in agreement, in that case, it is a fair tradeoff and ok that if a pattern is supposed to appear in the start content of a "product" post type it will not be available on any other post type at all? |
Correct. We might want in the future to allow post types to opt-in to starter modal wholesale, like "page" is auto-opted in, but it might also be entirely unnecessary if it's predicated on the patterns. From a pattern perspective, when we say it is restricted to |
|
Thank you @mtias, @mcsf, @ntsekouras this PR was updated following your suggestions and now we have a postTypes property. I'm now implementing as a follow-up the postType restriction part (if a postType is product the pattern will not appear at all for other post types). |
jorgefilipecosta
force-pushed
the
add/ability-to-use-Page-creation-Patterns-for-custom-post-types
branch
from
7763463 to
808b33c
Compare
jorgefilipecosta
force-pushed
the
add/ability-to-use-Page-creation-Patterns-for-custom-post-types
branch
from
808b33c to
291edce
Compare
|
A follow-up PR was proposed at #41842 that implements the postTypes restriction (if a pattern specifies postTypes it will only appear on the postTypes it specifies). |
| @@ -0,0 +1,224 @@ | |||
| <?php | |||
There was a problem hiding this comment.
Note to reviewers: this file is an exact copy of core with the following changes:
- class name changed for the Gutenberg prefix.
- post_types added to the description in public function get_item_schema().
- 'postTypes' => 'post_types', added to $key in prepare_item_for_response.
There are no other changes to the core file.
No changes from Core's _register_theme_block_patterns, just a copy in preparation for the next commit.
|
All the feedback was applied and some documentation was included. |
jorgefilipecosta
deleted the
add/ability-to-use-Page-creation-Patterns-for-custom-post-types
branch
bph
added
the
Needs Dev Note
…php. Backports PHP changes in WordPress/gutenberg#41791 to the core. Adds the post types property to the rest API patterns endpoint. Props mcsf, ntsekouras, matveb. See #56467. git-svn-id: https://develop.svn.wordpress.org/trunk@54263 602fd350-edb4-49c9-b593-d223f7449a82
…php. Backports PHP changes in WordPress/gutenberg#41791 to the core. Adds the post types property to the rest API patterns endpoint. Props mcsf, ntsekouras, matveb. See #56467. Built from https://develop.svn.wordpress.org/trunk@54263 git-svn-id: http://core.svn.wordpress.org/trunk@53822 1a063a9b-81f0-0310-95a4-ce76da25c4cd
…php. Backports PHP changes in WordPress/gutenberg#41791 to the core. Adds the post types property to the rest API patterns endpoint. Props mcsf, ntsekouras, matveb. See #56467. Built from https://develop.svn.wordpress.org/trunk@54263 git-svn-id: https://core.svn.wordpress.org/trunk@53822 1a063a9b-81f0-0310-95a4-ce76da25c4cd
…php. Backports PHP changes in WordPress/gutenberg#41791 to the core. Adds the post types property to the rest API patterns endpoint. Props mcsf, ntsekouras, matveb. See #56467. git-svn-id: https://develop.svn.wordpress.org/trunk@54263 602fd350-edb4-49c9-b593-d223f7449a82
This commit documents the postTypes property part of the block pattern registration added in WordPress/gutenberg#41791, and meanwhile backported into core. Props mcsf, ntsekouras. Built from https://develop.svn.wordpress.org/trunk@54850 git-svn-id: http://core.svn.wordpress.org/trunk@54402 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This commit documents the postTypes property part of the block pattern registration added in WordPress/gutenberg#41791, and meanwhile backported into core. Props mcsf, ntsekouras. Built from https://develop.svn.wordpress.org/trunk@54850 git-svn-id: https://core.svn.wordpress.org/trunk@54402 1a063a9b-81f0-0310-95a4-ce76da25c4cd
This commit documents the postTypes property part of the block pattern registration added in WordPress/gutenberg#41791, and meanwhile backported into core. Props mcsf, ntsekouras. Built from https://develop.svn.wordpress.org/trunk@54850 git-svn-id: http://core.svn.wordpress.org/trunk@54402 1a063a9b-81f0-0310-95a4-ce76da25c4cd
Closes: #41304
This PR is a follow-up to #40034 and allows the creation patterns modal to appear in other post types besides pages.
API
In order for a pattern to appear in a post type starting modal, the pattern blockTypes need to include support for 'core/post-content' ( so it defines the pattern is supposed to be the full content of a post) and the pattern should define the postTypes it supports as starting content in the postTypes array. Defining support only 'core/post-content' continues to work as before as by default we assume that a pattern supports being the full content of a page.
API shape alternatives
Old discussion:
I'm not totally sure if using blockTypes with 'core/post-content/$postType' is the right path. For template-parts we use a similar format e.g: 'core/template-part/header'. This format is consistent with the template-pasts format and that is the main reason I'm using it.
If people prefer I'm open to an alternative format e.g: using a new property on the pattern like "creationPostTypes" an array of post types that the pattern defines support for appearing as start content (e.g: ["page, "product",...]).
cc: @mtias, @mcsf in case you have a preference for a specific API shape.
Updated: following @mtias suggestion we use a post types array.
Post types defining patterns they support vs Patterns defining the post types they support
In #41304, @Humanify-nl proposed a different API, where the post type is the one that defines patterns that appear. I'm following a different path where the patterns define the post types where they appear. This allows patterns in the pattern directory to define support for the common post types where they work, without the post type not even knowing that the pattern exists. It seems post types are less numerous than patterns so it is more expected that the pattern creator knows the post types where the pattern makes sense than the post type creator is aware of all the possible patterns that can be used.
Common use cases and code samples of how to achieve them.
On my "Special Page" post type I want to support all the patterns that appear on normal pages
I want to totally remove this functionality from my "Special Post" post type.
Testing Instructions
I applied the following diff:
I created a new post and verified the following modal appears:
I created a new page and verified the following modal appears:
