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:
It is caused by the template_hierarchy related filters:
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.