Gutenberg Block Templates of post_type wp_template do not override WooCommerce templates.

[JoshuaJarman]

We've created a number of sites using the new Gutenberg Block Templates full site block templating system and routing via the post_type wp_template. the sites only have an index.php and functions.php and other than that are php-less and full page editing via gutenberg and they do all the routing via this new mechanism of sluging to match template name.

/wp-admin/edit.php?post_type=wp_template
#17626
#17512

all the core, custom post types, error pages such as 404 etc work flawlessly using this method. <3

we have been unable to override ANY woocommerce templates using this method. :-(
has anyone been successful? is woocommerce doing something that is preventing this?

any help would be greatly appreciated. thanks!

Possibly helpful terms to disambiguate what i am asking about.

wp_template: The new "Template Posts Type".
wp_template_parts: The new "Template Part Posts Type".
Template Hierarchy: The classic WP template hierarchy.
Template Files: The classic .php template files.

[noahtallen]

Thanks for the issue! Could you post some code that you are trying?

Some thoughts:

• Firstly, the FSE experiment is still just an experiment, so I would strongly advise to be careful about using it in production, if at all. In an experimental stage, the API for using FSE & templates is subject to change, so you cannot rely on it being the same in future Gutenberg releases, which might break things for you if you rely on it! (Until it is promoted to a stable feature!)
• Perhaps woocommerce is doing some special stuff to override the template hierarchy on their end?

It sounds as if this issue is more related to woocommerce not yet supporting FSE. I wouldn't expect them to at this point either, since the FSE experiment is still experimental ;) Without knowing how their template stuff works, I don't think I can comment on what could be going wrong.

That said, it would likely be helpful to begin a discussion with them about this, as I would expect they might be interested in supporting this in the future. Perhaps it would be worth opening an issue with them here: https://github.com/woocommerce/woocommerce

cc @nerrad

[JoshuaJarman]

the gutenberg block templates are separate from the FSE experiment, but FSE does leverage them.

we aren't using the FSE, just the core baked in gutenberg functionality, but the concept is the same so i mentioned it which apparently auto-closes the issue? yikes.

this is more related to that core routing which is standard now, but if you think woocommerce is doing something non-standard that is preventing this is there a better place to ask that question?

seems like the gutenberg team creating this routing would be the most qualified place to ask? right?
This is about the interaction of both and seemed like it was most likely to receive a qualified response here.

do you think the woocommerce team has the first clue about wp_template post routing?
I'll ask there as well and cross link these questions. i still think the gutenberg team has the best shot at giving me an answer.

[nerrad]

Thanks for the ping @noahtallen.

I think Noah has covered all the important points in his reply.

It's still a bit unclear to me the exact issue that you are facing at the moment (aside from whatever WooCommerce templates you are trying to override not working). On initial read it looks like you are trying to work with does involve underlying APIs being developed to in turn support full site editing and the new block template routing system and it's possible WooCommerce needs to do some integration with this new system for the custom templates Woo provides.

That's something that is on the Woo development team's radar to start diving into soon, but as Noah pointed out, being this is still experimental - we too will likely be releasing anything we do as a experiments as well.

[noahtallen]

Woocommerce is its own plugin, not part of Gutenberg or WordPress, so I would ask in the woocommerce repo if you have woocomerce-related questions.

the concept is the same so i mentioned it which apparently auto-closes the issue

which issue got autoclosed? :)

we aren't using the FSE

Ah, so you are kind of replicating the same sort of behavior, just by using filters to render your own custom CPT. Nifty!

seems like the gutenberg team creating this routing would be the most qualified place to ask

Which code are you talking about? Maybe I don't understand your question! I think seeing a code snippet would help me to understand your problem better. If we are thinking about this function:

gutenberg/lib/template-loader.php

Lines 40 to 52 in 1a16a0f

	function gutenberg_add_template_loader_filters() {
	if ( ! post_type_exists( 'wp_template' ) ) {
	return;
	}
	foreach ( get_template_types() as $template_type ) {
	if ( 'embed' === $template_type ) { // Skip 'embed' for now because it is not a regular template type.
	continue;
	}
	add_filter( str_replace( '-', '', $template_type ) . '_template', 'gutenberg_override_query_template', 20, 3 );
	}
	}
	add_action( 'wp_loaded', 'gutenberg_add_template_loader_filters' );

