Roots Discourse

Full site editing/FSE: Frontend doesn't load template

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.