Template hierarchy test cases

[bobbingwide]

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.

Your homepage displays	Template hierarchy	True conditionals
Your latest posts	front-page, home, index	is_front_page, is_home
A static page; Home	front-page, page-*, singular, index	is_front_page, is_page, is_singular
A static page: Blog	home, index	is_home

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

URL	Template hierarchy	True conditionals
a post	single-post-*, single, singular, index	is_singular, is_single
a page	page-*, singular, index	is_page, is_simgular
a block	single-block-*, single, singular, index	is_single, is_singular
block (archive)	archive-*, index	is_archive, is_post_type_archive
category
tag
taxonomy	these to be completed some day!
date query
search
not found

[bobbingwide]

Repeating the tests in the above tables for Gutenberg 9.3.0 and 9.4.0 attempting to get each template clearly identifying itself with template-name.html above the header.

URL	Template	9.3.0	9.4.0
A static page: Home	front-page.html	correct	OK. but front-page.html not shown
A static page: Blog	home.html	correct	wrong. index.html not home.html
Your latest posts	front-page.html	correct	wrong. home.html not shown

Notes:

• Issue Losing Your homepage displays settings on updating Settings > General #40 workaround applied.
• s.b/wp56 used for 9.3.0 ( WordPress 5.6-beta4 )
• blocks.wp-a2z for 9.4.0 ( WordPress 5.5.1 )
• It wasn't an easy task to find out which template was being used.
• I couldn't do it using the front end.

[bobbingwide]

I've been looking at the logic for template and template part synchronization.

1. It seems to be pretty inefficient. It has to check the file time of each template and template part in the theme on every single load.
2. It's not loading up my changes.
3. I don't yet know why not.

I thought the problem was in _gutenberg_create_auto_draft_for_template().
But it looks OK. If it finds the most recent post is an auto-draft and the new post content is different it updates it.
If it's published it doesn't.

[bobbingwide]

It seems to be pretty inefficient. It has to check the file time of each template and template part in the theme on every single load.

In a development environment where the .html files are being changed one might expect the logic to not bother at all with the database. In production it certainly shouldn't be doing this on the front end.
After theme update perhaps, or whenever a wp_template or wp_template_part is changed.

This is child / user theme territory that may have been thought out but not clearly documented.

I now believe the reason I'm not seeing changes to some of the files is because I have published wp_template files.
I'll trash them again.

This is the use case for not updating published templates / template parts.

Say the user creates their own template part called Christmas one year. The next year the theme developer decides to deliver a new template part, also called Christmas. Shouldn't the user be told that the template part is going to be overridden by the new one in the theme?

[bobbingwide]

It looks likes the problem is with the following query from gutenberg-resolve-template.

// Find all potential templates 'wp_template' post matching the hierarchy.
	$template_query = new WP_Query(
		array(
			'post_type'      => 'wp_template',
			'post_status'    => array( 'publish', 'auto-draft' ),
			'post_name__in'  => $slugs,
			'orderby'        => 'post_name__in',
			'posts_per_page' => -1,
			'no_found_rows'  => true,
			'meta_key'       => 'theme',
			'meta_value'     => wp_get_theme()->get_stylesheet(),
		)
	);

In my environment it returns two posts for 'front-page'.
The first one is the older post which doesn't have the latest updates.
The orderby doesn't get the newest.

Workaround

Delete posts with post_status auto-draft and try again.

See also Gutenberg PR 27016 where the queries have been changed to use a theme taxonomy called wp_theme.

[bobbingwide]

Hooray. I also had to delete the two entries from the wp_options table which hold the last updated date.
Now to see if, when I make changes to the templates or template parts, they are updated on the front end.

[bobbingwide]

Repeating the tests once the templates have been reloaded as 'auto-draft' posts.

URL	Template	9.3.0	9.4.0
A static page: Home	front-page.html	correct	correct
A static page: Blog	home.html	correct	wrong - index.html
Your latest posts	front-page.html	correct	correct
block archive	archive-block.html	correct	wrong - archive.html
single oik plugin	single-oik-plugins.html	correct	wrong - single.html

So now we have to look at the logic that loads the template hierarchy.

[bobbingwide]

I raised an issue against Gutenberg. WordPress/gutenberg#27177

[bobbingwide]

I'm going to close this issue now. Things have moved on. Current version of Gutenberg is 15.3.1, WordPress 6.2-RC1