Attempt to create a FSE theme

[bobbingwide]

Follow the instructions to create an FSE theme...
https://developer.wordpress.org/block-editor/tutorials/block-based-themes

Note: I've called the theme Fizzie since it sounds a bit like what you'd say if you quickly read out the letters F S E.
Where F = Full, S = Site and E = Editing.

Fizzie is/was the affectionate term for the Yamaha FS1E moped from the early 1970's.
It was a hybrid; more motorcycle than bicycle. It had pedals but you never rode it without starting the engine.

The Fizzie theme may also be considered to be a hybrid, with FSE template parts using server rendered shortcodes rather than native blocks. This is so I can implement the required functionality as quickly as possible.

[bobbingwide]

After creating the 3 standard files in the Creating the theme section, the results vary depending on the selected Experimental settings:

FSE	Demo templates	Action	Result	Because
N	N	View the site	Empty page	index.php is empty
N	Y	View the site	Empty page	index.php is empty
Y	N	View the site	No matching template found	?
Y	Y	View the site	See screenshot	Displays gutenberg/lib/demo-block-templates/front-page.html

Obviously it's not enough. I need to follow more instructions... Creating the templates and template parts

[bobbingwide]

Results after adding template parts and the main template ( front-page.html ) to the theme.

FSE	Demo templates	Action	Result	Because
Y	N	View the site	Template Part Not Found Template Part Not Found	Bug on windows - see below
Y	Y	View the site	See previous screenshot

Having debugged the first Template Part Not Found problem I developed a workaround fix and raised an issue WordPress/gutenberg#26010

I then looked at the message from the demo template. This was not found since the demo template tries to embed the
header from

<!-- wp:template-part {"slug":"header","theme":"twentytwenty"} /-->

1. In my site the active theme is not twentytwenty, but fizzie.
2. when changed to 'fizzie' it initially suffered the same problem as before.
3. When corrected it used my locally created header.html.
4. So I copied the one from the demo into my theme.

Note: the template part embedding logic doesn't appear to use the gutenberg/lib/demo-block-template-parts folder except in create_auto_draft_for_template_part_block().
In my development environment this logic doesn't create any auto-drafts.
I'm not sure what's supposed to happen, so moving on to the next thing.

[bobbingwide]

This is the current position.

1. I've started to create the theme's templates and template parts
2. Initially they were just .html files but since starting Style fizzie to be the same as genesis-a2z #4 I've been using the Site Editor (beta) and Appearance > Templates and Appearance > Template Parts to edit the theme using WordPress.

Now I need to

3. Export the templates and template parts to a .zip file.
4. Update the theme's files - extracted from the .zip file.
5. Check they're OK.
6. Zip it up and try the theme in another installation.

then
6. Further develop the theme.
7. Repeat the process.

[bobbingwide]

3. Export the templates and template parts to a .zip file.

• In Site Editor (beta) use More tools & options > Export to Download your templates and template parts.
• The .zip file is called edit-site-export (n).zip
• I chose to save it in \apache\htdocs\downloads\FSE

The structure of the .zip file is

\theme
   \block-template-parts
     template-part-name.html
     ...
   \block-templates
     template-name.html
     ...

[bobbingwide]

4. Update the theme's files - extracted from the .zip file.

I did just that, extracted the files from the theme folder directly into fizzie, replacing the existing files from the original development.

Notes on subsequent updates to these comments

• I'm now revisiting these problems and taking screen captures as I repeat the process of documenting and resolving the problems.
• This time I'm going to commit the changes as I make them.
• So the first commit will effectively destroy the theme for any site other than s.b/wp56
• The theory is that I should be able to find out what I actually saw after the initial import of the .html files.

5. Check they're OK.

In a different environment I then tried to check that they were OK.

The first problem was "Template part not found", appearing twice.

• I resolved the first message by implementing the alternative fix to Gutenberg issue 26010.; use validate_file() against $attributes['slug'].

The results changed. Template part not found was only displayed once.

• For the second problem I needed to know the value of $attributes['slug'].
• I discovered that the problem was that the post identified by $attributes['postId'] was not present, so get_post_status() would return false.
• The elseif ( isset( $attributes['theme'] ) && wp_get_theme()->stylesheet === $attributes['theme'] ) would then be run
  to see if there was a template part in the database for the selected theme,if that theme was the current theme.
• When the theme matched, but the wp_template_part didn't exist, then the logic would find the template part's .html file.
• When the theme didn't match it wouldn't look for the .html file.

I noticed that the value of the theme attribute varied, with 3 different values: "", "fizzie" and "custom".

So, some of the template parts were found and others were not.

These facts indicate that I needed to change the theme's block-templates files to:

• remove the postId attributes.
• set the correct value for the theme attribute.

e.g. change

<!-- wp:template-part {"postId":561,"slug":"footer","theme":"fizzie"} /-->
<!-- wp:template-part {"postId":723,"slug":"page-content","theme":"custom"} /-->

to

<!-- wp:template-part {"slug":"footer","theme":"fizzie"} /-->
<!-- wp:template-part {"slug":"page-content","theme":"fizzie"} /-->

There was one other problem. What was the post that was displayed in the screenshot?
Answer. It was the post returned from the call to get_post_status() when trying to find the template part for header-2-columns.

<!-- wp:template-part {"postId":665,"slug":"header-2-columns","theme":""} /-->

The code that mistakenly found this post is:

