In my local development environment I've been developing the theme without WordPress SEO being activated.
I activated it for use by the sb-breadcrumbs-block and the server response has more than doubled. Why's this?

In the Genesis-SB theme the "Seen before" field displays the value of the post meta field called _seen_before.
This field is auto-incremented each time the post is viewed individually.

I need to replicate this logic in SB.
I imagine this will have to be implemented as a new block.
It'll give me the opportunity to learn how to access post meta data.

Note: In my first attempt to simply display the current value of the field nothing is being shown for the [bw_field _seen_before] shortcode.

This is a follow on issue related to #31 where I wrote

It's not so easy to reduce the amount of work that the filter function has to do for other queries.

• Checking for is_main_query() is useless; every query is considered the main query.
• One tiny improvement is to only call get_post_thumbnail_id when the post is a bigram.
• Investigating what the actual query is doing is prone to error due to increased complexity.

Looking at the trace output for each invocation of the genesis_sb_the_posts() filter function, which is called 22 times on the
home page, we can see

• a number of queries which don't need to be filtered.
• and others which shouldn't have been needed in the first place

Note: the_posts is invoked from WP_Query::get_posts(). It is preceded by many other filters including pre_get_posts, which is hooked into by bigram and oik-types to adjust the post types to be listed.

Queries that don't need to be filtered include queries for wp_template and wp_template_part: the FSE theme locating templates and template parts

The unnecessary query was invoked from gutenberg_render_block_core_query_no_results(), which is the server rendering for the wp:query-no-results block.
The saved queries output for this query is:

        [47] => Array

            [0] => (string) "SELECT SQL_CALC_FOUND_ROWS  wp_posts.ID FROM wp_posts  WHERE 1=1  AND ((wp_posts.post_type = 'post' AND (wp_posts.post_status = 'publish' 
OR wp_posts.post_status = 'private')))  ORDER BY wp_posts.post_date DESC LIMIT 0, 1"
            [1] => (double) 0.00086402893066406
            [2] => (string) "require('wp-blog-header.php'), require_once('wp-includes/template-loader.php'), include('wp-includes/template-canvas.php'), get_the_block_template_html, do_blocks, render_block, WP_Block->render, sb_render_block_core_template_part, do_blocks, render_block, WP_Block->render, WP_Block->render, WP_Block->render, WP_Block->render, sb_render_block_core_template_part, do_blocks, render_block, WP_Block->render, WP_Block->render, gutenberg_render_block_core_query_no_results, WP_Query->__construct, WP_Query->query, WP_Query->get_posts"
            [3] => (double) 1652252151.8039
            [4] => Array

The current page in genesis-sb is:

In genesis-SB the Post Author section is displayed below the post.

• Self Bio links to the bigram/self-bio, which basically contains the same of the user's bio
• The gravatar is a gravatar
• The Bio is the user's bio and is passed through the_content filtering to create any SB links

Proposed solution

• Implement a post-author.html template part that uses the post-author block or similar.
• Override the post-author block to run the_content filter using bigram_the_content.
• It would be nice if styling could be done using theme.json
• Failing that wrap the post-author block in a group with a light grey background

In the Site Editor this first pass at the footer area seems reasonable.

But these are a number of problems.
This is what I see in the front end.

Problems

1. Front end - Tag cloud in the front end is displayed with <br /> between each link - when formatted in a column.
2. Editor -Tag cloud colour cannot be set
3. Front end - White colour for the headings has not been respected
4. Editor - Accidentally clicking on a tag cloud link leaves the Site Editor - changes not saved.
5. Editor - Tag clouds only work for certain taxonomies
6. Front end - Group block - no matter what I do it's always full width.

There are currently major performance problems attempting to use the Site Editor to edit the SB theme. See #6.

In order to determine what's causing these problems I want to be able to test the theme in multiple environments, with fewer activated plugins.

Requirement

The block override logic should work even when Gutenberg is not activated.

Proposed solution

I implemented this for Fizzie. Similar code will be needed in the block overrides for SB.

