When I first started developing Fizzie I created a front-page.html template.
I found that this was being used even when the Your homepage displays radio button was set to Latest posts
See #1 (comment)
This was very early days, before the core/query block did anything like I expected it to.

Now, with Gutenberg 9.4.0 I'm seeing the wrong templates being used to display my content.
I need to document what I expect for particular URLs and to confirm the results with Gutenberg 9.3.0 and 9.4.0.
Refer to https://developer.wordpress.org/files/2014/10/Screenshot-2019-01-23-00.20.04.png

These results were determined for my non-FSE themes genesis-hm and genesis-a2z
The template files are .php files.

page-* represents multiple levels of specificity: page-slug, page-ID, page

Originally raised as #38, I'm raising this as a new issue since I think it's better to track it down now if it's a core problem rather than a Gutenberg problem. It would be easier if it's a Gutenberg problem because I'll be able to fix it.

Problem is that the navigation menus don't appear at all.

In the genesis-a2z theme the following PHP templates are used for the oik-plugins CPT.

Single page - single-oik-plugins.php
Archive page - archive.php

Requirement

Create FSE templates for both of these.

• single-oik-plugins.html
• archive-oik-plugins.html

Single page template parts

• Header
• Breadcrumbs
• Content

• Information
• Download
• Search
• Page footer
• footer

In the screen captures Content and Page footer are only partially shown. Footer is not shown at all.

Archive page

• Header
• Letters selection
• Breadcrumbs
• Category description. Is this really necessary for the Letters category?
• 3 column display of block title with link and featured image
• Search
• Page footer
• footer

Note: The 3 column display is different from that already delivered in archive.html, which uses category-query.html.
Looks like archive.html should use a different template part to implement the 3 column main query.

In blocks.wp-a2z the widget areas are mostly populated by shortcodes.
These don't appear to work in the template parts used in Full Site Editing.
Is this a limitation of Full Site Editing or am I doing something wrong?

Answer: Something wrong.
I added a shortcode to the content of the page and they all started expanding.
It looks like I'll need to implement some logic to ensure shortcodes are enabled when it's a FSE theme.
It could be as simple as do_action( "oik_add_shortcodes" ); in functions.php

Having updated WordPress to 5.6-RC1, and Gutenberg to 9.4.0, my menus in s.b/wp56 don't appear at all.
No messages. Just blank spaces. There's also a different template being used.

With 5.6-RC1 Settings > Reading
it appears that there's no setting for your homepage displays

I recently noticed that when I changed the Site Title on Settings > General
the values I'd chosen for Your homepage displays on Settings > Reading were lost.

The unexpected result was that the template being used by Gutenberg FSE changed from front-page.html to home.html.

On deeper investigation I determined this be an upstream bug in Gutenberg 9.3+.
The version of WordPress is immaterial.

To reproduce:

1. Ensure you have Gutenberg 9.3.0 or 9.4.0
2. Visit Settings >Reading and set values for Your homepage displays. eg Static page: Home and Blog
3. Visit Settings > General
4. Save Changes
5. Revisit Settings > Reading.
6. The values you set in step 2. have gone. The radio button isn't set.

Screenshots

Step 2.

Step 6.

I updated to Gutenberg 9.4.0-RC1 prior to delivering my fix for #35.
On blocks.wp.a2z I got "No matching template found".

Problem analysis

Turns out it was a forward slash backslash problem in Windows..

Temporary fix

Change line 128 of lib\templates.php, function _gutenberg_synchronize_theme_templates()

strpos( $path, $template_base_path . DIRECTORY_SEPARATOR ) + 1 + strlen( $template_base_path ),

With the home-query.html template part I noticed a number of white sections which were associated with empty paragraphs.

