bobbingwide / sb-debug-block

SB Debug block - debug block for a Full Site Editing theme
Apache License 2.0
2 stars 0 forks source link

Implement oik-sb/sb-debug-block for debugging FSE templates and template parts #2

Open bobbingwide opened 3 years ago

bobbingwide commented 3 years ago

Background

In Fizzie, SB and ThisIs... I've used some custom HTML to add debug information to each template, and some template parts. It appears at the top of each template enabling me to know which template I'm viewing. eg In 404.html

<!-- wp:html -->
<div class="WP_DEBUG">404.html</div>
<!-- /wp:html -->

If I change the text in the .html file I can tell whether or not the template has been loaded from the file or the database. It doesn't let me know which language version is being used though.

Similarly, it's nice to know where a template part starts, and possibly where it ends. eg in the 404.html template part

<!-- wp:html -->
<div class="WP_DEBUG">404 template-part</div>
<!-- /wp:html -->

The first <div> with class WP_DEBUG is styled with CSS in the theme's style.css stylesheet to appear in the wp-admin top bar. Others have a dotted red border and appear when hovered over.

In order to turn off debugging it's necessary to either remove the custom HTML or change the CSS.

Finally, the output-input.html template uses a template part called contents-shortcode.html which uses the [contents] shortcode to display the raw HTML of the post content - escaped to make it visible in the browser. This can be used to check that what we see in the front end was produced from the blocks in the post's content

Requirements

Proposed solution

bobbingwide commented 3 years ago

Automatically determines the template name / template part name and where it was sourced.

This is only possible with changes to Gutenberg. Accessing the template information is easier than accessing template part information.

bobbingwide commented 3 years ago

Accessing the template information is easier than accessing template part information.

Actually, now that I've written it, accessing the template part information was easier. I was able to extend the logic in my template part override function to call an action hook rendering_template_part both before and after the rendering.

The call before passes the $attributes and the $seen_ids array. The call after passes a null parameter for the attributes and the updated $seen_ids array. This allows the debug block to be used after a template-part block. It should show the current level of template part nesting.

Now to attempt to rework the mechanism to indicate which template is being rendered by adding a do_action( 'rendering_template' ) hook to replace the global I used in the first instance.