if ( ! empty( $attributes['postId'] ) && get_post_status( $attributes['postId'] ) ) {
		// If we have a post ID and the post exists, which means this template part
		// is user-customized, render the corresponding post content.

Here's the saved query:

           [23] => Array
                (
                    [0] => SELECT * FROM wp_posts WHERE ID = 665 LIMIT 1
                    [1] => 0.00045490264892578
                    [2] => require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('C:/apache/htdocs/wordpress/wp-content/plugins/gutenberg/lib/template-canvas.php'), gutenberg_render_the_template, do_blocks, render_block, apply_filters('pre_render_block'), WP_Hook->apply_filters, gutenberg_render_block_with_assigned_block_context, WP_Block->render, {closure}, gutenberg_render_block_core_template_part, get_post_status, get_post, WP_Post::get_instance
                    [3] => 1603912044.9733
                    [4] => Array
                        (
                        )

                )

This post was an autosaved revision of a post that was created over 2 years ago! The published post was 663.
Three other queries were performed for post IDs 723, 745 and 561, trying to load template parts called page-content, page-footer and footer.

Note:

• I don't know what caused the value of the theme attribute to vary. It could be that some times I edited the templates and template parts using the Site Editor (beta) and other times edited the CPTs directly.
• Also note that sometimes editing the CPTs directly caused an out of memory problem due to an infinitely descending loop of action hooks the_content and render_block ( check hook name! ).

It wasn't immediately clear which template was being used.

[bobbingwide]

The next problem was one I'd found earlier.
My settings were to display Your latest posts but the front-page template was being used.
It therefore displayed just one post.

Workaround

Change to displaying a static page.

[bobbingwide]

Then there were further problems:

• No image was being displayed in the site logo.
• Navigation menu blocks were hardcoded inside the templates, linking to the original site.

[bobbingwide]

No image was being displayed in the site logo.

• The missing site logo problem can be fixed by adding a Site logo block to any content and setting the image.
• This will then be used in other instances of the Site logo block.
• The block can then be removed from the post/page.
• The Site logo remains. The post ID of the image is stored in wp_options with key site_icon.

[bobbingwide]

These facts indicate that I needed to change the theme's block-templates files to: remove the postId attributes.

The fact that the postId is exported is a known bug WordPress/gutenberg#25845.
A fix has been developed.

The possibility that the postId attribute could be maliciously modified such that it refers to private content has not been addressed.

[bobbingwide]

• Navigation menu blocks were hardcoded inside the templates, linking to the original site.

I asked the following on #core-editor

I have a question regarding Navigation blocks and FSE. Where can I find notes explaining how the Navigation is supposed to work. What's the FSE equivalent to registering nav menu locations. At present nav menus appear to behave as static blocks. How is a theme supposed to indicate 'this is where you can put your menu'? Even if it's not yet implemented, I still want to know where the requirements and proposed solution is documented. thanks in advance

One reply was:

The issue though is that currently if you do not register a menu, the navigation screen in the admin is not shown, and that won’t be deprecated. So there still needs to be some alignment between the old and the new.

I've therefore added a comment to the code in functions.php, confirming that nav menus need to be registered.

/**
     * You need to register nav menus in order for admin to display Appearance > Menus
     * and for Navigation (beta) to allow you to Manage locations.
     * But it's not at all clear how you indicate these locations in the theme's templates
     * and the core/navigation block doesn't refer to a menu name.
     * 
     * Additionally, I can't see how the server side rendering adds the class names required
     * to allow the menu to display the current selection.
     */
    register_nav_menu( 'header', 'Header menu');
    register_nav_menu( 'footer', 'Footer menu');

Another reply was:

This idea of "a defined place for a menu" is likely to not have a place in a block based theme.

So how does a Theme designer create templates that contain menus?

• Are the menus just blank?
• If so, does the end user have to edit the templates using the Site Editor in order to populate the menu?
• What if the theme is then updated and the templates are changed?

If I could find the right place to raise an issue on Gutenberg then I would. In the mean time, I'll continue to develop the theme and discover what the workflow is when I attempt to create a new release for trying on another site ( e.g. s.b/cwiccer ).

[bobbingwide]

Also note that sometimes editing the CPTs directly caused an out of memory problem due to an infinitely descending loop of action hooks the_content and pre_render_block.

I'm going to raise this as a separate issue to see if this is something I've done or a problem with Gutenberg itself.

[bobbingwide]

I resolved the first message by implementing the alternative fix to Gutenberg issue 26010.; use validate_file() against $attributes['slug'].

I've submitted a PR for this: WordPress/gutenberg#26772

[bobbingwide]

Yesterday I took the plunge, and switched themes on my local version of blocks.wp-a2z.org ( blocks.wp.a2z ) from genesis-a2z to Fizzie.
Even though the theme isn't finished - there are known problem areas, both with Fizzie and with Gutenberg - I believe it's good enough to be a Minimum Viable Product.

I imagine there will be many changes to Gutenberg's Full Site Editing capability over the coming months and we won't see it in core until WordPress 5.7 or 5.8.

I'm not yet ready to take the risk of migrating the live site to a Full Site Editing theme.
But after 5 weeks hard work, I reckon this issue can soon be closed.
Before that I'll have to review what I consider to be a Minimum Viable Product.

Let's hope the next theme will be quicker and easier.

[bobbingwide]

I'm not yet ready to take the risk of migrating the live site to a Full Site Editing theme

I've updated the Gutenberg source to 9.4.0-RC1. Now I get No matching template found.
There have been some changes with template and template part synchronization.
They don't seem to take into account sites where the FSE theme is wholly implemented in files, not in the database.
Also, it's a WordPress Multi Site environment.
Raising a separate issue to perform problem determination.

[bobbingwide]

Fizzie v0.7.0 was released on 2021/08/03. Closing therefore.