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

Only list the custom block templates in the list of available templates per post type #2020

Closed

Conversation

youknowriad
Copy link
Contributor

This backports a change that was missed during the initial backports related to the templates list shown in the post editor.
It's a change from the following Gutenberg PR WordPress/gutenberg#35802

Trac ticket: https://core.trac.wordpress.org/ticket/54335

Testing instructions

Make sure the post editor only shows custom page templates in the template list and not hierarchy templates (index, single...)

cc @Mamaduka

@youknowriad youknowriad self-assigned this Dec 7, 2021
foreach ( get_post_types( array( 'public' => true ) ) as $type ) {
$block_templates = get_block_templates( array( 'post_type' => $type ), 'wp_template' );
Copy link
Member

@Mamaduka Mamaduka Dec 7, 2021

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for working on this, Riad. While an update will fix the issue, I'm a little worried about the WP_Query calls this change will produce.

Since only custom templates (is_custom = true) are allowed to be page/post templates, maybe we use that property and conditionally add templates to the list?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure I understand? Are you worried about the number of requests? Is there a way maybe to solve this by adding a new is_custom to the query object?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, I'm worried about the number of requests.

We'll still need the post_type to check if the template is supported for this specific post type.

I think this has to be done slightly differently than we do in a plugin. I can create PR for my idea of PoC later today/tomorrow if we're not limited in the timeline.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Rough example:

if ( current_theme_supports( 'block-templates' ) ) {
	$block_templates = get_block_templates( array(), 'wp_template' );
	foreach ( get_post_types( array( 'public' => true ) ) as $type ) {
		foreach ( $block_templates as $block_template ) {
			if ( ! $block_template->is_custom ) {
				continue;
			}

			if ( isset( $block_template->post_types ) && ! in_array( $type, $block_template->post_types, true ) ) {
				continue;
			}

			$post_templates[ $type ][ $block_template->slug ] = $block_template->title;
		}
	}
}

We have to use properties directly in the loop instead of passing post type as query argument because we don't have access to the current post type in the get_post_templates method.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we don't have access to the current post type in the get_post_templates method.

Why we need that to determine whether a template is is_custom ?

--
I think we can probably commit the PR as is and consider improvements in follow-up to buy us time WDYT?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think we can probably commit the PR as is and consider improvements in follow-up to buy us time WDYT?

Sounds good. I can do a follow-up PR for beta 3.

Why we need that to determine whether a template is is_custom?

We don't need to know the post type for is_custom.

@youknowriad
Copy link
Contributor Author

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants