# Full site editing/FSE: Frontend doesn't load template **URL:** https://discourse.roots.io/t/full-site-editing-fse-frontend-doesnt-load-template/21574 **Category:** sage **Tags:** webpack, sage10 **Created:** 2021-10-16T13:15:34Z **Posts:** 30 ## Post 1 by @strarsis — 2021-10-16T13:15:35Z 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` --- ## Post 2 by @oxyc — 2021-10-17T15:56:17Z This doesn’t work anymore? > [@Sage 10: Block based theme support?](https://discourse.roots.io/t/sage-10-block-based-theme-support/17294/2): > > To get \/block-templates/\*.html files to work you can add the following filter which fixes the paths add\_filter('template\_include', function ($template\_file) { global $\_wp\_current\_template\_hierarchy; $\_wp\_current\_template\_hierarchy = array\_map('basename', $\_wp\_current\_template\_hierarchy); return $template\_file; }, 19); --- ## Post 3 by @strarsis — 2021-10-24T15:51:04Z No, it doesn’t seem to work anymore. Adding this filter doesn’t change the frontend, the blade template is still shown. Related issue: > > > * [x] I've read the [guidelines for Contributing to Roots Projects](https://gith…ub.com/roots/.github/blob/master/CONTRIBUTING.md) > * [x] This request isn't a duplicate of an existing issue > * [x] I've read the [docs](https://roots.io/documentation/) and followed them (if applicable) > * [x] This is not a personal support request that should be posted on the [Roots Discourse](https://discourse.roots.io/) community > > ## Description > Full Site Editing (FSE) with Sage 10 theme loads a blade template in frontend, no Website editor blocks are shown. > > ## Steps to reproduce > 1. Ensure a Sage 10 theme is present and enabled. > 2. Enable Full Site Editing (FSE) support in the Sage 10 theme. > 3. Add some modifications to the Website editor. > 4. Add/edit a page (front page). > 5. Open the front page on frontend. > Note that the site blocks from the Website editor are not loaded, instead the default blade-based template. > > **Expected behavior:** > Frontend shows the blocks from website editor. > > **Actual behavior:** > Frontend doesn't show the blocks from website editor, but the default blade template instead. > > **Reproduces how often:** > Always. > > ## Versions > `1.16.1: 2021-07-30` > > ## Additional information > Latest Gutenberg plugin `11.7.1`. > > The previous code for adding compatibility for Full Site Editing (FSE) doesn't work (anymore): > ```php > // Sage 10 + Gutengberg Full Site Editing (FSE) template compatibility > // @see https://discourse.roots.io/t/sage-10-block-based-theme-support/17294/2?u=strarsis > add_filter('template_include', function ($template_file) { > global $_wp_current_template_hierarchy; > $_wp_current_template_hierarchy = array_map('basename', $_wp_current_template_hierarchy); > return $template_file; > }, 19); > > ```` --- ## Post 4 by @strarsis — 2021-10-31T14:40:53Z The `template_include`filter 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): > > > ### Description > > The block-template, e.g. for a page, can be used in backend (Gu…tenberg editor), but on frontend the plain HTML is shown, the areas/block placeholders are not rendered. > What part of WordPress core/Gutenberg plugin is responsible for rendering the block-template HTML? Is it a filter? > Maybe the theme I am using somehow intercepts the renderer? How can I find this out? > > ### Step-by-step reproduction instructions > > 1. Enable a FSE theme. > 2. Add some content to the site and to a page. > 3. View the page. > Note that the page HTML is still the same as the block-template, block placeholders are still in place and not rendered. > > ### Screenshots, screen recording, code snippet > > _No response_ > > ### Environment info > > - WordPress `5.8.1` > - Gutenberg plugin `11.8.0` > > > ### Please confirm that you have searched existing issues in the repo. > > Yes > > ### Please confirm that you have tested with all plugins deactivated except Gutenberg. > > Yes 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)]; } ``` --- ## Post 5 by @strarsis — 2021-11-01T18:36:40Z 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. --- ## Post 6 by @strarsis — 2022-01-07T20:26:04Z Note: Gutenberg deprecated the directories `block-templates` in favor of `templates` and `block-template-parts` in favor of `parts`. --- ## Post 7 by @strarsis — 2022-01-07T21:06:21Z Excellent explanation of the current template resolving mechanism used for Gutenberg: [https://core.trac.wordpress.org/ticket/53176#comment:2](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. --- ## Post 8 by @philipp — 2022-05-25T10:23:31Z @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? --- ## Post 9 by @strarsis — 2022-05-25T10:30:23Z 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. --- ## Post 10 by @philipp — 2022-05-29T09:43:27Z Thanks for getting back to me. I understand that this is not production ready. :melting_face: Would be great if you could keep us up to date on your findings. Would be great to use Sage with FSE. Thanks! :pray:t3: --- ## Post 11 by @slowrush — 2022-06-14T13:23:18Z +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) :slight_smile: --- ## Post 12 by @strarsis — 2022-06-14T17:10:19Z 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. --- ## Post 13 by @huub — 2022-08-31T12:45:06Z Hi,@strarsis, did you manage to get FSE working with Sage 10? --- ## Post 14 by @strarsis — 2022-09-10T11:58:01Z Incredibly busy right now. When I finish with the FSE theme I will surely tell you about it. --- ## Post 15 by @strarsis — 2022-10-20T16:14:15Z 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](https://github.com/WordPress/gutenberg/issues/45170) 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. --- ## Post 16 by @strarsis — 2022-10-21T23:12:39Z @slowrush: Alright, I prepared a new Sage 10 Full Site Editing (FSE) example project: > **[GitHub - strarsis/sage10-fse: Sage 10 theme adjusted for Gutenberg Full Site...](https://github.com/strarsis/sage10-fse)** > > Sage 10 theme adjusted for Gutenberg Full Site Editing (FSE) - GitHub - strarsis/sage10-fse: Sage 10 theme adjusted for Gutenberg Full Site Editing (FSE) 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. --- ## Post 17 by @slowrush — 2022-10-27T14:58:58Z 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 :pray: --- ## Post 18 by @strarsis — 2022-12-04T01:21:56Z I also added an example for generic block patterns to the Sage FSE theme now. --- ## Post 19 by @talentreeweb — 2023-11-13T10:57:51Z 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: ![image](https://discourse.roots.io/uploads/default/original/2X/9/9a4615198838dde00f0f8fe026fbaa92d6c03eac.png) Template in wp-admin: ![image](https://discourse.roots.io/uploads/default/original/2X/9/92a5cb89c718b046d40041dce85a4e5bc2d54a4e.png) --- ## Post 20 by @dsturm — 2023-11-13T14:24:36Z 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](https://github.com/zirkeldesign/acorn-fse), 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 :wink: But eventually it’ll help you on this. --- ## Post 21 by @strarsis — 2023-11-13T16:28:50Z @dsturm: Could you create a PR for this in the forked `acorn` repository, that `Sage 10 FSE` uses? > **[GitHub - strarsis/acorn at patch-1](https://github.com/strarsis/acorn/tree/patch-1)** > > patch-1 Edit: I just noticed that there is already a forked `acorn` with some FSE adjustments: [https://github.com/zirkeldesign/acorn-fse](https://github.com/zirkeldesign/acorn-fse) Maybe that one should be required in `Sage 10 FSE` theme instead, until the adjustments were also merged into upstream `roots/acorn`? --- ## Post 22 by @dsturm — 2023-11-14T07:43:45Z Hej @strarsis, the mentioned repo ([GitHub - zirkeldesign/acorn-fse: A Roots Acorn package, to provide FSE compatibility for Sage 10.](https://github.com/zirkeldesign/acorn-fse)) is a separate `acorn` package, which will be installed parallel to the origin `roots/acorn`. In this package, I tried to have a solution which support an unpatched `acorn` and uses Providers to remove the original template filters and sets the modified ones to support FSE and hybrid rendering. Since it is WIP, it currently lacks some documentation and further testing. --- ## Post 23 by @talentreeweb — 2023-11-14T09:41:24Z Any tips on this? I replaced the filterTemplateHierarchy() -function content with your suggestion, but the blade -templates still are not working. If I dump the array using your code, I get the following: ![image](https://discourse.roots.io/uploads/default/original/2X/9/93f5fec599af03cdfb0200efbcbd527de1bfd72b.png) ![image](https://discourse.roots.io/uploads/default/original/2X/3/3d9e88fbfcc1ce8d211cf5e6c65312d95abd54a0.png) --- ## Post 24 by @dsturm — 2023-11-14T09:52:50Z Hej @talentreeweb, so, what is your current frontend output? I didn’t mentioned, that I also had to modify the patched [`filterTemplateInclude` method](https://github.com/strarsis/acorn/blob/95c5f0bf3f4ecf3f4be8ffb6cb34b1c14a2f16c2/src/Roots/Acorn/Sage/Concerns/FiltersTemplates.php#L31) and added a check, if an existing file is NOT a blade file: ``` public function filterTemplateInclude($file) { if (@file_exists($file) && ! str_contains($file, '.blade.php') ) { return $file; } ... ``` * * * Secondly, the `filterTemplateHierarchy()` method will prefer FSE template files over blade. So, if that does not fit you, you might change the `array_merge()`. --- ## Post 25 by @talentreeweb — 2023-11-14T10:58:20Z Hi, I edited the filterTemplateInclude -function as you suggested, but still no success. I have a page called ‘Sample page’ which uses the (blade) template template-test-blade.blade.php. The pages element gets the template: ![image](https://discourse.roots.io/uploads/default/original/2X/8/87aa7b1d7b35a815ee8f2d6329c439c2ec51165b.png) In the blade -template file, I have: ![image](https://discourse.roots.io/uploads/default/original/2X/6/6205cfe2dd6cf2d0307d6046aaa6090d6b6104f6.png) But none of the h1 Elements are printed to the page in the frontend. It only shows the blocks I have added in the Gutenberg editor. When dumping the wp\_die(var\_dump(array\_merge($files, $fse\_paths, $hierarchy))); inside the filterTemplateHierarchy -function, it gives: ![image](https://discourse.roots.io/uploads/default/original/2X/9/91a030d799b2c743b51ce36ed92b36443baac8e9.png) Also, if I just return the $hierarchy the template works, but the FSE templates do not work: ![image](https://discourse.roots.io/uploads/default/original/2X/b/bfaf66a02305b770196930a3e0481f0d23621b88.png) Page using blade template: ![image](https://discourse.roots.io/uploads/default/original/2X/d/d2bc6a5a6467195ffa8e190df87808d3adb87de5.png) Page using FSE template, no styles here at all: ![image](https://discourse.roots.io/uploads/default/original/2X/7/70bcf26b3e0936c0ca9b92a6eb1bbce6088bceb2.png) --- ## Post 26 by @dsturm — 2023-11-14T11:18:14Z Custom templates didn’t work yet. But I think I found the solution: ``` 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); // Extract all entries, which point to a custom blade template (e.g. template-foo.blade.php) $custom_template = get_page_template_slug(); $custom_template_paths = []; if ($custom_template) { $custom_template_paths = array_filter($hierarchy, static fn ($file) => str_contains($file, $custom_template) ); $hierarchy = array_diff($hierarchy, $custom_template_paths); } // Rebuild hierarchy with original $files and FSE paths on top. return array_merge($custom_template_paths, $files, $fse_paths, $hierarchy); } ``` Could you test this? It worked for me with standard, custom FSE and custom blade templates. --- ## Post 27 by @talentreeweb — 2023-11-14T12:49:53Z Hi, Tested and it works! Thank you! --- ## Post 28 by @strarsis — 2023-11-14T18:04:15Z @dsturm: Related PR: [Template hierarchy filter: Preserve existing paths by strarsis · Pull Request #141 · roots/acorn · GitHub](https://github.com/roots/acorn/pull/141) But that PR does not handle hybrid (Blade-PHP templates instead of FSE block templates) correctly. It would be great if your `acorn` fork could be merged into upstream. --- ## Post 29 by @dsturm — 2023-11-15T10:43:09Z @strarsis I’d like to contribute / PR this. But I need to do some more modifications and tests, since I ran into some issues while using this with a standard `sage` install. :thinking: --- ## Post 30 by @dsturm — 2023-11-16T10:53:45Z I have now opened a PR to merge the changes into `roots/acorn`: > > > While we already have a pull request (PR) for full-site editing (FSE) support by… @strarsis (#141), this PR further enhances these modifications and now supports hybrid templates (Blade-PHP and FSE block templates, currently with priority given to the latter). > > ### Requirements theme > > To enable FSE support, the theme (`sage`) **requires** some modifications: > > 1. Since we use `wp_is_block_theme()` to check for FSE themes when altering the theme hierarchy, `templates/index.html` needs to exist. > 2. Currently `sage` [removes theme support for FSE](https://github.com/roots/sage/blob/be5281cdd178cb1faba9d8bba8185d6f6c1c4caf/app/setup.php#L52) - we need to remove / comment out this line. > 3. Because the generated CSS for blocks will be created in `wp_head()` action hook, the [current position](https://github.com/roots/sage/blob/be5281cdd178cb1faba9d8bba8185d6f6c1c4caf/index.php#L14) of the `view(...)->render()` method is too late and would result in empty styles for rendered blocks. Therefor, we need to [call it prior to `wp_head()`, store it in a temporary variable and echo it later](https://github.com/dsturm/sage/blob/5912c37dad81dcc2770b6f809f6b5ffa79ab4ac1/index.php#L6). > > ### Test this PR > > Optionally create a new Bedrock project > ```bash > composer create-project roots/bedrock > ``` > > Use / require acorn fork and setup (minimal) prepared sage theme > ```bash > # Require PR / fork > composer config repositories.acorn-fse vcs https://github.com/dsturm/acorn > composer require roots/acorn:dev-fse > # Clone new (sage) theme > cd web/app/themes > git clone -b fse https://github.com/dsturm/sage sage-fse > cd sage-fse > # Build > composer i -o && yarn && yarn build > # Activate theme > wp theme activate sage-fse > ``` > > ### Ideas > > To use block patterns like `header` or `footer` in blade templates / views, I wrote [two directives](https://github.com/dsturm/sage/blob/5912c37dad81dcc2770b6f809f6b5ffa79ab4ac1/app/Providers/ThemeServiceProvider.php#L34) which are currently located in my [prepared `sage` fork](https://github.com/dsturm/sage), but should be located in `roots/acorn`: > > [**@blocktemplate('template-part')**](https://github.com/dsturm/sage/blob/5912c37dad81dcc2770b6f809f6b5ffa79ab4ac1/app/Providers/ThemeServiceProvider.php#L39) > > This will render the specified block part (i.e. `header`) and fallback, if FSE is not enabled. > ```blade > > ``` > > [**@parseblocks**](https://github.com/dsturm/sage/blob/5912c37dad81dcc2770b6f809f6b5ffa79ab4ac1/app/Providers/ThemeServiceProvider.php#L36) > > If FSE is supported, this will render all blocks. > > ```blade > @parseblocks > > > @endparseblocks > ``` > > ### Questions > > 1. Which template type should be given priority: FSE or Blade? > 2. Do we need configuration for FSE options (in `config/view.php`) - like enabling/disabling FSE or setting template hierarchy priority? > 3. Should we include the directives into `roots/acorn`? > 5. How should we handle the FSE requirements. Should we have a `fse:init` command for acorn which will publish stubs and ensure we do not have `remove_theme_support('block-templates')`? > > ### Useful resources > - https://discourse.roots.io/t/full-site-editing-fse-frontend-doesnt-load-template/21574/27 > - https://fullsiteediting.com/lessons/how-to-use-php-templates-in-block-themes/#h-making-sure-that-wordpress-loads-the-block-css