I think my impression was that was behind the experimental flag, but I guess it is only conditioned on a CPT of "wp_template" existing, which would be true in your case.

[JoshuaJarman]

i'm not using anything from the experimental branches or the FSE plugin.

ONLY using the feature from core per the docs:
https://developer.wordpress.org/block-editor/developers/block-api/block-templates/
"Defined in a template.php file or pulled from a custom post type (wp_templates) that is site specific."

it is really hard to get any help or answers on this feature, everyone is confused by what is being discussed.

custom post type (wp_templates) problem is there isn't any php code snippet, block templates using the slug for routing don't work for woocommerce pages. looking over the code you posted now...thanks for sticking with me.

[noahtallen]

You're totally right. I think part of it is that the word "template" is overloaded. If we look at that documentation page though:

Planned additions:

• Saved and assigned to pages as “page templates”.
• Defined in a template.php file or pulled from a custom post type (wp_templates) that is site specific.
• As the equivalent of the theme hierarchy.

the bit about defining templates in this way is still under "planned additions" and is definitely still WIP

[noahtallen]

Currently, the main purpose of the "template API" on that page is to set up something like:

• The default blocks for a post
• Restrictions on what can be inserted in a post

When I think of wp_template in the context of FSE, I'm thinking of solving the problem "edit the layout which is used to render multiple pages of a site"

What is your use case?

[JoshuaJarman]

Ah i see, i thought since this routing was merged and released to core a number of versions back and is working for everything else that it was usable. That might have been a mistake on my part.

The good news is that it works with everything else. Do you know how i'd look up a timeline for woocommerce on this or ask their team in a way they'd understand the question? the wording is tricky for me to disambiguate in a meaningful way when asking.

[nerrad]

@JoshuaJarman I'm on the development team for WooCommerce, so I'm already engaging here with you on this. Is there anything in my previous answer that you'd like me to clarify?

As far as timeline, the team I'm working on are planning on diving into things within the next two months but I don't have any ETA on when you'll start seeing things surface.

[JoshuaJarman]

ah thanks again for meeting me here. <3

yes one more question as i have to get something working....

is there a way to link this up manually for now that you'd recommend?
is creating the php template files in the theme folder and calling the blocks manually the best way currently?
or can i hook into a wc template action and change the routing to a gutenberg slug routing instead of a file template routing?

any tips or advice would be greatly appreciated. it appears we've driven into an under construction area and just need directions on how to best navigate past this for the moment.

[noahtallen]

i thought since this routing was merged and released to core a number of versions back and is working for everything else that it was usable.

You are right that this routing should have been put behind an experimental flag (otherwise, this experimental functionality begins working if you just have a simple wp_template CPT. Do you think it is worth us adding that check now?

After looking doing a search on the WC codebase for "template", I found this file which handles template loading. You might be able to figure out what is going on by looking through it: https://github.com/woocommerce/woocommerce/blob/b62457dd0175b065ef871ad482ea278c9ad6e222/includes/class-wc-template-loader.php

[nerrad]

any tips or advice would be greatly appreciated. it appears we've driven into an under construction area and just need directions on how to best navigate past this for the moment.

This is kind of the issue for WooCommerce right now. Sorry I don't have any tips or help for you specifically as we're in the same boat being we haven't explored this yet (as noted, it's something being planned).

[JoshuaJarman]

thanks for taking the time to explain the current status to me better and let me know where things are. i look forward to this being addressed by the wc team when that happens and will try and figure out a workaround until then.

the functionality is incredibly slick and seems to be working great for everything else. all the standard stuff works as intended and we haven't had any other issues. we were very happy about this addition. all sites working well so far, this woocommerce issue is the first bit of unpaved area we've hit so far as this is our first ecommerce site under this new build style. so kudos to the gutenberg team on that, excellent work.

[nerrad]

Again, it's awesome you're experimenting with this @JoshuaJarman, and thanks for the kind words for the Gutenberg team! I'm going to close this issue because there's nothing actionable currently from it for this repository.

If in your experiments, you find a specific reproducible bug or issue within the GB code that you can point to, please don't hesitate to open a new issue.