Open bobbingwide opened 4 years ago
I've reduced the problem to the simplest I can.
style.css
to ensure that paragraphs are visible even when empty.
p { background-color: white; border: 1px solid grey; padding: 5px;}
404.html
template containing
<!-- wp:template-part {"slug":"issue-26731","theme":"twentytwentyone-blocks"} /-->
issue-26731.html
template part containing a (hand crafted) group block.
Notice the blank between the two </div>
s<!-- wp:group -->
<div class="wp-block-group">
<div class="wp-block-group__inner-container">
</div> </div>
<!-- /wp:group -->
</p>
generated by wpautop().<div class="wp-site-blocks"><div class="wp-block-template-part"><div class="wp-block-group">
<div class="wp-block-group__inner-container">
</div>
</p></div>
</div>
</div>
Remove the blank between the two </div>
tags.
Gutenberg's already tried to fix this problem. There's a comment in do_blocks()
associated with code that removes wpautop()
from the_content
filtering.
// If there are blocks in this content, we shouldn't run wpautop() on it later.
Solution: don't call wpautop()
.
I've found another instance where wpautop()
is causing problems. It affects the inline CSS generated for FSE themes using the new alignment techniques.
<style> .wp-container-606f3a09dc6ea > * {
max-width: 80%;
margin-left: auto;
margin-right: auto;
}</p>
<p> .wp-container-606f3a09dc6ea > .alignwide {
max-width: 90%;
}</p>
<p> .wp-container-606f3a09dc6ea .alignfull {
max-width: none;
}
.wp-container-606f3a09dc6ea .alignleft {
float: left;
margin-right: 2em;
}</p>
<p> .wp-container-606f3a09dc6ea .alignright {
float: right;
margin-left: 2em;
}
</style>
Following up here that this is still occurring in different areas - been trying to isolate different occurrences.
Describe the bug While attempting to develop a fix for another problem in
gutenberg_render_block_core_template_part()
I encountered situations wherewpautop()
has inadvertently added end paragraph tags into the generated HTML. These were causing unwanted blank areas in the browser.The problem is caused by
wpautop()
, which is not needed. Removing the call towpautop()
fixes the issue.To reproduce Steps to reproduce the behavior:
</p>
tags in the page.Expected behavior No unwanted
</p>
tags in the generated HTMLScreenshots hex dump of the end of $content before wpautop()
hex dump of the end of $content after wpautop().
See the problem in https://github.com/bobbingwide/fizzie/issues/20
Editor version (please complete the following information):
Desktop (please complete the following information):
Additional context