[wp-trac] [WordPress Trac] #58333: WordPress 6.2.1 Shortcodes some shortcode no longer works!

Thu May 18 12:25:39 UTC 2023

#58333: WordPress 6.2.1 Shortcodes some shortcode no longer works!
--------------------------+-----------------------
 Reporter:  jorcus        |       Owner:  (none)
     Type:  defect (bug)  |      Status:  reopened
 Priority:  normal        |   Milestone:  6.2.2
Component:  Shortcodes    |     Version:  6.2.1
 Severity:  normal        |  Resolution:
 Keywords:                |     Focuses:
--------------------------+-----------------------

Comment (by asafm7):

 Thanks, @miyarakira .

 Regarding:

   I like the idea of a solution that applies wptexturize, do_shortcode and
 similar filters to specific blocks that need them (paragraph block,
 classic block, shortcode block, heading block, etc) rather than applying
 them across all blocks.

 This list of blocks is incomplete and can never be made complete, as there
 are many blocks made by plugins and also custom blocks, and people are
 using these blocks in many ways that can't be predicted. I, for example,
 use inline shortcodes inside Yoast blocks.

 There should be at least a filter for determining whether a specific block
 should do_shortcode() or not.

 Also, I wonder if the issue can't be fixed by applying do_shortcode()
 earlier, for example inside get_block_templates() or get_block_template()

 Replying to [comment:59 miyarakira]:
 > @la-geek  Oh I see, I thought by "risk" you meant the risk of classic
 themes being affected by this breaking change.
 >
 > > if rendered shortcodes in classic themes are still secure?
 >
 > The security vulnerability addressed by this change was only in block
 themes, due to the way it applied content filters including `do_shortcode`
 on the *entire page* after all blocks have been rendered. It meant that,
 for example, shortcodes within a user-submitted comment would run even if
 the user was a visitor (not logged in). Classic themes, on the other hand,
 only apply `do_shortcode` to the post content which only certain user
 roles can edit.
 >
 > ---
 >
 > > why a shortcode rendered in a Template PART is more secure than a
 Template
 >
 > @audrasjb This might be an oversight since a template part can include
 anything that a template can. The same set of content filters is applied
 to every template part:
 >
 >
 https://github.com/WordPress/gutenberg/blob/a0a1fd51e542b5c97f166f7be1679c2858dbb96e/packages
 /block-library/src/template-part/index.php#L145-L153
 >
 > Notably, it runs `do_blocks` then `do_shortcode` on the result. If I
 understand correctly, that means if any block renders content submitted by
 non-privileged users, shortcodes within that content will be run.
 >
 > ---
 >
 > That's why I was wondering about the `core/post-content` block.
 >
 > Before WP 6.2.1, the function `get_the_block_template_html` (which block
 themes use to render the whole page) ran `do_blocks`, which renders all
 blocks on the page including the Post Content block, then applied
 `do_shortcode` to the entire result HTML. This latter step was removed as
 security fix in 6.2.1, but the Post Content block itself applies
 `the_content` filter, which runs `do_blocks` then `do_shortcode`.
 >
 > As a further twist, a Post Content block can contain other Post Content
 blocks, according to this comment in the pull request titled,
 [https://github.com/WordPress/wordpress-
 develop/pull/3549#issuecomment-1426532982 Avoid double-processing post
 content when parsing block template HTML].
 >
 > ---
 >
 > This "double processing" means that the same set of content filters is
 being applied more than once to the same content. It's the cause of a
 number of related issues, including running shortcodes on the result of
 rendering blocks ''and'' running shortcodes (which I believe is related to
 the security vulnerability).
 >
 > - [https://github.com/WordPress/gutenberg/issues/37754
 no_texturize_shortcodes WP filter broken with block themes]
 > - [https://github.com/WordPress/gutenberg/issues/33813 Single quotes are
 rewritten as quotes in HTML block and Shortcode blocks]
 > - [https://github.com/WordPress/gutenberg/issues/49357 Shortcode
 escaping with double square brackets does not work anymore in FSE themes]
 >
 > (This last one might have been solved in 6.2.1, since `do_shortcode` is
 no longer being run twice on the same content.)
 >
 > To summarize, in a block theme, there are currently several places where
 a very similar stack of content filters is being applied:
 >
 > - Default filters: `the_content`, `widget_text_content`, and
 `widget_block_content` ([https://github.com/WordPress/wordpress-
 develop/blob/trunk/src/wp-includes/default-filters.php here]) - all of
 which applies `do_blocks` and `do_shortcode`
 > - Entire page: `get_the_block_template_html`
 ([https://github.com/WordPress/wordpress-
 develop/blob/d5792c7a8861330d53adc05dacfdfdccb822b1d4/src/wp-includes
 /block-template.php#L237-L243 here]), which applies `do_blocks` ~~and
 `do_shortcode`~~
 > - Template part: `render_block_core_template_part`
 ([https://github.com/WordPress/gutenberg/blob/a0a1fd51e542b5c97f166f7be1679c2858dbb96e/packages
 /block-library/src/template-part/index.php#L145-L153 here]), which applies
 `do_blocks` and `do_shortcode`
 > - Post Content block: `render_block_core_post_content`
 ([https://github.com/WordPress/gutenberg/blob/a0a1fd51e542b5c97f166f7be1679c2858dbb96e/packages
 /block-library/src/template-part/index.php#L145-L153 here]), which applies
 `the_content` filter ''and'' can contain nested Post Content blocks
 >
 > Hopefully some of this is useful in getting to the bottom of the issue.
 >
 > I'm invested in finding a proper solution to the above issues, as I've
 struggled with them for a while. I wrote in
 [https://github.com/WordPress/gutenberg/issues/37754#issuecomment-1433931297
 a comment on one of the issues]:
 >
 > > The way it currently works, there's no way for block authors to opt-
 out of these filters; the most they can do is to work around or reverse
 their effects. A better design would be to ''not'' process the resulting
 HTML of a block by default, except for certain blocks where `the_content`
 filter makes sense. As @carlomanf said:
 > >
 > >> I like the idea of a solution that applies `wptexturize`,
 `do_shortcode` and similar filters to specific blocks that need them
 (paragraph block, classic block, shortcode block, heading block, etc)
 rather than applying them across all blocks.
 >

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/58333#comment:61>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform