Although the Gutenberg editor recognized and uses the FSE templates,
on frontend the index.php is still used instead.
Is there a route/router/loader that has to be reconfigured so it doesn’t short-circuit the template and allows WordPress to use the FSE templates instead?
(theme root)/block-templates/index.html
This doesn’t work anymore?
No, it doesn’t seem to work anymore. Adding this filter doesn’t change the frontend, the blade template is still shown.
Related issue:
The template_includefilter workaround doesn’t work and doesn’t seem to fix the underlying issue.
So after further investigating this issue (I really want to use Sage 10 + Gutenberg Full Site Editing/FSE) I found out that the Sage provider thing that also does the blade template handling in the acorn library (that adds all the runtime logic to the Sage 10 theme) intercepts the template loading and always sets the blade template file.
In contrast, the Gutenberg Full Site Editing block-template logic will use classical theme template files only as a fallback if it can’t find a block-template/ template file.
Just disabling the Sage provider caused new trouble as it also disabled manifest support.
When I comment out these two lines in the SageServiceProvider.php file, the Gutengberg block templates finally load:
But this will disable the classic blade fallback templates - including WooCommerce pages that aren’t Full Site Editing/FSE aware yet (as I know).
So how can I change the priorities or logic in Sage 10 that Gutenberg Full Site Editing/FSE block-templates have precedence over the classic blade templates?
The WordPress core logic first looks for an existing classic template file, then tries to find a Gutenberg Full Site Editing/FSE block-template and uses that, otherwise falls back to the classic template file:
Issue (Gutenberg):
It is caused by the template_hierarchy related filters:
add_filters([
'index_template_hierarchy',
'404_template_hierarchy',
'archive_template_hierarchy',
'author_template_hierarchy',
'category_template_hierarchy',
'tag_template_hierarchy',
'taxonomy_template_hierarchy',
'date_template_hierarchy',
'home_template_hierarchy',
'frontpage_template_hierarchy',
'page_template_hierarchy',
'paged_template_hierarchy',
'search_template_hierarchy',
'single_template_hierarchy',
'singular_template_hierarchy',
'attachment_template_hierarchy',
], $sage->filter('template_hierarchy'), 10);
Without the Sage-related filter:
Array ( [0] => front-page.php )
With the Sage-related filter:
Array ( [0] => resources/views/front-page.blade.php [1] => resources/views/front-page.php [2] => resources/views/front-page.css [3] => resources/views/front-page.html )
The get_query_template uses the "{$type}_template" filter at the end - which is then overridden by the aforementioned Sage class.
The filterTemplateHierarchy function always tries to lookup a blade template file for the passed $files array paths. This will also override block-template files.
This seems to fix it:
public function filterTemplateHierarchy($files)
{
return $files + [$this->sageFinder->locate($files)];
}
Found a workaround that basically short-circuits the template_hierarchy filters in acorn so the Full Site Editing/FSE template can be found:
// Full Site Editing/FSE fix for Sage 10 acorn template hierarchy filters
// @see https://discourse.roots.io/t/full-site-editing-fse-frontend-doesnt-load-template/21574/5?u=strarsis
// @see vendor/roots/acorn/src/Roots/Sage/SageServiceProvider.php: bindCompatFilters
$acorn_sage_template_filters = [
'index_template_hierarchy',
'404_template_hierarchy',
'archive_template_hierarchy',
'author_template_hierarchy',
'category_template_hierarchy',
'tag_template_hierarchy',
'taxonomy_template_hierarchy',
'date_template_hierarchy',
'home_template_hierarchy',
'frontpage_template_hierarchy',
'page_template_hierarchy',
'paged_template_hierarchy',
'search_template_hierarchy',
'single_template_hierarchy',
'singular_template_hierarchy',
'attachment_template_hierarchy',
];
foreach ($acorn_sage_template_filters as $template_filter) {
add_filter($template_filter, __NAMESPACE__ . '\\acorn_sage_fse_fix_template_path_before', 10);
add_filter($template_filter, __NAMESPACE__ . '\\acorn_sage_fse_fix_template_path_after', 20);
}
function acorn_sage_fse_fix_template_path_before($files)
{
global $acorn_sage_template_files_before;
$acorn_sage_template_files_before = $files;
return $files;
}
function acorn_sage_fse_fix_template_path_after($files)
{
global $acorn_sage_template_files_before;
return $acorn_sage_template_files_before + $files;
}
But the underlying compatibility issue in Sage 10/acorn should be addressed for future Sage 10 releases.
Note: Gutenberg deprecated the directories block-templates in favor of templates and block-template-parts in favor of parts.
Excellent explanation of the current template resolving mechanism used for Gutenberg:
https://core.trac.wordpress.org/ticket/53176#comment:2
For the post types, the gutenberg_locate_block_template is registered by the Gutenberg integration if the theme has block-templates support.
@strarsis I followed your notices about Sage and FSE here. Now I am wonderung what the current status on this is. Were you able to get Sage 10 as FSE-Template running?
Gutenberg and Sage had some changes in their loading behavior.
I had to adjust at least two times. Currently I had issues with latest Gutenberg (open basedir error on staging). As I also want to use FSE on production, I have to further debug this.
But with those adjustments FSE support in the theme should at least be detected in development.
Thanks for getting back to me. I understand that this is not production ready. 
Would be great if you could keep us up to date on your findings. Would be great to use Sage with FSE.
Thanks! 
+1 on this @strarsis please let us know if you have any luck with FSE, just starting to dip my toes in now! (I’ll post back if I find a useful workaround) 
Starting today with a new Sage 10 Gutenberg theme that should support FSE.
So I hope to find what may still cause issues with Sage 10 + Gutenberg FSE.
Incredibly busy right now. When I finish with the FSE theme I will surely tell you about it.
Follow up on this: Added Full Site Editing templates, but the Gutenberg site editor was simply blank.
Found the issue, you can see it here: Non-error, unexpected response for `_wp-find-template` not handled · Issue #45170 · WordPress/gutenberg · GitHub
The underlying issue is the Blade-PHP loader in Sage that catches those Gutenberg-requests.
This is the next thing I have to fix, then FSE should work.
@slowrush: Alright, I prepared a new Sage 10 Full Site Editing (FSE) example project:
Explanations and instructions are in the README.
Usually the Sage 10 should be a hybrid FSE theme, with non-block templates used for classic/traditional/classic views (with Blade-PHP). This has to be tested to ensure the order of precedence of template files is correct:
Can a block template be overridden by a classic/Blade-PHP template?
Currently the classic/Blade-PHP templates are always overridden by existing block templates.
thanks @strarsis - I’ll jump on this eve and try to wrap my head around it all!
appreciate taken the effort to get this far 
I also added an example for generic block patterns to the Sage FSE theme now.
Hi @strarsis , I have been trying to use your Sage10 FSE -theme and it works wonderfully on the wp-admin side. However I am unable to use the blade-templates at all. Is this how the theme is supposed to work (.html templates work but the .blade.php ones dont)? For example, I have created a blade template called ‘Testi Blade Template’ and it shows in the WP-admin when creating a page, but when I select the template none of the blade-template code works. Would be much needed if I could use the php-syntax and blade code inside a page. (creating custom ACF blade blocks work however, but there is need on some pages to use for example header.blade.php or footer.blade.php instead of the Gutenberg template part).
Any advice? Thanks!
Template code:
Template in wp-admin:
Hi @talentreeweb.
I also ran into this issue - an hybrid rendering did not work for me either in @strarsis theme repo.
I figured out, this was because of the overriden / patched method filterTemplateHierarchy in the used roots/acorn package:
public function filterTemplateHierarchy($files)
{
return $files + [$this->sageFinder->locate($files)];
}
Since $this->sageFinder->locate($files) returns an array, surrounding it with brackets, this method will return just the “default” array. So, any php / blade files won’t be located at all.
To fix this, I changed the method to:
public function filterTemplateHierarchy($files): array
{
$hierarchy = $this->sageFinder->locate($files);
// Extract all entries, which point to an official FSE path (e.g. templates/...)
$fse_paths = array_filter($hierarchy,
static fn ($file) => str_starts_with($file, 'templates/') || str_contains($file, 'templates/'));
$hierarchy = array_diff($hierarchy, $fse_paths);
// Build hierarchy with original $files and FSE paths on top.
return array_merge($files, $fse_paths, $hierarchy);
}
This will rebuild the found template files and will prio the FSE files above the blade template files.
I tried to get an optimized solution on this, by creating a acorn package, which should work on a vanilla sage theme and uses the original roots/acorn package. It also should check for required files in the theme. And it adresses an issue, where blocks won’t generate their CSS in wp_head().
Because this package is pretty WIP by now, please use with caution 
But eventually it’ll help you on this.