Remove do_shortcode and wpautop for block template parts (still need to remove shortcode block)

[johnstonphilip]

Relates to issue #20342

Description

This PR removes the wpautop and do_shortcode wrappers for block template parts as suggested by @azaozz in #20343.

How has this been tested?

1. Create a block-based theme, with the header.html and footer.html in the block-template-parts directory, and the index.html file pulling those in.
2. Attempt to add a shortcode block to the header block-template-part. Notice that you still can (though ultimately this needs to be removed).
3. Save the header and view your site.
4. Notice the shortcode does not get converted.

Screenshots

Types of changes

Bug fix.

Still to-do: Un-list the shortcode block if editing a block-template or block-template part.

Un-listing a block in a context does not seem to be possible yet, as blocks are registered without an attached context. For example, I did not see a way to only register the shortcode block if editing the_content.

The only way I could see to remove the shortcode block was by removing it here:

gutenberg/packages/block-library/src/index.js

Line 117 in cd851b2

shortcode,

But that removes it entirely, for all contexts, not just for the block-template-part editor.

Additionally, since the block-template-part editor is eventually going to be rolled into Full-Site Editing, and editing a block-template-part and the_content will be possible in that same view (where shortcodes are still allowed) there would have to be a way to disable the shortcode block, but only if editing in a block-template-part area, and otherwise, leave it registered, even if both contexts are being loaded in a single page.

Checklist:

• My code is tested.
• My code follows the WordPress code style.
• My code follows the accessibility standards.
• My code has proper inline documentation.
• I've included developer documentation if appropriate.
• I've updated all React Native files affected by any refactorings/renamings in this PR.

[youknowriad]

closing this in favor of #30552 which is more ready to land.

Sorry, I closed the wrong PR :)

[bobbingwide]

I'm still using shortcodes in template parts for times when blocks are not yet available.
For example see: https://github.com/bobbingwide/fizzie/blob/main/block-template-parts/a2z-pagination-block.html

[azaozz]

Thinking it's time to revisit this. See #20343 (comment) and the following comments. Autop was removed, but do_shortcode() still runs "globally" (on the whole HTML output).

Similarly to autop, there is no good reason to globally support shortcodes in template parts. Shortcodes are old, slow, buggy, limited technology. The shortcode block can be used for now, perhaps to make it a bit easier for some themes and plugins. However thinking best would be to not have it there by default but leave plugins to add/enable it. Reason is that once it is added (by default), there's no getting rid of it, ever.

[bobbingwide]

there is no good reason to globally support shortcodes in template parts.

I have more examples where I need to use shortcodes because they exist but the equivalent block doesn't.

<p>Published: [bw_field post_date] | Last updated: [bw_field post_modified] [post-edit]</p>

The shortcode block can be used for now,

I also have examples where the shortcode block is not suitable because it adds unwanted paragraphs before and after the shortcode's output. As a workaround I switched to use the custom HTML block

See bobbingwide/fizzie#65

Until Gutenberg supports the block equivalent of inline shortcodes then I will continue to need to use these solutions.
If that requires me to override the template-part processing then so be it.

There is already a published FSE theme that uses shortcodes. See product-content.html in
https://blocks.wp-a2z.org/oik-themes/hansen/?oik-tab=template_parts

[azaozz]

@bobbingwide I see... To put this in a "JavaScript perspective", using shortcodes in FSE in 2021 is roughly the equivalent of building a React app (latest well established technology) and then adding Prototype.js and Scriptaculous.js (2008 technology) for the "things that may not be available yet". I believe this would be a pretty poor decision.

If you really must use shortcodes outside of post_content and few widgets, I've got few questions:

1. Looking at the first example, how hard would it be to make a block that would insert all of the required HTML instead of having to type the whole thing every time? If you've considered that, and it is hard-to-do/unacceptable, thinking that it would be far more beneficial to add an easy, straightforward way for adding such blocks instead of falling back to using ancient technology.

2. I'm thinking that even the shortcode block should not be added to FSE by default. If plugins want to use shortcodes (and hopefully explain all the shortcomings of that decision to their users), they can add the shortcode block themselves.

the shortcode block is not suitable because it adds unwanted paragraphs before and after

Right, the shortcode block has some limitations. These may eventually be fixed in Gutenberg although don't think this is a priority. A plugin can also fix this particular limitation pretty easily (I think).

Until Gutenberg supports the block equivalent of inline shortcodes

Don't think that's a good idea, old tech vs. new tech, etc. But it's probably worth a ticket (if one doesn't exist already). Also see above, plugins can hook into block parsing and do... pretty much anything they want with all blocks.

TL;DR: Currently (without FSE) shortcodes are not supported in "template tags", only in post_content and some widgets. Adding a "global" shortcodes support in FSE sounds like a poor architectural decision.

[youknowriad]

The related issue is closed so I'm wondering if this is still relevant anymore? Should we close the PR?