1. The sb_maybe_override_block() function needed check the currently assigned render_callback function
2. Each block override function that references a gutenberg_ prefixed function should test for its existence before calling it.

After deleting a template part using Move to trash the following error message was displayed.

Updating failed. No templates exist with that id.

Several problems here.

1. I shouldn't have remained in the block editor after performing the delete.
2. The message says "templates" not "template parts"
3. What's "that id"?
4. I clicked on Move to trash again. This time I got "No templates exist with that id."

In this example I was in the Code editor.
The template part had been deleted.

While attempting to recreate the problem in Visual editor mode:

• the Move to trash button ran Updating
• and then Post updated slid up from the bottom.
• the template part had not been NOT deleted

In the Genesis-SB theme the home page and certain archive pages display the result of the main query in three parts.

• Hero
• Thumbnail grid - up to 4 by 4
• Links section

followed by a pagination block.

60 bigrams are displayed per page.

The logic I need to replicate includes a routine to rearrange the posts per page so that those with a Featured image come first.
This is genesis_sb_the_posts( $posts, $query ) which is hooked into the_posts. It's run on every page.

Note: I assume there'll be at least one featured image in a block of 60 bigrams.

Then in the loop to display the posts there's logic to check which format to use, based on the index and the number of posts which have a featured image.

function genesis_sb_do_loop() {
	$count = 0;
	$images = genesis_sb_featured_images( 1 );
	
	if ( have_posts() ) {
		while ( have_posts() ) {
			the_post();
			//do_action( 'genesis_before_entry' );
			if ( $count == 0 ) {
				genesis_sb_hero();
			} elseif ( $count < $images  ) {
				genesis_sb_images();
			} elseif ( $count == $images ) {
				printf( '<div %s>', genesis_attr( "links" ) );
				genesis_sb_after_images();
            } else {
				genesis_sb_after_images();
			}
			$count++;
		}
		echo '</div>';
		do_action( 'genesis_after_endwhile' );
	} else {
		do_action( 'genesis_loop_else' );
	}
}

• genesis_sb_featured_images() will return 0, 4, 8, 12 or 16
• it uses genesis_sb_full_rows() to determine this
• genesis_sb_hero(), genesis_sb_images() and genesis_sb_after_images are the functions being replaced by the three query blocks.

Proposed solution

• I'll implement the the_posts filter first.
• I have to find a way of detecting which query block is being processed to determine which of the (up to 60) posts returned in the main query should be processed per block.
• I'm going to try to override the gutenberg_render_block_core_query_loop() to either fiddle with the main query's posts or handle the loop myself.
• The override logic will be similar to the solution for Fizzie; I've already implemented logic to override tag-cloud and template-part.

When I was writing the readme file yesterday I wrote some notes explaining why SB would be harder to develop than Fizzie.

In some respects, even though it should consist of fewer templates and templates parts, SB will be harder to achieve since there is some PHP logic for the home page which I imagine will be more than tricky to implement. I believe I will need to find a method to override server side logic for the query loop blocks. Now I think about it, I reckon I can implement a solution. I supposed I'd better design it first. So I'm going to stop writing this and continue with the "programmming".

Well today I started trying to use the Site Editor to create 3 different query blocks
that I would then fiddle with during server side rendering to
achieve the same logic as implemented in the Genesis-SB theme.

I didn't get very far. I duplicated the first query block then tried to change the Offset to 1 and posts per page value to 60.
The main editor area went white. There were very many errors in the Console. I'll need to start with a clean slate.

SB v0.2.1 is functionally working fine. There are a couple of styling issues on my iPhone 13 mini and iPad.

• metadates wrapping
• no margins
• drop down menu styling for Sulphurous Brewmasters and Some Background
• font for tables could be smaller and/or horizontal scrolling supported
• Site Building menu minimises to hamburger

I updated my local development environment from WordPress 5.7.1 to 5.8 and noticed that the footer widget area was restyled.

Was in 5.7.1

Now in 5.8

