Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Should templates registered for nonexistent/inactive plugins appear in the UI? #64754

Open
justintadlock opened this issue Aug 23, 2024 · 6 comments
Labels
[Feature] Templates API Related to API powering block template functionality in the Site Editor Needs Decision Needs a decision to be actionable or relevant [Type] Enhancement A suggestion for improvement.

Comments

@justintadlock
Copy link
Contributor

justintadlock commented Aug 23, 2024

#61577 introduced a plugin template registration API. The intention was to specifically let plugin authors register templates specifically for their plugin by registering the template in the form of plugin_uri//template_name.

This works well. As you can see, if I register a template for Gutenberg with gutenberg//template_name, it correctly appears in the UI:

add_action( 'init', function() {
	wp_register_block_template( 'gutenberg//awesome', [
		'title'       => __( 'An Awesome Template', 'pluginslug' ),
		'description' => __( 'The template description', 'pluginslug' ),
		'content'     => '<!-- wp:template-part {"slug":"header","tagName":"header"} /--><!-- wp:group {"tagName":"main","layout":{"inherit":true}} --><main class="wp-block-group"><!-- wp:paragraph --><p>This is a plugin-registered template.</p><!-- /wp:paragraph --></main><!-- /wp:group -->'
	] );
} );

Screenshot:

image

However, if I change the plugin_uri bit to anything (not a valid, active plugin), such as super-duper//awesome, it still appears in the UI but with the super-duper "title":

add_action( 'init', function() {
	wp_register_block_template( 'super-duper//awesome', [
		'title'       => __( 'An Awesome Template', 'pluginslug' ),
		'description' => __( 'The template description', 'pluginslug' ),
		'content'     => '<!-- wp:template-part {"slug":"header","tagName":"header"} /--><!-- wp:group {"tagName":"main","layout":{"inherit":true}} --><main class="wp-block-group"><!-- wp:paragraph --><p>This is a plugin-registered template.</p><!-- /wp:paragraph --></main><!-- /wp:group -->'
	] );
} );

Screenshot:

image

Note that there's no way to define a title that can be internationalized for this section in the UI, so I think this is likely bad practice in general.

Discussion / Needs Decision

Should this be restricted so that it doesn't show templates registered for inactive plugin URIs? Or should this continue working as a sort of fallback? Other options?


I think there are larger discussions on expanding what can be registered in future iterations of the feature (custom groups/categories, theme-registered templates, etc.). But I want to limit this ticket to just what the behavior should be for this first version of the API so that there is no confusion around what should happen.

@justintadlock justintadlock added [Type] Enhancement A suggestion for improvement. [Feature] Templates API Related to API powering block template functionality in the Site Editor Needs Decision Needs a decision to be actionable or relevant labels Aug 23, 2024
@Aljullu
Copy link
Contributor

Aljullu commented Aug 23, 2024

Thanks for opening this issue, @justintadlock!

I didn't restrict the namespace to match the current plugin uri to follow suit with register_block_type(), which also allows using any namespace. However, one difference between both functions is that the namespace used by wp_register_block_template() ends up being shown in the UI as the author/origin of the template, while the namespace used in register_block_type() is never shown in the UI, AFAIK.

I don't have a strong opinion towards restricting the namespace to match the plugin uri or not. However, in order to be cautious, I lean towards being more restrictive, at least in the first version, and only accept the current plugin uri as the namespace. This would allow us to open the namespace to any value in the future. However, if the first version allows any namespace, we will never be able to revert the decision.

What do you think?

cc @ntsekouras @youknowriad

@ndiego
Copy link
Member

ndiego commented Aug 23, 2024

I lean towards being more restrictive, at least in the first version, and only accept the current plugin uri as the namespace.

I think this is reasonable for the first iteration of this API. I can imagine people wanting to change this though in the future, but you would also need to be able to set a title.

@youknowriad
Copy link
Contributor

the namespace used in register_block_type() is never shown in the UI, AFAIK.

Just want to correct this. The "namespace" of register_block_type can be shown in the UI if you also register it as a "block collection" (it's very similar in principal to the template source)

@ndiego
Copy link
Member

ndiego commented Sep 2, 2024

The "namespace" of register_block_type can be shown in the UI if you also register it as a "block collection" (it's very similar in principal to the template source)

This is new to me, or maybe I am misunderstanding something. How do you register a block collection?

@youknowriad
Copy link
Contributor

@ndiego I think the API is documented here https://developer.wordpress.org/block-editor/reference-guides/block-api/block-registration/#block-collections (wp.blocks.registerBlockCollection)... It's a very old API :)

@ndiego
Copy link
Member

ndiego commented Sep 3, 2024

I think the API is documented here https://developer.wordpress.org/block-editor/reference-guides/block-api/block-registration/#block-collections (wp.blocks.registerBlockCollection)... It's a very old API :)

Ah, very cool. Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Feature] Templates API Related to API powering block template functionality in the Site Editor Needs Decision Needs a decision to be actionable or relevant [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

4 participants