<!-- wp:group {"className":"posts"} -->
<div class="wp-block-group posts"><div class="wp-block-group__inner-container"><!-- wp:columns -->
    <div class="wp-block-columns"><!-- wp:column {"width":"100%"} -->
        <div class="wp-block-column" style="flex-basis:100%"><!-- wp:query-loop -->
            <!-- wp:group -->
            <div class="wp-block-group"><div class="wp-block-group__inner-container"><!-- wp:post-title /-->

                <!-- wp:post-featured-image {"isLink":true} /-->

                <!-- wp:post-excerpt {"moreText":""} /-->

                <!-- wp:columns -->
                <div class="wp-block-columns"><!-- wp:column {"width":"33.33%"} -->
                    <div class="wp-block-column" style="flex-basis:33.33%"><!-- wp:paragraph -->
                        <p>Published:</p>
                        <!-- /wp:paragraph -->

                        <!-- wp:paragraph -->
                        <p>Last updated:</p>
                        <!-- /wp:paragraph -->

                        <!-- wp:paragraph -->
                        <p>Filed Under:</p>
                        <!-- /wp:paragraph --></div>
                    <!-- /wp:column -->

                    <!-- wp:column {"width":"66.66%"} -->
                    <div class="wp-block-column" style="flex-basis:66.66%"><!-- wp:post-date {"format":"F j, Y"} /-->

                        <!-- wp:post-date {"format":"F j, Y"} /-->

                        <!-- wp:post-hierarchical-terms {"term":"category"} /--></div>
                    <!-- /wp:column --></div>
                <!-- /wp:columns --></div></div>
            <!-- /wp:group -->

            <!-- wp:spacer {"height":39} -->
            <div style="height:39px" aria-hidden="true" class="wp-block-spacer"></div>
            <!-- /wp:spacer -->
            <!-- /wp:query-loop --></div>
        <!-- /wp:column --></div>
    <!-- /wp:columns -->
    <!-- wp:query-pagination /-->
</div></div>
<!-- /wp:group -->

Explanation

• These unexpected white sections were associated with empty paragraphs that had been generated by wpautop()
  run against the content generated gutenberg_render_block_core_template_part() ...
  Actually, my latest version, fizzie_lazy_render_block_core_template_part( ).

I need to check whether or not it's any of my own plugins that are causing this.

I've been creating the theme in s.b/wp56 so the url attribute in the navigation-link blocks is of the form https://s.b/wp56/permalink/

Here's the current footer menu.

<!-- wp:navigation {"orientation":"horizontal","itemsJustification":"center"} -->
<!-- wp:navigation-link {"label":"Blog page","url":"https://s.b/wp56/blog-page/"} /-->

<!-- wp:navigation-link {"label":"home-page","url":"https://s.b/wp56/"} /-->

<!-- wp:navigation-link {"label":"Trying to build Fizzie","url":"https://s.b/wp56/2020/10/trying-to-build-fizzie/"} /-->
<!-- /wp:navigation -->

When I implement the theme on blocks.wp-a2z, blocks.wp-a2z.org and other subdomains I'll want the menu items to point to the current site. I want the correct site url = as provided by site_url().

Proposed solution

In the absence of a solution delivered by Gutenberg, intercept the server side rendering using the same method as documented in #18.

eg

function fizzie_render_block_core_navigation_link( $attributes, $content, $block ) {
    $attributes = fizzie_nav_atts( $attributes );
    $html = gutenberg_render_block_core_navigation_link($attributes, $content, $block);
    return $html;
}

function fizzie_nav_atts( $attributes ) {
    $attributes['url'] = str_replace( 'https://s.b/wp56', site_url(), $attributes['url'] );
    return $attributes;
}

And while we're at it....
Apparently the logic already supports current-menu-item - see
WordPress/gutenberg#25575
so let's see if we can ensure that the current-menu-item class is set.

Looking at the current code, we need to set $attributes['id'] to the value of get_the_ID()
when the current URL is the same as the link's URL.