sb doesn't yet use theme.json, it still uses experimental-theme.json. This could be part of the problem. No harm in implementing it anyway.

In the live site the menu-in-menu plugin is used to complete the drop down menus.
There are 4 sub menus: SB, Selected Bits, Section B and Specially Built.

What's the easiest way of incorporating these menus into the main menu?

• Can it be done with drag and drop?
• If not, then I'll just have to add the menu items individually.

Requirement

• Main menu to match the existing live site
• Easiest way to implement
• Also, the styling still needs improving.

Proposed solution

• Try implementing with Drag and Drop in the Site Editor or tempate part editor
• If that fails do each item manually

Update code to run without problems in PHP 8.1, PHP 8.2, and PHP 8.3 with WordPress 6.4.1

See bobbingwide/bobbingwide#103 and bobbingwide/bobbingwide#114

In seriouslybonkers.com I used to use oik-widget cache to cache the contents of the sidebar widgets.
But there was a probem with caching of the Sequentially Biased widget since it supports pagination;
see bobbingwide/oik-widget-cache#3

oik-widget-cache has been deactivated for a while, but I can't remember why I did it.

Anyway, now that the widgets are implemented as blocks I'm wondering if there's a server performance benefit to caching a selection of the widgets? ie. Can some of the template parts be cached?
If so, how do we go about doing it?

Possible solution

• Since we're already implementing override logic on template-parts we could implement a className attribute of "cache" on the template part. When this is detected then we'll look to see if there's a cached version.
• The logic should also take into account the fact that the template-part is newer than the cached version.
• If so, then it should use the new template part and re-cache the output.

In WordPress/gutenberg#29335 a solution has been developed that make alignments more declarative.
ie A new solution makes it a lot easier to use alignwide and alignfull. I believe this means you no longer need a ton of confusing CSS.

Since SB is a brand new theme I feel I should implement the solution in this theme first.
Later, when comfortable with the solution, and when a run time version of Gutenberg is delivered, I should apply it to Fizzie as well. See http://github.com/bobbingwide/fizzies/issues/44

Requirements

As for Fizzie. Properly support alignwide and alignfull, but with widths as below

Solution

