There are a number of techniques to debug templates, template parts and post content.
- Add some debugging output.
- Add some debugging styling.
- Use a custom template that mixes the two.
Add some debugging output
In this theme the templates have a custom HTML block at the top indicating the template name and sometimes a timestamp. I use this to check that the template that’s being displayed is the one I expect it to be.
<!-- wp:html -->
<div class="WP_DEBUG">my-template-name.html timestamp</div>
<!-- /wp:html -->
Add some debugging styling
The style.css file contains CSS to style the .WP_DEBUG class so that it’s not too in your face.
I also use custom CSS, either added to the content using the CSS block or edited on the fly in the inspector
Custom template output-input
- This page has the custom template callout
output-input - It looks quite different from a normal page.
- There’s no header or footer
- Just the content
- Followed by the source of the content, which is prefixed by the Blocks heading
- And there’s custom CSS to highlight paragraphs and any unwanted <br /> tags
Proposal for a Debug block
I have started to develop a Single Block plugin debug block bobbingwide/sb-debug-block. For this to work I need to develop some additional debugging capability built into Gutenberg / WordPress core.
The code needs to be able to determine the current template and current template part.
A simple hack is to add this into gutenberg_override_query_template() saving the current template returned by gutenberg_resolve_template() into a global $_wp_current_template. This can then be referenced in the debug block.
function gutenberg_override_query_template( $template, $type, array $templates = array() ) {
global $_wp_current_template_content;
global $_wp_current_template;
$current_template = gutenberg_resolve_template( $type, $templates );
// Set the current template's details.
$_wp_current_template = $current_template;