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

[WordPress Trac]

#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 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 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:59>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform