ACF 5.8.0-beta3 wpautop issues

[mitchkramez]

This is a good description of what I'm running into, including a fix: https://wordpress.stackexchange.com/questions/321662/how-do-i-disable-wpautop-for-a-specific-block

I'm wondering what exactly is going on in this situation, as, if I include my custom block that includes a call to get_the_excerpt, it seems to apply wpautop to the entire page, every single block. if I remove the get_the_excerpt this doesn't happen and all is well.

This seems like there's probably something going on that would need to be looked at. I can share some specifics on my case if it's helpful, but would rather not post them publicly here if possible...

[elliotcondon]

@mitchkramez

Thanks for the bug report. I'm not sure that I fully understand the issue yet. Would you mind providing some screenshots + instructions to help explain and replicate the problem?

[mitchkramez]

@elliotcondon, basically what's happening is this: https://ep.d.pr/hVGafj
tags are being inserted everywhere on this page when include a call to get_the_excerpt in this particular block. It's as if gutenberg is taking all of my block templates, and adding br tags every time there's a line break.

Adding this to my functions.php file fixes the issue:

add_filter('render_block', function ($block_content, $block) {
    if ('acf/ep-resources-block' === $block['blockName']) {
        remove_filter('the_content', 'wpautop');
        remove_filter('the_excerpt', 'wpautop');
    }

    return $block_content;
}, 10, 2);

At first I suspected some wonky HTML was causing issues, but remove ALL html from that block template still results in the br tags being placed all over the page if I include get_the_excerpt in that block. If i remove the get_the_excerpt call, everything is fine. It's pretty strange. Let me know if you'd like more detail!

[elliotcondon]

Hi @mitchkramez

I've just spent some time trying to replicate the issue but haven't had much luck. Are you able to put together a very basic environment to test the issue and then share that code with me to replicate on my end?

[mathewjordan]

Hey @elliotcondon

I came across this same issue and put together a code example for you. Please see mathewjordan/dummy_acf_register_block to review. My dummy example is very basic but hopefully it demonstrates the issue. This also might not even be anything under your purview and more to do with core.

A more real world example would be something like rendering a directory listing when a user is selected from a field.

The problem may very will be in the implementation how we are choosing to build the templates to render. Any feedback would be greatly appreciated.

[mathewjordan]

I should also note that I am now using 5.8.0-RC2.

[elliotcondon]

Hi @mathewjordan

Thanks for setting up a plugin to test with. I've just installed this, created a field group to match and believe I have replicated the issue.

Can you please confirm the field type for "Dummy Body"?

I made the assumption that this is a WYSIWYG field, which if true, explains the extra <p> tags. When outputting the value of a WYSIWYG field, the <p> tags are automatically added via the wpautop() function - much like how the the_content() function behaves.

If you would like to avoid the value containing <p> tags, please change your field type to a textarea, or consider removing the <p> tags with something like this: https://wordpress.stackexchange.com/questions/5650/is-there-un-wp-autop-function

[mathewjordan]

Hey @elliotcondon.

Thanks for getting back to me and I apologize now. The <p> was a poor choice for my example as it wasn't the only issue. I was still having the issue even while using basic text fields.

I'm working with a legacy site here and have realized it's another plugin that is conflicting and causing my templating issues. Raw HTML Pro https://wordpress.org/plugins/raw-html/ has some functions that inadvertently go in and modify the template structure of Gutenberg blocks before rendering.

I found a workaround for this by either outputting things using some ugly echos OR also simply switching to an unordered list which will probably be my method in the near-term.

<?php

echo '<div class="dummy-block">';
    echo '<div class="dummy-header">';
        echo '<h2>' . get_field('dummy_title') . '</h2>';
    echo '</div>';
    echo get_field('dummy_body');
    echo '<div class="dummy-meta">';
        echo '<span>' . get_field('dummy_meta_1') . '</span>';
        echo '<span>' . get_field('dummy_meta_2') . '</span>';
        echo '<span>' . get_field('dummy_meta_3') . '</span>';
    echo '</div>';
echo '</div>';

?>

<div class="dummy-block">
    <div class="dummy-header">
        <h2><?php the_field('dummy_title'); ?></h2>
    </div>
    <?php the_field('dummy_body'); ?>
    <ul class="dummy-meta">
        <li><?php the_field('dummy_meta_1'); ?></li>
        <li><?php the_field('dummy_meta_2'); ?></li>
        <li><?php the_field('dummy_meta_3'); ?></li>
    </ul>
</div>

Unfortunately this conflict leaves me in limbo as a lot of my ancient posts still depend on the old way of doing things, but the future is bright now that I can begin enforcing structure with these custom blocks. Loyal to the cause. Thanks again!

[elliotcondon]

Hi @mathewjordan

Thanks for the reply. Glad you were able to diagnose the issue :)