• Switch to using a newly built version of gutenberg-source
• remove assets/alignments-front.css - I'd already done this
• Change experimental-theme.json replacing "custom" with "layout"
• Implement `{"layout": {"inherit": true }} attribute on relevant blocks in templates/ template parts
• Try using different blocks with different widths.

Which is basically the same as for WordPress/theme-experiments#233

Caveat
I don't know what to expect with the sidebar.

Two changes in one here, both for the Stupidly Brilliant category

1. As for wp-secrets, I want to be able to style AI prompts and AI responses to show the prompts fed into the AI tools.
2. Also, since the default image is 1024x1024, I want to reformat the output off singular.html to display a larger featured image.
3. This either means putting the content below and not side by side, or moving the sidebar below.

Vertical menus were being displayed with flex styling.

Also the "Table of title, post-name, S B" link was being doubly linked due to the S B string being filtered.
This didn't happen when the menu was in a widget.

While investigating the creation of Sampled Bigrams I noticed that the most recent bigram didn't appear to be listed in the Dashboard > All bigrams display.

This was true for both SB and the genesis-SB theme.
I had considered mentioning the problem on the UK Slack channel. But a couple of hours later, while looking at reducing the number of times genesis_sb_the_posts() gets called or actually does stuff, I realised that it was this function that was affecting the display of posts in the Dashboard.

Explanation

Since the most recent post was a Sampled Bigram it didn't have a featured image.
So, even though it was being sorted to the top by the query that was run, it got demoted to behind the posts that did have featured images.

Problem resolution

Adding an early check on is_admin() resolves the issue for the Dashboard post listing.

It's not so easy to reduce the amount of work that the filter function has to do for other queries.

• Checking for is_main_query() is useless; every query is considered the main query.
• One tiny improvement is to only call get_post_thumbnail_id when the post is a bigram.
• Investigating what the actual query is doing is prone to more complexity.

It happened with Fizzie and again with SB.
The logic run when Gutenberg finds a query-loop block is flawed and leads to a Fatal error for each query-loop block.

See bobbingwide/fizzie#70 (comment)

We need to update SB for Gutenberg 11.2.0.

The query-loop override implemented for the home page needs to be applied to work against the post-template block.

Issue #1 was the first issue for the SB theme, focussing on creating the home page ( index.html )
The Singular template also needs creating:

Requirements

• Same header, menu, sidebar and footer as the home page
• Main body to contain:
• Post title
• Featured image
• Post content
• Seen before
• Tags for category, S-word and B-word
• postmeta data
• post author
• And, if Jetpack is enabled, the share buttons for Pinterest, Twitter and Facebook - somewhere after the post content.

Proposed solution

• as above

The new taxonomies could either be created using oik-types or added by the bigram plugin.

Supplied by: is the name of the individual or AI that came up with the SB
Synthesised by: is the name of the AI image generator tool

When the fields have been added the additional text in the post content can be removed.
Note: Synthesised by should be associated with the attachment rather than the bigram post.

After a rather unsatisfactory export of the templates and template parts I manually created the html files but had a problem when I added the footer to index.html

<!-- wp:template-part {"slug":"footer","theme":"sb","tagName":"footer","layout":{"inherit":true}},"align":"full" } /-->

This results in the message.

Template part has been deleted or is unavailable:

There is nothing after the colon. I would have expected to see the slug or the post ID.
This is explained by the fact that the $attributes['slug'] is not set;
that there's a Warning message to that effect.

Warning: Undefined array key "slug" in C:\apache\htdocs\wordpress\wp-content\plugins\gutenberg-wordpress-source\build\block-library\blocks\template-part.php on line 7

The three hierarchical taxonomies that are displayed as tags need to be displayed using the post-terms block.
The block's settings doesn't allow the user to decide the taxonomy name; it has to be selected using the term attribute.

<!-- wp:post-terms {"term":"category"} /-->
<!-- wp:post-terms {"term":"s-word"} /-->
<!-- wp:post-terms {"term":"b-word"} /-->

The original CSS that styles the links as inline tags needs to be changed from .wp-block-post-hierarchical-terms to .wp-block-post-terms.

In Genesis-SB the SB page displays a react dialog.
This needs to be delivered as a block in a custom template page-sb.html

The latest versions of Gutenberg and WordPress look in templates and parts folders.
Not only do I need to rename the folders I also need to change the template-part override.

The CSS that styles the main menu is also being applied to the menus in the sidebar and footer.
There are a couple of problems with this

1. It doesn't match what we see on the live site
2. In the sidebar the longer menu items get scrunched up.

While attempting to check that oik.css wasn't inadvertently affecting the style changes noticed when using Gutenberg-source ( latest trunk) I deactivated oik. This prevented the custom taxonomies from being registered which produced a Fatal error trying to display the tag cloud.

Warning: Attempt to read property "labels" on bool in C:\apache\htdocs\bigram\wp-includes\taxonomy.php on line 582

Fatal error: Uncaught Error: Attempt to assign property "labels" on bool in C:\apache\htdocs\bigram\wp-includes\taxonomy.php:582
Stack trace:

#0 C:\apache\htdocs\wordpress\wp-content\plugins\gutenberg-wordpress-source\build\block-library\blocks\tag-cloud.php(24): get_taxonomy_labels(false) 
#1 C:\apache\htdocs\wordpress\wp-content\plugins\gutenberg-wordpress-source\lib\compat.php(136): gutenberg_render_block_core_tag_cloud(Array, '', Object(WP_Block)) 
#2 C:\apache\htdocs\bigram\wp-includes\class-wp-block.php(221): {closure}(Array, '', Object(WP_Block)) 
#3 C:\apache\htdocs\bigram\wp-includes\class-wp-block.php(211): WP_Block->render() 
#4 C:\apache\htdocs\bigram\wp-includes\class-wp-block.php(211): WP_Block->render() 
#5 C:\apache\htdocs\bigram\wp-includes\class-wp-block.php(211): WP_Block->render() 
#6 C:\apache\htdocs\bigram\wp-includes\blocks.php(799): WP_Block->render() 
#7 C:\apache\htdocs\bigram\wp-includes\blocks.php(837): render_block(Array) 
#8 C:\apache\htdocs\wordpress\wp-content\plugins\gutenberg-wordpress-source\build\block-library\blocks\template-part.php(100): do_blocks('<!-- wp:group {...') 
#9 C:\apache\htdocs\wordpress\wp-content\plugins\gutenberg-wordpress-source\lib\compat.php(136): gutenberg_render_block_core_template_part(Array, '', Object(WP_Block)) 
#10 C:\apache\htdocs\bigram\wp-includes\class-wp-block.php(221): {closure}(Array, '', Object(WP_Block)) 
#11 C:\apache\htdocs\bigram\wp-includes\blocks.php(799): WP_Block->render() 
#12 C:\apache\htdocs\bigram\wp-includes\blocks.php(837): render_block(Array) 
#13 C:\apache\htdocs\wordpress\wp-content\plugins\gutenberg-wordpress-source\lib\full-site-editing\template-loader.php(182): do_blocks('<!-- wp:templat...') 
#14 C:\apache\htdocs\wordpress\wp-content\plugins\gutenberg-wordpress-source\lib\template-canvas.php(12): gutenberg_get_the_template_html() 
#15 C:\apache\htdocs\bigram\wp-includes\template-loader.php(106): include('C:\\apache\\htdoc...') 
#16 C:\apache\htdocs\bigram\wp-blog-header.php(19): require_once('C:\\apache\\htdoc...') 
#17 C:\apache\htdocs\bigram\index.php(17): require('C:\\apache\\htdoc...') 
#18 {main} thrown in C:\apache\htdocs\bigram\wp-includes\taxonomy.php on line 582

The Site Editor can't handle Classic blocks. See #6 (comment)

• The [bw_list] shortcode could be converted to using the Query loop block, but that might stop the Ajax pagination from working.
• Alternatively use the shortcode block.
• The [bw_archive] shortcode could be converted to the Archive block. This would require an override to the Server Side Rendering to support the post_type argument - passing bigram. Default is post.
• Alternatively use the shortcode block.

The revised prompt is returned from some image generation routines. For SB's which are just entered as two words this can be quite informative. We need to display this using a style similar to is-style-aiprompt with the exception that the font is normal ( sans-serif ) not Serif.

Also, since these images are 1024x1024 we need more space to display them when shown on the home page.
So remove the two 50% columns to leave title, featured image, content.

Additionally, change the code that enqueues the styling for the paragraph such that it will work in the block editor. See tt4ai's code for that.

Requirements

• Replicate the functionality of the genesis-SB theme as used on https://seriously-bonkers.com

Approach

• Implement using Full Site Editing ( FSE )
• Attempt to create most of the theme using the Site Editor ( beta ).
• Attempt to style using the Site Editor ( beta ).
• Incorporate the react-SB page as a block
• Use modern CSS to style the grids
• Implement with a side bar
• Improve performance of both server and front end
• Dont worry too much about i18n
• Develop blocks which are missing as blocks in the theme or single block plugins.
• Allow server side rendering overrides a la Fizzie.

Proposed solution

• Clone live site and develop locally in s.b/bigram
• Start with an empty theme - just enough to be able to use FSE
• Develop a home page with template parts suitable for other pages
• Develop a 404 page early on ... for the #fse-outreach-experiment
• Develop a singular template with post-author, metadates, etc

It's far too easy to not realise that you're updating the wrong template part when editing a template in the site editor.
In this example I'd added the columns to contain the main content area and sidebar area into the Main menu template part.

What can be done to prevent this happening in the future?

I created the new empty theme for SB using new-empty-theme.php
It lower cased the theme name - from SB to sb.
When attempting to load the header template part it was not found since
the following test failed.

wp_get_theme()->get_stylesheet() === $attributes['theme']

Whose problem is it?

• Mine for naming my theme SB
• new-empty-theme.php's for lower casing my theme name
• Gutenberg's for performing case sensitive tests

The navigation menu items are hardcoded as s.b/bigram/etc. On the live site these need to be changed to seriouslybonkers.com/

Proposed solution

• copy the navigation-link.php overrides from Fizzie
• change fizzie_ to sb_
• change s.b/wp56 to s.b/bigram

In the Genesis-SB theme the pagination section's CSS is in style.css.
Here the active page is page 2 and I'm hovering over the Previous Page link.

Out of the box styling for the pagination blocks allows me to set the colours for the previous and next pagination blocks but not the numbers. Here I've got two previous blocks, the first has attributes for foreground and background colours.

<!-- wp:query-pagination-previous {"style":{"color":{"background":"#328dbd"}},"textColor":"background"} /-->

In Genesis-SB the Submit Bigram page ( submit-bigram ) uses [bw_login] and [bw_new popst_type="bigram"] to display a front end form to a logged in user to create a new bigram.

This needs fixing and reworking for SB

1. The form displays Undefined: I and a plan text entry field instead of File: with a "Choose File" button inside and input field of type="file"`.
2. The form should be wider; no featured image required.