$is_active   = ! empty( $attributes['id'] ) && ( get_the_ID() === $attributes['id'] );
```

Full Site Editing (FSE) themes have started to appear on wordpress.org. I think it's time to start creating a catalogue of them.
Obviously the one that I know most about is Fizzie, but there are quite a few more I'm aware of. See /bobbingwide/oik-themes/issues/11.

Requirements

• Ability to discover themes
• Archive display of all FSE themes
• Display of individual themes
• Display of the templates and template parts
• Display of other useful information about the theme

Proposed solution

• Add Themes link to the main header menu - linking to oik-themes to display the archive
• Add an archive-oik-themes.html template
• Add a single-oik-themes template
• Make use of improvements to oik-themes plugin

In the genesis-a2z theme we display the Published date ( post_date ) and Last updated date ( post_modified ) at the bottom of the content.
This is followed by an (Edit) link, which enables authorised users to edit the content.

Published: November 6, 2020 | Last updated: November 6, 2020 (Edit)

Requirement

• To display this information in a template area between the content and the information
• Date values to be formatted using the site settings
• Labels either to be text in the template or translatable strings in the theme
• (Edit) link to only be displayed to authorised users

Proposed solution

• implement a new template part called metadates.
  eg

<p>Published: [bw_fields post_date] | Last updated: [bw_fields post_modified] ( edit )</p>

• update style.css / experimental-theme.json as required

Since:

• we are dependent upon oik and oik-fields to display the post meta data in the Information box
• we use oik-blocks to display block icons

in the short term solution for the date fields can be implemented as shortcodes such as [bw_field] or [bw_fields]
which could then be implemented in the oik-blocks/fields block.

The (Edit) link should be a separate shortcode ( bw_edit ) / block ( post-edit )

In the longer term I'd expect these to be implemented as core/post-date, core/post-modified and core/post-edit blocks.

I believe that some of these requirements have already been raised by members of the theme-experiments projects.

In the genesis-a2z and genesis-oik themes for each post we display the Published date, Last updated date and an Edit post link.
These are implemented using genesis shortcodes.

Extract from the genesis-a2z theme.

$string = sprintf( __( 'Published: %1$s', 'genesis-oik' ), '[post_date]' );
	$string .= '<span class="splitbar">';
	$string .= ' | ';
	$string .= '</span>';
	$string .= '<span class="lastupdated">';
	$string .= sprintf( __( 'Last updated: %1$s', 'genesis-oik' ), '[post_modified_date]' );
	$string .= '</span>';
  $string .= ' [post_edit]';
	//$output .= apply_filters( 'do_shortcodes', $string);
	$output .= do_shortcode( $string );

Requirement

• Display the same information in the Fizzie theme.
• Preferably implement as blocks.

Proposed solution

• A single block that can display the required field value and a text prefix.

While developing the archive.html template file I encountered a problem where the Template Part Not Found message was displayed but there was no template name. The only attribute value passed to gutenberg_render_block_core_template_part() was tagName, with a value of div.

Analysis of the HTML comment that formed the wp:template-part block indicated that I was missing a comma between attributes.

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

It would be helpful if the error could be detected and a message produced.

The core/query-pagination block doesn't appear to work at present.
For pages that should be using the main query, I would have expected the pagination to work using URLs with /page/n,
where n is the page number.

I believe it should be possible to add this logic for when the core/query-loop block is the main query.
ie When not within the core/query block.

While testing a solution for issue #27 I started changing the home-query.html template part.
I wanted to use the metadates.html template part to replace the rather complicated ( and ugly ) columns block that I'd used to display Published and Last updated dates.

I noticed that for the second and subsquent posts in the query-loop the [post-edit] shortcode worked but the [bw_fields] ones did not. get_edit_post_link() calls get_post() to find the current post ID.
But the logic for [bw_fields] currently prevents the shortcode from doing anything when the current post is not the global post.
This was done to prevent a sidebar on an archive page from displaying the wrong information.

Proposed solution

I don't want to revert the change to [bw_fields].
If we extend [bw_fields] to work when the id attribute is '.' then this might resolve this problem.

Originally posted by @bobbingwide in #27 (comment)

Requirement

Display a grid of blog post titles in a particular category with the following structure

• Standard header
• Letter pagination menu
• Breadcrumbs
• Category description
• Responsive grid of post title links - 3 columns down to 2 or 1
• with Pagination
• Page footer
• Footer

A similar problem to #7 occurred when I tried to document the core/post-content block.
In the editor, the block was displayed as:

On the front end, the logic that attempts to prevent infinite recursion didn't kick in.

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.

Originally posted by @bobbingwide in #1 (comment)

Problem

• Attempting to use Appearance > Templates to edit a specific template part can lead to a timeout / memory exhausted issue.

With oik-bwtrace activated I got

Fatal error: Allowed memory size of 268435456 bytes exhausted (tried to allocate 585728 bytes) in C:\apache\htdocs\wordpress\wp-content\plugins\oik-bwtrace\includes\class-BW-trace-record.php on line 191

The trace log file was 364MB. The call stack at the end of the trace file was 3647 functions deep.

Requirement

Create a shortcode to be used to implement contents for the category-description template part.

Solution

• Name the shortcode [archive_description].
• Use term_description() to obtain the description.
• Implement for tags, categories and custom taxonomies.

Detected while trying to view https://s.b/wp55/fizzie/category/block-news/

Notice: Trying to get property 'term_id' of non-object in C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\build\block-library\blocks\post-hierarchical-terms.php on line 32

Notice: Trying to get property 'name' of non-object in C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\build\block-library\blocks\post-hierarchical-terms.php on line 33

Fatal error: Uncaught Error: Object of class WP_Error could not be converted to string in
C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\build\block-library\blocks\post-hierarchical-terms.php:33
Stack trace:
#0 C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\build\block-library\blocks\post-hierarchical-terms.php(33): sprintf('...', Object(WP_Error), '')
#1 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(219): gutenberg_render_block_core_post_hierarchical_terms(Array, '', Object(WP_Block))
#2 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(211): WP_Block->render()
#3 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(211): WP_Block->render()
#4 C:\apache\htdocs\wordpress\wp-content\themes\fizzie\functions.php(307): WP_Block->render(Array)
#5 C:\apache\htdocs\wordpress\wp-content\themes\fizzie\functions.php(263): fizzie_render_block_core_query_loop_main_query(Array, '', Object(WP_Block))
#6 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(219): fizzie_render_block_core_query_loop(Array, in C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\build\block-library\blocks\post-hierarchical-terms.php on line 33

Problem

When editing a page the core/query block's sidebar is only offering four post types:

• Post
• Page
• Plugin
• oik plugin version

To be usable the full list should include 13 other post types including:

• Attachments
• oik premium version
• Blocks
• Block examples

Question: So what's going wrong?

The other following offences should be taken into consideration.

• Choosing order by A Z chooses order by Z A on first selection.
• Orderby doesn't appear to work for oik plugins.
• No ability to choose post_parent
• Found post content with the More block produces - this block can only be used once.

It appears I'm not the only one who doesn't really understand how to implement alignfull and alignwide styling on blocks.

Reading the issue entitled "How to style alignfull and alignwide" ( WordPress/gutenberg#8289 ) I can see a number of solutions but can't see any clearly documented requirements.

Whichever solution I go for I should understand my own requirements for Fizzie:

• Initially a single column theme with no sidebars
• then extended to support a theme with sidebars.

These are the widths I'm going to use:

In blocks.wp.a2z and other local subdomains of wp.a2z I need to be able to clone the content to wp-a2z.org

Proposed solution

• Add a block including the [clone][cloned] shortcodes to the footer.html template part.

Warning: array_key_exists() expects parameter 2 to be array, null given in C:\apache\htdocs\wordpress\wp-content\plugins\gutenberg-wordpress-source\lib\block-supports\align.php on line 48

Warning: array_key_exists() expects parameter 2 to be array, null given in C:\apache\htdocs\wordpress\wp-content\plugins\gutenberg-wordpress-source\lib\block-supports\colors.php on line 73

Warning: array_key_exists() expects parameter 2 to be array, null given in C:\apache\htdocs\wordpress\wp-content\plugins\gutenberg-wordpress-source\lib\block-supports\colors.php on line 108

Warning: array_key_exists() expects parameter 2 to be array, null given in C:\apache\htdocs\wordpress\wp-content\plugins\gutenberg-wordpress-source\lib\block-supports\colors.php on line 125

Warning: array_key_exists() expects parameter 2 to be array, null given in C:\apache\htdocs\wordpress\wp-content\plugins\gutenberg-wordpress-source\lib\block-supports\custom-classname.php on line 46

Interestingly the post-excerpt block appeared more like the post-content block and vice-versa.

Well, the post-content block appeared more like an excerpt than post content.
In order to fix this I had to change the core function get_the_content() to set $elements['more'] to true, since generate_postdata() hadn't.

Not surprisingly this didn't resolve the problem with the post-excerpt ignoring the more block.

Originally posted by @bobbingwide in #27 (comment)

Problem

core/post-content when nested in a query in another post's query-loop's core/post-content block is broken by a more block.

While developing my fix for the post-content infinite recursion problem, I became aware of a problem with the display of post content in the nested posts. The workaround I implemented for #27 was to eliminate the more block from the content that was being displayed.

In the above screen capture I've re-introduced the core/more block into the Aab page.
The post content should be 'Aab - excerpt before more. Aab - post content after more.'
The More link shouldn't appear.

In parallel with #1 and #4 it makes sense to play with the experimental theme JSON file called experimental-theme.json.

https://developer.wordpress.org/block-editor/developers/themes/theme-json/

Requirements

• Try to use experimental-theme.json to define the colours and font sizes for blocks such as paragraph, h1-h6 to match the current settings in genesis-a2z
• Improve styling of blocks where I'd noticed problems while populating the block catalog.

Solution

Notes

• genesis-a2z's style.css was 1800 lines, with very little, if any, custom styling for blocks.
• I wondered how much styling I'd have to put into style.css and how much could go in the JSON file

While attempting to document each of the new blocks for FSE I noticed that the Panels in the Settings sidebar were

• Typography
• Colours
• Block's specific settings

Question: Why aren't the Block's specific settings first?

It was pointed out in #core-editor Slack, by Andrés,

the "FSE blocks" (navigation, post editor, etc) follow the model of existing blocks (paragraph, heading), in which the style related controls are above everything else.
Personally, I don't have a strong opinion on this, though. I presume there's a design balance to make here (consistency among blocks but also priority of the most used settings, etc).
Perhaps the G2 components project / design tools would be a good place to re-evaluate this?

An example

Here's a screen capture of the Post date block.

• Which of the Settings am I more likely to want to change?
• Which of the settings are Agencies more likely to want to restrict?

Proposed actions

• Complete the documentation for all the new blocks
• Use them for a while
• See which settings I do use and where they are
• Raise an issue anyway so that other people can express their views.
• Write my own block ( e.g. Post Modified Date or Post Edit ) and see how the Settings panel appears.

While analysing the problems I came across with Gutenberg 9.4.0 I developed an extension to template-part.php which added debug information visible in the front end.
It sandwiched the output for each template part in some debug <div class="WP_DEBUG"> tags
which contained the name of the template part.

I then wrote some naff CSS to enable the information to be viewed on the front end.

Requirements

• Formalise this solution for template parts
• Find a method to automatically produce front end information regarding the template file that's been selected
• Consider ways to easily turn the debug information on and off. e.g. Additional constant ( FSE_DEBUG), logged in admin user.

In #core-editor Slack I asked some simple questions which resulted in quite a few replies.
The result of this was that I decided to extract the navigation menus into separate template parts.
I started with the footer template part and converted the wp:navigation into a new template part called footer-menu.html.
Rather than embedding this directly into the footer template part I decided I'd just put it after the footer in each template.

But I found a problem with the CSS styling.
The footer and footer-menu template were separated with a light grey background between them

I intially thought it was a problem with unexpected characters between the HTML tags.
But these were just line feed characters ( \n aka hex 0a ).

I discovered that it was due to the margin property set on the nested paragraph and list blocks.
I have no idea why the margin on the paragraph was applied the way it did.
That's the wonder of CSS for you I suppose.

When I started styling the nav menu I copied the CSS from genesis-a2z. The screenshot.png I took on 28th October showed the white space.
When I updated to Gutenberg 9.2.2 I noticed the space between menu items disappeared.
This is because there is no longer a blank space between list items.
This can easily be demonstrated using the the code inspector.
In this screen capture, from the genesis-a2z theme, I removed the blank space between a couple of items.

Requirement

Some spacing between the menu items.

Proposed solution

In order to regain the blank space I'll either need to change the CSS, or adjust the markup.
It makes more sense to use CSS.

I first noticed this problem while trying to use bold on a paragraph block in s.b/wordpress.
The Bold, Italic and More rich text controls toolicons are missing
The problem went away when I deactivated Yoast SEO 15.3 (screenshot 2) .
But I couldn't reproduce the problem in other environments.

Time to do some analysis to determine what's causing the problem

A message in the console when it doesn't work is:

react-dom.82e849f1.js:1680 Warning: Failed prop type: You provided a `value` prop to a form field without an `onChange` handler. This will render a read-only field. If the field should be mutable use `defaultValue`. Otherwise, set either `onChange` or `readOnly`.
    in select (created by y)
    in div (created by u)
...

When a core/post-excerpt block is included in a query for pages/posts the post excerpt displayed is for the post that contains the core/query & core/query-loop blocks not the posts that were found.

It seems to work for Gutenberg 9.3.0 but not the Gutenberg source.

Analysis

In wp55 the $block->context['postId'] value is correctly set for each invocation of fizzie_render_block_core_post_excerpt().
It's also correctly set in wp56.

The problem is due to oik-shortcodes adding its own filter function for get_the_excerpt with priority 9.
The filter function oik_get_the_excerpt obtains the excerpt from the global $post.

Since WordPress 4.5.0 the get_the_excerpt filter has been invoked with two parameters $post_excerpt and $post.

Solution

The oik-shortcode plugin should be changed. Two options

1. make use of the $post parameter instead of global $post
2. don't implement the filter.

Trying 1. first.

I've implemented the category.html template as far as possible, with the current Gutenberg FSE functionality.

There are a number of problems:

• the query loop doesn't dynamically use the chosen category.
• pagination doesn't work at all

Requirement

The Gutenberg blocks wp:query, wp:query-loop and wp:query can be used in templates and template parts to create user defined queries and pagination.

Currently ( Gutenberg 9.2.2 ) they don't support the main query that WordPress has already parsed.

This makes it extremely difficult to create archive pages that support the selected taxonomy term ( category, tags or custom taxonomy ).

I need a simple solution that allows me to process the posts in the main query.

Proposed solution

In the current implementation the wp:query-loop block is nested in the wp:query block.
The wp:post-* blocks are nested within the wp:query-loop.

eg

<!-- wp:query {"queryId":1,"query":{"perPage":2,"pages":1,"offset":0,"postType":"post","categoryIds":[],"tagIds":[],"order":"desc","orderBy":"date","author":"","search":"","exclude":[542]}} -->
<!-- wp:query-loop -->
<!-- wp:post-title /-->
<!-- wp:post-featured-image {"isLink":true} /-->
<!-- wp:post-date /-->
<!-- wp:post-excerpt /-->
<!-- /wp:query-loop -->
<!-- /wp:query -->

The query-loop block uses the $block->context passed to it from the query block to construct the query.
When we want to process the main loop we need to execute the query already defined in global $wp_query.

This can be achieved using the following code:

function gutenberg_render_block_core_query_loop_main_query( $attributes, $content, $block ) {
    if ( have_posts() ) {
        $content = '';
        while ( have_posts() ) {
            the_post();
            $post = get_post();
            $content .= (
            new WP_Block(
                $block->parsed_block,
                array(
                    'postType' => $post->post_type,
                    'postId' => $post->ID,
                )
            )
            )->render(array('dynamic' => false));
        }
    } else {
        $content = "No posts found. So why isn't this a 404?";
    }
    return $content;
}

If we remove the outer wp:query block then the $block->context will not be set.
This will prompt us to run the main query.
eg

<!-- wp:query-loop -->
<!-- wp:post-title /-->
<!-- wp:post-featured-image {"isLink":true} /-->
<!-- wp:post-date /-->
<!-- wp:post-excerpt /-->
<!-- /wp:query-loop -->

Steps:

For query-loop:

• Prototype a solution implemented in the callback function for the dynamic block wp:query-loop; gutenberg_render_block_core_query_loop() in query-loop.php.
• Raise an issue against Gutenberg. . No need, there's one already: 25377
• Create a pull request to implement the improvement.

For query-pagination:

• take a similar approach as for query-loop
• Raise a separate issue against Fizzie
• Raise a separate issue against Gutenberg.

In a brand new WordPress Multi Site site I visited
https://s.b/wp55/fizzie/category/uncategorised/
and got the following:

Notice: Trying to get property 'term_id' of non-object in C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\build\block-library\blocks\post-hierarchical-terms.php on line 32

Notice: Trying to get property 'name' of non-object in C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\build\block-library\blocks\post-hierarchical-terms.php on line 33

Fatal error: Uncaught Error: Object of class WP_Error could not be converted to string in 
C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\build\block-library\blocks\post-hierarchical-terms.php:33 
Stack trace: 
#0 C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\build\block-library\blocks\post-hierarchical-terms.php(33): sprintf('<a href="%1$s">...', Object(WP_Error), '') 
#1 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(219): gutenberg_render_block_core_post_hierarchical_terms(Array, '', Object(WP_Block)) 
#2 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(211): WP_Block->render() 
#3 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(211): WP_Block->render() 
#4 C:\apache\htdocs\wordpress\wp-content\themes\fizzie\functions.php(278): WP_Block->render(Array) 
#5 C:\apache\htdocs\wordpress\wp-content\themes\fizzie\functions.php(234): fizzie_render_block_core_query_loop_main_query(Array, '', Object(WP_Block)) 
#6 C:\apache\htdocs\wp55\wp-includes\class-wp-block.php(219): fizzie_render_block_core_query_loop(Array, in C:\apache\htdocs\wp55\wp-content\plugins\gutenberg\build\block-library\blocks\post-hierarchical-terms.php on line 33

<b>Notice</b>:  register_rest_route was called <strong>incorrectly</strong>. 
The REST API route definition for <code>udemy/v1/login</code> is missing the required <code>permission_callback</code> argument. 
For REST API routes that are intended to be public, use <code>__return_true</code> as the permission callback. 
Please see <a href="https://wordpress.org/support/article/debugging-in-wordpress/">Debugging in WordPress</a> for more information. 
(This message was added in version 5.5.0.) in <b>C:\apache\htdocs\wp56\wp-includes\functions.php</b> on line <b>5225</b><br />

plus 4 or 5 more.

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.

In order to test #11 we need a 404 page. In genesis-a2z it's a bit basic.

Requirement

A 404.html page with the following sections

• Header
• Breadcrumbs
• Not found message
• ? The main loop - implemented as a template part
• Search
• Page footer
• Footer

This is a bit of an ask but...
In order to be able to document the blocks that are used in Full Site Editing in blocks.wp-a2z.org I need to enable Full Site Editing.
To achieve this with Gutenberg 9.2.x the theme needs to support:

• a full-width styled header - with logo, site title, site info and menu
• a body with max-width: 1140px
• a widget area below the body - for search
• a footer area with 3 columns
• a full width bottom footer containing a footer menu

The general purpose archive.html template embeds the a2z-pagination.html template part

<!-- wp:template-part {"slug":"a2z-pagination","theme":"fizzie"} /-->

which contains

<!-- wp:paragraph -->
<p>[bw_terms]</p>
<!-- /wp:paragraph -->

By default the [bw_terms] shortcode uses the letters taxonomy.
For Plugins and Themes this is OK.
But for Blocks we need to use the block letters taxonomy.

Thererfore we need separate template files archive-block.html and archive-block_example.html both of which will reference a block-a2z-pagination.html template part that contains the shortcode [bw_terms block_letters].

Also, the post_type attribute needs to be specified.
Therefore we also need archive-oik-plugins.

I wanted to test my rich text localization ( l10n) logic in Gutenberg 9.5.1 so I created a template part called i18n-rich-text.html.
I tried to load it using the Template part block in a page, while in the bb_BB locale.

But in s.b/wp56 I got This block has encountered an error and cannot be previewed even before I had a chance to pick the template part.
I believe this was due to the Template part block trying to display Previews of the blocks and failing to detect recursion.

Note: In s.b/wp55/tt1 - with the recursive template parts I'd created for Twenty Twenty-One Blocks it causes Chrome to time out.

Clearly there's a problem with the Template parts block ( core/template-part ).
But what should I do as a workaround?

To date I've developed local workarounds for a number of issues found in Gutenberg's experimental Full Site Editing solutions.
I summarised the local improvements that I've made so far in #18.

Requirements

In the long term I'd want to see these problems addressed in Gutenberg / WordPress core.
When this has been done, there should be no need for the local workaround.
This issue is to track issues and PRs as they progress through Gutenberg
then to remove the local workaround when it's no longer necessary.

Proposed solution

• Raise a Gutenberg issue for each problem
• Implement a PR to fix the issue.
• Remove the local change when the PR's been merged, or otherwise fixed.

THIS TABLE IS WELL OUT OF DATE - 2022/01/12

I got these messages trying to user The Events Calendar with the Fizzie theme.

Deprecated: Theme without header.php is deprecated since version 3.0.0 with no alternative available. Please include a header.php template in your theme. in C:\apache\htdocs\wordpress\wp-includes\functions.php on line 4973

Deprecated: Theme without footer.php is deprecated since version 3.0.0 with no alternative available. Please include a footer.php template in your theme. in C:\apache\htdocs\wordpress\wp-includes\functions.php on line 4973

With the current implementation of Full Site Editing (FSE) in Gutenberg making a stupid mistake such as embedding a template part recursively results in a Fatal error of some form.

Simple - trivial - example

Here we see the 404.html page failing to display anything due to immediate recursion on a template part.

404.html contains

<!-- wp:template-part {"slug":"header","theme":"twentytwentyone-blocks","align":"full", "tagName":"header","className":"site-header"} /-->

<!-- wp:template-part { "slug":"issue-27", "theme":"twentytwentyone-blocks"} /-->

<!-- wp:template-part {"slug":"footer","theme":"twentytwentyone-blocks","align":"full","tagName":"footer","className":"site-footer"} /-->

The issue-27 template part contains.

<!-- wp:spacer {"height":70} -->
<div style="height:70px" aria-hidden="true" class="wp-block-spacer"></div>
<!-- /wp:spacer -->

<!-- wp:template-part { "slug": "issue-27", "theme": "twentytwentyone-blocks" } /-->

This is a simple example.

Another simple one is where template part A uses template part B which uses template part A.
It gets more complicated when the template parts are sourced from different places.

As mentioned in #23 we need the ability to allow an authorsied user easy access to the editor for a displayed post.
This should work for a single post or for any post listed in a query-posts block.

Requirements

• Ability to display an edit link for the current post
• Displayed to users who have the authority to edit the post
• The link text should be (Edit), by default

Proposed solution

In genesis-a2z this was implemented using the [edit] shortcode.
In oik, a similar capability is implemented in the [bw_pages] shortcode as part of the format= parameter.
A value of lower case e causes the [Edit] link to appear for the current post.
It uses the WordPress core function get_edit_post_link()

/**
 * Format the Edit post link (format=e)
 *
 */
function bw_field_function_edit( $post, &$atts, $f ) {
 $link = get_edit_post_link( $post->ID );
 if ( $link ) {
   BW_::alink( "bw_edit", $link, __( "[Edit]", "oik" ) ); 
 }
}

Every now and then, in the Appearance > Template parts list I notice a number of unexpected (no title) - Draft posts created. These are copies of existing posts. But I don't know what caused them to be created.

For issues #27, #30, and #31, and the original issue #7, I've developed a solution that's not particularly extendable.
I want to deliver my solution as a fix for the issue(s) I've raised on Gutenberg.

But, I don't know how to deliver the solution to Gutenberg such that it can then go into core.

Proposed solution

• Attempt to refactor the solution using classes
• Implement classes that extend the base class to produce block specific problem determination support.

Full Site Editing themes should support internationalization (i18n) and localization (l10n).

The process to extract and localize is summarized by this diagram.

Requirements

• To be able to use the Fizzie theme in the user's selected locale.
• To automatically extract and localize templates and template parts.
• Test with two additional languages:

1. UK English - locale en_GB
2. bbboing's language bb_BB

Proposed solution

• Create localized versions of the templates and template parts delivered by Fizzie.
• Use the automated tools developed in bobbingwide/oik-i18n/issues/7
• Use a batch routine t10n.bat to automate the translation into UK English and bbboing.
• Update Gutenberg and/or Fizzie to support loading of translated templates and template parts
• Test for UK English ( en_GB ) and bbboing ( bb_BB ).

Requirements on Gutenberg

• Gutenberg's template and template loading logic needs to be updated to take into account the user's locale.
• The translated files will be stored in subfolders of the languages folder, with one directory per supported locale.
• If the directory isn't present the US English files are used.

Assumptions, scope, exclusions and caveats

• Templates and template parts are inherently static; they don't implement conditional / looping logic.
• Internationalization (i18n) of the templates and template parts is only necessary for certain strings which should not be translated.
• As such, localized versions can be created at build time, or whenever the translations are updated.
• Blocks used in templates and template parts may implement conditional / looping logic.
• These blocks are usually server side rendered using PHP.
• A theme's PHP code will be localized using makepot.
• Any JavaScript blocks delivered by the theme will be localized using makejson.
• The solution should support all locales and character sets currently supported by WordPress.
• The solution should support themes which are not delivered from wordpress.org

Limitations of the prototyped solution

• t10n.bat is currently dependent upon oik-batch's oik
• The current routines are prototyped batch routines which echo debug information.
• Not all scenarios are yet catered for by the routines invoked by t10n.
• The current solution doesn't merge .pot files into one file prior to translation.
• But text strings used in PHP and template files and parts are not expected to be the same.
• So there shouldn't be too many duplicate strings to translate.

The primary menu displayed in the right hand side of the header doesn't behave nicely when the window gets narrower.
Is this something that the block should cater for or is it the theme's responsibility.

Options

1. Allow it to wrap without having the items overlapping.
2. Switch to a hamburger menu - which is how it's done in genesis-a2z.
3. Make it horizontally scrollable?

While developing the archive.html template file I decided to extract the navigation menus
into separate template parts.
I decided to try two methods.

For the footer menu I extracted the navigation into a footer-menu template part then added this to each template, 9 in all.

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

For the header-2-columns template part I'd extract the navigation into header-menu, including this template as an inner block. Fewer changes.

In Gutenberg there have been at least 3 issues associated with Reusable blocks causing infinite recursion.

WordPress/gutenberg#18704
WordPress/gutenberg#21117
WordPress/gutenberg#22131

The first of these 3 is still open.

I wanted to see if my fix for #27 and #30 could also be applied to issue 18704.

I created a scenario with three reusable blocks named after these issues.

These are in a recursive loop. 1133 -> 1135 -> 1134 -> 1133

I added a reusable block to the 404.html template and achieved the fatal error.
I then overrode the gutenberg_render_block_core_block render_callback
with fizzie_render_block_core_block

function fizzie_render_block_core_block( $attributes, $content, $block ) {
    if ( empty( $attributes['ref'] ) ) {
        return '';
    }
    if ( fizzie_process_this_content( $attributes['ref'] ) ) {
        $html = gutenberg_render_block_core_block( $attributes, $content, $block );
        fizzie_clear_processed_content( $attributes['ref'] );
    } else {
        $html = fizzie_report_recursion_error( $attributes['ref'], 'block' );
    }
    return $html;
}