TT2: Blank screen displayed for custom post type

[jffng]

Originally reported in TT2's development repository by @davidfcarr: ​https://github.com/WordPress/twentytwentytwo/issues/345

I'm trying to debug the interaction between this theme and the rsvpmaker custom post type from an events management plugin of mine. When trying to view this content, a blank screen is displayed but no error is logged.

Guessing it might have something to do with changes to the template hierarchy.

Normally, posts of this post type would be displayed in single.php unless a single-rsvpmaker.php has been defined. So I would expect it to display in the single.html template of Twenty Twenty Two.

What else should I check? Have other plugin developers reported similar issues?

[hellofromTonya]

Test Report: a basic custom post type registered, no special archive page defined, + using TT2; Single post rendered > Couldn't reproduce blank page

[hellofromTonya]

Test Report

Env / Setup:

• Theme: TT2
• Plugins: a basic CPT plugin (​code is in this gist)
• WordPress: 5.9-RC4
• OS: macOS Big Sur
• Localhost: wp-env
• Browser: Firefox

Note: The testing plugin only registers the custom post type. This means posts in that post type will use single from TT2.

Setup Steps:

1. Add the ​testing plugin file to wp-content/testcpt/.
2. Activate the testing plugin.
3. Activate TT2.
4. Trigger the permalinks by going to Settings > Permalinks > and then clicking the "Save changes" button.
5. Go to TestCPT > Add new.
6. Create a new post.

Cool. Ready to test.

Steps to test

1. View the TestCPT post in the front-end.

Expected behavior: the post renders the content as it does any other post.

Results

See it in action in the testing gif: 54896-with-basic-cpt.gif​.

The custom post type post rendered as expected.

Unable to reproduce.

[hellofromTonya]

5.9 is in the 24 hour code freeze.

As the reported issue has not yet been reproducible and not seeing additional reports of this issue, I think this issue is not a blocker for today's 5.9 final release.

Moving this to 5.9.1 for visibility and continued investigation.

Also noting, my test report above intended to validate that a custom post type does use TT2's single which then does render in the front-end. Additional testing using a single-testcpt or equivalent would be helpful to validate the hierarchy.

[ugyensupport]

I would like to say that it could be something related to any custom post types plugin on it's incompatibility with Twenty Twenty two theme.
I tried on my end and can't reproduce it.

[davidfcarr]

The problem well may be with my code. My frustration is there seems no way to debug it. Fails with a white screen of death. Even with all debugging options turned on, no error is displayed or logged. May suggest an out of memory condition. Does the process of displaying a page take a lot more memory with a block theme? I've tried eliminating filters and functions tied to the post type but have not been able to narrow down where the issue is coming from. Wondered if you're seeing this with other custom post types.

[davidfcarr]

I tried a couple of other full site editing themes, Gutena and Jace, and encountered the same problem. It seems to be an issue with display of the custom post type within the new theme framework, not just with Twenty Twenty Two.

[davidfcarr]

Issue does not occur on 5.9 if a traditional theme is active.

[davidfcarr]

For the sake of anyone who may encounter a similar issue, I traced this to a filter on 'single_template'

One of the documented ways of using that function is to alter the order in which php templates in a theme will be evaluated for use. Apparently, this will have to be altered somehow to support .html templates from a block-based theme. I haven't seen this documented anywhere yet.

For now, I'm disabling this functionality by checking for the existence of the 5.9 function locate_block_template

<?php
add_filter( 'single_template', 'rsvpmaker_template_order', 99 );

function rsvpmaker_template_order( $templates = '' ) {
        if(function_exists('locate_block_template'))
                return $templates;
//rest of code

[davidfcarr]

Turned out the better solution was to filter on single_template_hierarchy as documented here ​https://developer.wordpress.org/reference/hooks/type_template_hierarchy/

Is called earlier in the process and doesn't disrupt block theme operation