This happened before when I used the block editor.
The most recent update I did was to the categories.
I reckon there's something wrong with the site editor but haven't analyzed it yet.

<ul class="sb thumbnail wp-block-post-template is-layout-grid wp-container-core-post-template-layout-35 wp-block-post-template-is-layout-grid"><li>
<figure class="wp-block-post-featured-image is-layout-grid wp-container-core-post-template-layout-3 wp-block-post-template-is-layout-grid">
<a href="https://seriouslybonkers.com/bigram/spoon-blade/" target="_self">
<img loading="lazy" width="1024" height="1024" src="https://seriouslybonkers.com/wp-content/uploads/2024/03/Spoon-Blade.png" class="attachment-post-thumbnail size-post-thumbnail wp-post-image" alt="Spoon Blade" style="object-fit:cover;" decoding="async" srcset="https://seriouslybonkers.com/wp-content/uploads/2024/03/Spoon-Blade.png 1024w, https://seriouslybonkers.com/wp-content/uploads/2024/03/Spoon-Blade-400x400.png 400w, https://seriouslybonkers.com/wp-content/uploads/2024/03/Spoon-Blade-150x150.png 150w, https://seriouslybonkers.com/wp-content/uploads/2024/03/Spoon-Blade-768x768.png 768w" sizes="(max-width: 1024px) 100vw, 1024px"></a>
</figure>
<h3 class="wp-block-post-title has-medium-font-size"><a href="https://seriouslybonkers.com/bigram/spoon-blade/" target="_self">Spoon Blade</a></h3>
</li>
...
</ul>

In the genesis-sb theme there are a number of specialised templates for displaying archives.
These use a common function called genesis_sb_page()
Is this logic necessary in FSE, or can we just get away with index.html?

Quick analysis indicates that we can get away with using index.html for the archive, category and date archives but need special logic for the search results.

Search results

The Search template displays different results depending on the actual search performed and the results obtained.
This is implemented by logic in a couple of filter functions genesis_sb_do_search_title and genesis_sb_search_banter()
The first displays the heading, the second the report on the search terms used

No results found

Search Results for: serve busts
Searching Beautifully...
Considering terms: serve busts
This doesn't qualify for automatic creation of an SB.

Results found

Search Results for: supplied by
Searching Beautifully...
Checking first post: Steve Biddle

Then the results are displayed as for index.html

Only an S word

Search Results for: supplied
How about a B word too?

Only a B word

Search Results for: by
How about searching for an S word as well?

Bad search

Search Results for: frogs legs
Try to search for an S-word a B-word or both
Sorry but, no posts surfaced before I gave up looking. Sobeit.

Possible solution

It could be possible to add a search-banter.html template part to index.html; inside body-and-sidebar.html