WordPress 6.2.1 Shortcodes some shortcode no longer works!

[jorcus]

I'm using bbPress on my site. After updates, the shortcodes no longer works. Eg. "[bbp-topic-index]"

[costdev]

Hi @jorcus, welcome to Trac and thanks for opening this ticket.

Is your site using a block theme?

---

• Moving to 6.2.2 for visibility.

[costdev]

From a Slack discussion:

@jorcus I'm using [bbp-topic-index] on my homepage. Of course, it's a custom block theme. I think i understand the issue now after seeing the github update audrasjb mentioned. i will try to use "Page"

Closing this ticket as wontfix as it appears this is expected behaviour.

[samiamnot]

Support was removed in what seems to be a security patch in https://core.trac.wordpress.org/changeset/55766

[jorcus]

Yes, I'm using a custom block theme. My homepage is currently using the site editor. After updates to 6.2.1, my homepage is displaying the "[bbp-topic-index]" in text. Now, I already rollback to 6.2

[Ipstenu]

FYI this may be a bigger headache - ​https://wordpress.org/support/topic/wordpress-v6-2-1-breaks-the-shortcode-block-in-templates/ indicates people are using them in templates.

[andergmartins]

For those who want to stay on 6.2.1 and need to restore the support for shortcodes on templates, you can try this workaround.

Add the following code as a plugin in a PHP file in the plugins folder:

<?php
/*
Plugin Name: Fix shortcode
Plugin URI:
Description: Restore shortcode support on block templates
Author: Anderson Martins
Version: 0.1.0
*/

add_filter('render_block_data', function($parsed_block) {
    if (isset($parsed_block['innerContent'])) {
        foreach ($parsed_block['innerContent'] as &$innerContent) {
            if (empty($innerContent)) {
                continue;
            }

            $innerContent = do_shortcode($innerContent);
        }
    }

    if (isset($parsed_block['innerBlocks'])) {
        foreach ($parsed_block['innerBlocks'] as $key => &$innerBlock) {
            if (! empty($innerBlock['innerContent'])) {
                foreach ($innerBlock['innerContent'] as &$innerContent) {
                    if (empty($innerContent)) {
                        continue;
                    }

                    $innerContent = do_shortcode($innerContent);
                }
            }
        }
    }

    return $parsed_block;
}, 10, 1);

But be aware that support was removed for fixing a security issue, and restoring shortcode support you are probably bringing back the security issue.

[asjl]

I've got the same problem on over 600 pages which use five or six different templates with shortcodes in each template on one site and similar things on several others.

I'm looking forward to editing each of those pages to get the shortcode back in place. Or backtracking to 6.2 and turning off updates.

It reminds me of this:

"There’s no point in acting surprised about it. All the planning charts and demolition orders have been on display at your local planning department in Alpha Centauri for 50 of your Earth years, so you’ve had plenty of time to lodge any formal complaint and it’s far too late to start making a fuss about it now. … What do you mean you’ve never been to Alpha Centauri? Oh, for heaven’s sake, mankind, it’s only four light years away, you know. I’m sorry, but if you can’t be bothered to take an interest in local affairs, that’s your own lookout. Energize the demolition beams."

Douglas Adams, The Hitchhiker's Guide to the Galaxy

[timbearcub]

This kills the Smart Slider 3 plugin - using their block, as obviously they must use the shortcode in some way; as does XYZ PHP Snippets...sadly no-one has created a Search block with category function, AFAIK so I was extending the search with that, and now just get [shortcode]. Learning node.js just to extend a block is a bit of a high ask, you know?

You can't just take out functionality like that? Or at least make it clear you're taking out shortcodes and don't allow the Shortcode to be used in FSE.

Also - the previews all work, so get ready for a load of people getting confused that something shows in the FSE editor but doesn't work on the main site. I assumed it was a plugin thing, or something else.

I certainly didn't expect that Automattic had returned to their old ways of no communication and just breaking things on the fly. I expected that on WP 1.2 - yes I got back that far - the install where every install got hacked, or 1.5....not a supposedly mature platform at v6.2.1.

At very least tell your users what is going on, or put a message in the editor, or something?

[audrasjb]

Replying to timbearcub:

I certainly didn't expect that Automattic had returned to their old ways of no communication and just breaking things on the fly. I expected that on WP 1.2 - yes I got back that far - the install where every install got hacked, or 1.5....not a supposedly mature platform at v6.2.1.

Hello and thanks for sharing your feelings,
Just wanted to let you know that nobody on this ticket is employed by Automattic, and nobody from Automattic led the WP 6.2.1 release.
Let's keep focused on the actual issue :)

---

Shortcodes support on block templates was removed to fix a security issue and to avoid getting a zero-day vulnerability on WordPress websites.
The workaround shared by @andergmartins on comment:7 should work. But please note that it's also reintroducing the actual security issue.

This is also being discussed by the security team, and parallel discussion on Trac are very welcome.

[petitphp]

#58339 was marked as a duplicate.

[petitphp]

Just noticing, currently even if the block will not be render on the frontend, it is still possible to insert a shortcode block when editing a block template.
We could hide it in the inserter when editing a block template to limit its use. This should also disable patterns which use this block internally.

[petitphp]

#58341 was marked as a duplicate.

[ciantic]

Where are the details of the security issue? If only admins can edit the templates, is there still a security issue? I use shortcodes to add PHP functionality, which is not as easy to add without shortcodes now that templates are HTML files, and all my themes have those shortcodes sprinkled.

[sudeep007]

Hello guys I am directed to this group by Oliver Campion. I have opened a ticket in twenty-22 theme ​https://wordpress.org/support/topic/short-cope-stopped-working-on-theme-pages/ After the yesterday's code updates, shortcodes inserted in custom theme areas are stopped working. But these short codes are working fine with in post and page area, but not in theme block areas. Please resolve this issue.

[domainsupport]

Sorry for the delay in commenting here.

This update has been nothing short of a disaster. I cannot understand how there was no warning of such a destructive, automatic roll out!

We have managed to rollback affected sites to v6.2 and block automatic core updates until there is a suitable solution. Which we hope is imminent due to the reported security issues!

Shortcode Blocks, in our opinion, are absolutely essential to the design process when using Block Themes.

We use them to inject classic menus that can have dynamic menu items (such as sign out), dynamic header content, specialised loops and footer content that’s as simple as showing the current year in the copyright statement to showing a contact form or other such dynamic content. And that’s just what I can think of from the top of my head.

I realise that a security issue needed to be resolved but there must be some kind of compromise so we can re-enable such a core feature of WordPress without the security risk.

I would appreciate it if someone could urgently point me towards the documentation of the security risk so I might offer a solution that allows the Shortcode block to remain operational.

Thank you,

Oliver

[asafm7]

This is really bad... There must be a better way of fixing the security issue rather than killing an important functionality.

What is the best channel to raise the issue?

[Drivingralle]

This change is very concerning for advanced use cases in agencies and custom developments that prefer to deploy content via code.
We are using the shortcode block inside templates to deploy features to many sites inside a multisite.

As long as there is no "inline Block" to display small pieces of information within text the shortcode is an important feature.

[SergeyBiryukov]

Replying to asafm7:

What is the best channel to raise the issue?

Thanks everyone for sharing the concerns, the issue raised here is already prioritized and is being discussed with both the Editor and the Security teams.

[martatorre]

Thank you very much to all the team. Yes, for some developers this is something we are concerned about, so we look forward to hearing from you.

[asafm7]

Replying to SergeyBiryukov:

Replying to asafm7:

What is the best channel to raise the issue?

Thanks everyone for sharing the concerns, the issue raised here is already prioritized and is being discussed with both the Editor and the Security teams.

Thank you @SergeyBiryukov .

[mukesh27]

#58343 was marked as a duplicate.

[uxl]

There is a workaround if you need to place a shortcode in a template:

Using the block inserter, add a "Template Part" block, give your new custom template part a name for your own reference if you wish, and then add the shortcode inside the new template part.

[asafm7]

@SergeyBiryukov

I'm by no means a security expert, but it makes sense to me that if an unauthorized user can't modify the content of a block template, there is no problem with allowing shortcodes there (the same way blocks are allowed).

If, on the other hand, an unauthorized user *can* modify the content of a block template, the issue is much bigger than shortcodes.

The example given here is submitting a comment:
​https://www.wordfence.com/threat-intel/vulnerabilities/wordpress-core/wordpress-core-621-shortcode-execution-in-user-generated-content?asset_slug=wordpress

But the comments' content isn't part of the block template content, so I can't see the problem.

[danwol702]

I don't understand the security issue here, or perhaps the fix has not been thought through?

Adding a shortcode in a template part (such as 'header' or a custom part that I make) means that the shortcode executes as expected.

Adding a shortcode to the general area of a template does not work.

Adding a shortcode in a page or post does work.

What's the logic behind this? Because it doesn't seem to make sense from where I am. You can still insert a working shortcode in the site editor as long as you put it in a named section. Doesn't seem like that will have helped security very much!

[pik33]

That update destroyed my WordPress project. There are 2 problems introduced. First, the shortcode element doesn't work in the block theme (so what is its purpose now, anyway?). Second, my plugin generated output with shortcodes inside (so they were nested) and this also stopped working.

While I can change the plugin to do its job without these nested shortcodes, having no possibility to add a shortcode on the main page is a big problem.

I used the workaround from post 7 to restore the functionality.

[asafm7]

Sorry if this is a stupid question, but how are shortcodes less secure than blocks? Aren't they both placeholders being saved in the DB and later being replaced with content by a function? The concept seems identical to me. The only thing I can think of is the parsing mechanism. Maybe "parse_blocks" is safer than "do_shortcode"? If this is the case, can't "do_shortcode" be made safer?

[benniledl]

Are Shortcodes likely to be completely removed in the future?

[mllapan]

Step by step we will be locked to use block themes as well.
This update does not affect classic themes, which means they have plan to ditch classic themes, as they care for security of block themes only.

Take down shortcodes, take down classic themes, you took down 90% of WordPress users.
No one is thinking about BuddyPress, bbPress and hundreds of other plugins that are affected by blocks, shortcodes?

If these Gutenberg things are easier, that would be great, but you did not even make a thing work, and you are already trying to lock us inside that.

Wordpress will have a great downhill slalom for this.

For me, you can completely remove custom fields and shortcodes if you do this.
I call videos above title, above post content with specific styling.

If plan is to move us to block themes than say it directly, announce date when classic theme support will end.

[kraftner]

Although I can understand the stir this breaking change affecting a lot of people has caused, as a fellow WordPress user I'd like to remind you to please remember:

If you have any constructive (technical) input to the issue at hand - great! Add it to this ticket here. But at the same time I'd like to gently remind you that this is an issue tracker and not a discussion forum. For extended discussion including venting please head over to the forums: ​https://wordpress.org/support/welcome/

Venting your (understandable) frustration here won't speed up resolving this issue and might even add noise that only distracts those working on a solution. Like @SergeyBiryukov already mentioned this is already handled with very high priority which will hopefully result in a solution as soon as humanly possible.

[mllapan]

@kraftner, remove Gutenberg and no one will be frustrated.
It is just a problem from the beggining.

I am not familiar with core trac, but if you link me topic about Gutenberg, I will be more than happy to write a novel about how trash it is.

[kraftner]

Replying to mllapan:

@kraftner, remove Gutenberg and no one will be frustrated.
It is just a problem from the beggining.

I am not familiar with core trac, but if you link me topic about Gutenberg, I will be more than happy to write a novel about how trash it is.

@mllapan Trac is meant for working on issues, not for general discussion. If you are interested about how this works you can find more information here: ​https://make.wordpress.org/core/handbook/contribute/trac/

There already are multiple support forum threads on this issue like ​https://wordpress.org/support/topic/wordpress-v6-2-1-breaks-the-shortcode-block-in-templates/ and ​https://wordpress.org/support/topic/updated-to-6-2-1-and-now-shortcodes-arent-working-in-block-theme-templates/ including the one you have opened: ​https://wordpress.org/support/topic/gutenberg-shortcode-outside-post-area/

For general discussion on Gutenberg: ​https://wordpress.org/support/plugin/gutenberg/
For reviews of Gutenberg: ​https://wordpress.org/support/plugin/gutenberg/reviews/

[Ipstenu]

@mllapan I totally understand and empathize with your frustration. At this point, 'just remove Gutenberg' is not going to happen with WordPress.

When you say things like this:

I am not familiar with core trac, but if you link me topic about Gutenberg, I will be more than happy to write a novel about how trash it is.

What you end up doing is making every single person who wants to help and make the editor better feel like absolute trash. That doesn't help anyone, and is absolutely contributing to burn out.

I get being upset, but can we dial back things like this and remember to treat all humans kindly? We can't reasonably expect anyone to want to help us when we tell them their work is trash :(

[janwat]

THANK YOU
Replying to uxl:

There is a workaround if you need to place a shortcode in a template:

Using the block inserter, add a "Template Part" block, give your new custom template part a name for your own reference if you wish, and then add the shortcode inside the new template part.

[asafm7]

@Ipstenu may I suggest that part of the frustration is the lack of the ability to participate in a discussion?

This thread isn't a discussion, and @kraftner clearly stated that isn't meant to be. I've tried Slack, but was pointed back here.

@kraftner pointed here: ​https://wordpress.org/support/welcome/, and I assume was having this page in mind: ​https://wordpress.org/support/forums/. But there are multiple forums there, and it isn't clear which one is relevant. I've tried a couple, and none of them mention this issue.

The bottom line is that it seems there isn't a place to have an effective discussion (at least not an easily-found one), and when there is no discussion there is frustration.

That might point to a bigger communication gap, which in turn might have led to this problematic version update. (I believe the outcome of the security fix wasn't very hard to predict. "Killing" shortcodes like this feels a bit out of touch)

I've been using WordPress for years, and that is the first time I dive deep into how the discussion is made. To be honest, I'm a bit disappointed. Considering the fact that it is an open-source project, the discussion doesn't feel very open. (Slack felt to me sort of exclusive)

I'm not sure who's who here (and that might be part of the problem), and what your rule is in the community, if you have one. But if you do, maybe you can suggest to the people in charge to work on simplifying and improving the communication with the users' community.

I hope I'm not missing something obvious here.

[Ipstenu]

@asafm7 There are MANY ways to converse without jumping to insults (I was directly calling out a specific person in my other reply for a reason, you didn't do anything wrong).

Frustration is fine, we all get upset and frustrated and want to throw our hands up at things, but being intentionally mean is not okay. No place is good for telling people they (or their work) is trash.

Now, I agree it's confusing.

This ticket is not for 'discussion' in the sense that it is not for ranting about how much you hate WP/Gutenberg/a person. This ticket's for collecting data and working on issues, discussing the issue's technical merits and flaws, offering information that can help the security folks determine if this was the wrong fix, and finally for talking through possible solutions.

At this moment, we are ALL stuck waiting for security to make some kind of call here. And that SUPER sucks! I hate it too. I would love to know why this is somehow more risky than shortcodes in general, and why a security release with a breaking change was not more clearly announced to everyone.

IMO, this absolutely should have been something forums was pre-warned about. And it should have been a heck of a lot clearer in the release post. Even just 'Shortcodes no longer work in block templates due to a security issue. We will disclose this issue....'

That probably would have gone a long way to stave off panic.

[pbiron]

Replying to andergmartins:

For those who want to stay on 6.2.1 and need to restore the support for shortcodes on templates, you can try this workaround.

Since shortcode blocks still work in template parts, an easier work around is to:

1. create a template part
2. move the shortcode block that was in the template to the new template part
3. change the template and add the template part in place of the shortcode block

I've verified that this works.

[asafm7]

@Ipstenu

Yes, of course, we should always be polite :)

I wasn't referring to any specific part of the conversation. I was just trying to highlight the connection between frustration and lack of communication :)

Thank you (and all of the community) for your great work!

Replying to Ipstenu:

@asafm7 There are MANY ways to converse without jumping to insults (I was directly calling out a specific person in my other reply for a reason, you didn't do anything wrong).

Frustration is fine, we all get upset and frustrated and want to throw our hands up at things, but being intentionally mean is not okay. No place is good for telling people they (or their work) is trash.

Now, I agree it's confusing.

This ticket is not for 'discussion' in the sense that it is not for ranting about how much you hate WP/Gutenberg/a person. This ticket's for collecting data and working on issues, discussing the issue's technical merits and flaws, offering information that can help the security folks determine if this was the wrong fix, and finally for talking through possible solutions.

At this moment, we are ALL stuck waiting for security to make some kind of call here. And that SUPER sucks! I hate it too. I would love to know why this is somehow more risky than shortcodes in general, and why a security release with a breaking change was not more clearly announced to everyone.

IMO, this absolutely should have been something forums was pre-warned about. And it should have been a heck of a lot clearer in the release post. Even just 'Shortcodes no longer work in block templates due to a security issue. We will disclose this issue....'

That probably would have gone a long way to stave off panic.

[domainsupport]

Replying to pbiron:

Since shortcode blocks still work in template parts, an easier work around is to:

I've verified that this works.

How confident are you that support for shortcodes in template parts won’t also be rescinded?

Because I’m not that confident.

I would appreciate being included in any discussions to help find a resolution. I realise this is a sensitive topic but I believe I can (and want) to be of assistance.

[pbiron]

Replying to domainsupport:

How confident are you that support for shortcodes in template parts won’t also be rescinded?

I'm neither confident nor unconfident...since I'm not part of the security team and don't know the details of the vulnerability for which the 6.2.1 solution was to remove support for shortcodes in templates, but not template parts or post content.

[masteradhoc]

+1 having the same issue on my FSE Theme where i use shortcodes. Would be glad for a fix.
For now we'll try @pbiron's solution - thanks for that!

[kaylam]

You can also simply "create template part" from the problematic block(s) and update your template for fewer steps.

Replying to pbiron:

Replying to andergmartins:

For those who want to stay on 6.2.1 and need to restore the support for shortcodes on templates, you can try this workaround.

Since shortcode blocks still work in template parts, an easier work around is to:

1. create a template part
2. move the shortcode block that was in the template to the new template part
3. change the template and add the template part in place of the shortcode block

I've verified that this works.

---

It's been time-consuming to drop everything and comb through templates on multiple websites. It wasn't just affecting proper Shortcode blocks for us: Gravity Forms, Toolset Content Templates and (some) Views blocks... a website using a lot of custom post types and fields had about 95% of the content vanish into unrendered shortcodes.

Also, I'm unclear why a shortcode rendered in a Template PART is more secure than a Template. To me, a template part is for bits I want to use in multiple templates. I'm concerned that this Parts work-around is just a temporary fix.

[gimbalspinner]

Replying to andergmartins:

For those who want to stay on 6.2.1 and need to restore the support for shortcodes on templates, you can try this workaround.

Add the following code as a plugin in a PHP file in the plugins folder:

<?php
/*
Plugin Name: Fix shortcode
Plugin URI:
Description: Restore shortcode support on block templates
Author: Anderson Martins
Version: 0.1.0
*/

add_filter('render_block_data', function($parsed_block) {
    if (isset($parsed_block['innerContent'])) {
        foreach ($parsed_block['innerContent'] as &$innerContent) {
            if (empty($innerContent)) {
                continue;
            }

            $innerContent = do_shortcode($innerContent);
        }
    }

    if (isset($parsed_block['innerBlocks'])) {
        foreach ($parsed_block['innerBlocks'] as $key => &$innerBlock) {
            if (! empty($innerBlock['innerContent'])) {
                foreach ($innerBlock['innerContent'] as &$innerContent) {
                    if (empty($innerContent)) {
                        continue;
                    }

                    $innerContent = do_shortcode($innerContent);
                }
            }
        }
    }

    return $parsed_block;
}, 10, 1);

But be aware that support was removed for fixing a security issue, and restoring shortcode support you are probably bringing back the security issue.

Activating this as a plugin has not fixed it unfortunately.

[EmpireOfLight]

Replying to uxl:

There is a workaround if you need to place a shortcode in a template:

Using the block inserter, add a "Template Part" block, give your new custom template part a name for your own reference if you wish, and then add the shortcode inside the new template part.

I wish this worked but it doesn't for me.

[EmpireOfLight]

Replying to gimbalspinner:

Replying to andergmartins:

For those who want to stay on 6.2.1 and need to restore the support for shortcodes on templates, you can try this workaround.

Add the following code as a plugin in a PHP file in the plugins folder:

<?php
/*
Plugin Name: Fix shortcode
Plugin URI:
Description: Restore shortcode support on block templates
Author: Anderson Martins
Version: 0.1.0
*/

add_filter('render_block_data', function($parsed_block) {
    if (isset($parsed_block['innerContent'])) {
        foreach ($parsed_block['innerContent'] as &$innerContent) {
            if (empty($innerContent)) {
                continue;
            }

            $innerContent = do_shortcode($innerContent);
        }
    }

    if (isset($parsed_block['innerBlocks'])) {
        foreach ($parsed_block['innerBlocks'] as $key => &$innerBlock) {
            if (! empty($innerBlock['innerContent'])) {
                foreach ($innerBlock['innerContent'] as &$innerContent) {
                    if (empty($innerContent)) {
                        continue;
                    }

                    $innerContent = do_shortcode($innerContent);
                }
            }
        }
    }

    return $parsed_block;
}, 10, 1);

But be aware that support was removed for fixing a security issue, and restoring shortcode support you are probably bringing back the security issue.

Activating this as a plugin has not fixed it unfortunately.

Doesn't work for me either on a TT3 child theme using a basic ACF shortcode. Turning on WP_DEBUG doesn't show any errors.

[mllapan]

@Ipstenu, I am not trying to be negative person, and I am targeting no one.
True is that Gutenberg is a good idea badly done.

I raised topic few times in feedback forum, last was yesterday, and every time it is deleted.
So, I don't dare to try openning new posts about it, I will get a ban.

We are not able to raise discussion about Gutenberg anywhere, except rating it.

You have 2000+ one star reviews for this approach.
You have thousands of problems posted on forums.
It is clear what people think about it, and it is clear that it is pushed against will of majority.

Biggest problem is that this type of project is confusing to masses, we all learn functions.php, style.css.
You have us, ordinary people (freelancers) that learn CSS, some PHP and we are maintaing sites for customers.

For example, customer asks to add video player above post content.
Use meta key, develop shortcode, add new template for single post.

In blocks approach is easier, but removing shortcode now is a big deal.
Not just removing shortcodes.
I can't find, for example, where I would put JS in block, except again calling external JS in functions.php and adding JS to hide element that is holding empty src of video players (to hide video player).
CSS is avaiable in blocks, it is good, I see that it is adding up in json, but that box should be avaiable to be shown in fullscreen, so we can format CSS in a nice way.
Something similar should be added so we can add JS scripts.

And finally, when you use everything in block system, adding CSS, customizing few days, one day you awake, make a new change, press save, and there you go, all CSS, all customized things are gone, theme is reset for no explanation.
This happened to me twice and I learn to export theme often to avoid this problem as well.

Child themes missing header and footer, few support questions raised about this, no answer, I read it is also reported somewhere on this trac.
Workaround is to export existing theme, call it a new name and use it, for which we will not get updates, because it is now a new name theme.

Gutenberg easily becomes heavy, I put everything at 10000mb, and still magazine page will not load fully, after changes are done with heavy lag, pressing save more often saves nothing because it loses connection to server (overloads server).

We do not know to use new approach, to use json way, to create new blocks.
It is too complicated for someone who is not schooled to be a coder.

I guess we all want to know why developers push something what people, in its current state, dislike, and why we don't get answers.
Why to change a project which rules the internet.

I said all this knowing that this is a free project, not trying to ofend anyone, nor I am a person that gives up easily, I try hard to understand and work with it, but it is not yet good.

This is so-so off topic (so-so it is not), but I have to tell it somewhere.
I hope you understand mine, and probably, other people frustration, because we all have pretty much similar problems with Gutenberg.

Trash is a lingo word we use to tell that something is bad, it does not really mean it is a garbage.

[Pirenko]

Replying to EmpireOfLight:

Replying to gimbalspinner:

Replying to andergmartins:

For those who want to stay on 6.2.1 and need to restore the support for shortcodes on templates, you can try this workaround.

Add the following code as a plugin in a PHP file in the plugins folder:

<?php
/*
Plugin Name: Fix shortcode
Plugin URI:
Description: Restore shortcode support on block templates
Author: Anderson Martins
Version: 0.1.0
*/

add_filter('render_block_data', function($parsed_block) {
    if (isset($parsed_block['innerContent'])) {
        foreach ($parsed_block['innerContent'] as &$innerContent) {
            if (empty($innerContent)) {
                continue;
            }

            $innerContent = do_shortcode($innerContent);
        }
    }

    if (isset($parsed_block['innerBlocks'])) {
        foreach ($parsed_block['innerBlocks'] as $key => &$innerBlock) {
            if (! empty($innerBlock['innerContent'])) {
                foreach ($innerBlock['innerContent'] as &$innerContent) {
                    if (empty($innerContent)) {
                        continue;
                    }

                    $innerContent = do_shortcode($innerContent);
                }
            }
        }
    }

    return $parsed_block;
}, 10, 1);

But be aware that support was removed for fixing a security issue, and restoring shortcode support you are probably bringing back the security issue.

Activating this as a plugin has not fixed it unfortunately.

Doesn't work for me either on a TT3 child theme using a basic ACF shortcode. Turning on WP_DEBUG doesn't show any errors.

I'm not sure why, but to me, this only works when I use

<!-- wp:core:shortcode -->[shortode_here]<!-- /wp:core:shortcode -->

If I use

<!-- wp:shortcode -->[shortode_here]<!-- /wp:shortcode -->

it doesn't work. I'm adding this to a template...

[miyarakira]

Since shortcode blocks still work in template parts, an easier work around is to..

How confident are you that support for shortcodes in template parts won’t also be rescinded?

..I'm unclear why a shortcode rendered in a Template PART is more secure than a Template.

I'm wondering about this also.

This security fix removed do_shortcode from the function get_the_block_template_html in the file wp-includes/block-template.php.

It seems the same security vulnerability would exist in the block core/post-content which applies the_content filter, including do_shortcode.

​https://github.com/WordPress/wordpress-develop/blob/d5792c7a8861330d53adc05dacfdfdccb822b1d4/src/wp-includes/blocks/post-content.php#L54

A while ago I was made aware of these places where do_shortcode processes the entire page HTML, because it was breaking certain HTML attributes which contained [] square brackets. I had to implement a workaround to prevent it from doing so. But now in WP 6.2.1, one of those places no longer runs do_shortcode, which broke the workaround - and I had to release a quick fix for it.

It'd be great to be informed of these breaking changes in advance:

• Will the change in 6.2.1 be reverted in 6.2.2 to run do_shortcode again?
• If not, will the core/post-content block continue to run do_shortcode, or will it be removed also?

[audrasjb]

Hello and thank you all for contributing to this public ticket,

Just a quick reminder: please avoid off-topic discussion about Gutenberg or the project philosophy and stay focused on the actual issue. This is a Trac ticket, not a blogpost :)
There are many ways to express yourself about the WordPress Project: WP Devchat (every wednesday at 20:00 UTC on #core Slack channel) and of course make.wordpress.org/core post comments.

Replying to miyarakira:

It'd be great to be informed of these breaking changes in advance:

• Will the change in 6.2.1 be reverted in 6.2.2 to run do_shortcode again?
• If not, will the core/post-content block continue to run do_shortcode, or will it be removed also?

These options are still being actively discussed in the Security Editor group, but 6.2.2 will probably be a minimalistic "patch version" focused on solving the issue introduced by the related security fix. The Security Team will post an update about this as soon as possible.

[domainsupport]

Replying to audrasjb:

These options are still being actively discussed in the Security Editor group, but 6.2.2 will probably be a minimalistic "patch version" focused on solving the issue introduced by the related security fix. The Security Team will post an update about this as soon as possible.

I don't suppose there a way to request to join the Security Team?

Also, in the meantime, whilst we wait for their decision as to how this issue is going to be dealt with, what is the recommended method to replace a shortcode block? Would it be to develop a custom dynamic block to replace each shortcode? ​https://developer.wordpress.org/block-editor/how-to-guides/block-tutorial/creating-dynamic-blocks/

Thank you for your input.

Oliver

[La Geek]

Is there any information on whether there is a risk for classic themes when using shortcodes?

[miyarakira]

@la-geek Classic themes are not affected by this change, only block themes.

[La Geek]

@miyarakira

Thank you, I got this. But maybe there is also a security risk there?
As asked before in #47

"why a shortcode rendered in a Template PART is more secure than a Template."

so I wonder, if rendered shortcodes in classic themes are still secure?

[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, ​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).

• the get_the_block_template_html call all the same functions as the the_conent filter so they are run twice
• ​no_texturize_shortcodes WP filter broken with block themes
• ​Single quotes are rewritten as quotes in HTML block and Shortcode blocks
• ​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 (​here) - all of which applies do_blocks and do_shortcode
• Entire page: get_the_block_template_html (​here), which applies do_blocks and do_shortcode
• Template part: render_block_core_template_part (​here), which applies do_blocks and do_shortcode
• Post Content block: render_block_core_post_content (​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 believe a proper solution to all the above, including the vulnerability of shortcode execution in user-submitted content, is to selectively apply these content filters only as needed. As described in ​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.

[La Geek]

@miyarakira
Thank you very much 🌻

[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. Moreover, people are using 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(). With this, by definition, you only apply do_shortcode() on the template structure, which is inaccessible to unauthorized users.

Replying to 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, ​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).

• ​no_texturize_shortcodes WP filter broken with block themes
• ​Single quotes are rewritten as quotes in HTML block and Shortcode blocks
• ​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 (​here) - all of which applies do_blocks and do_shortcode
• Entire page: get_the_block_template_html (​here), which applies do_blocks and do_shortcode
• Template part: render_block_core_template_part (​here), which applies do_blocks and do_shortcode
• Post Content block: render_block_core_post_content (​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 ​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.

[domainsupport]

Replying to 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.

Oh.My.Days! No wonder shortcode support was stopped! That's crazy! Thank you @miyarakira for the explanation!

How about for blocks that are not marked as having shortcode support (like the Yoast block), an option is added in block ("Advanced") settings to enable shortcode support for that block so that it's not enabled by default but can be enabled if required? Obviously this should not be an option for blocks that contain user content (like a comment block).

[asafm7]

@domainsupport @miyarakira to be honest I'm a bit confused.

Even with comments blocks, the comments themselves aren't a part of the template structure, they are saved elsewhere in the database and are only retrieved later.

Am I missing something?

Can't we just do_shortcode() on the block template structure, before blocks are rendered?

[domainsupport]

Replying to asafm7:

Even with comments blocks, the comments themselves aren't a part of the template structure, they are saved elsewhere in the database and are only retrieved later.

Am I missing something?

Can't we just do_shortcode() on the block template structure, before blocks are rendered?

I think that the problem was / is that the do_shortcode filter is run on the entire HTML after blocks have been rendered. This means that anything that has a shortcode in the template content has the shortcode rendered whether it's user content or a shortcode block or whatever! Eeek!

[asafm7]

Well yes, exactly.

If this was the case, let's just move do_shortcode() to an earlier position, before blocks are rendered (or even before they are parsed).

This way, user content is never going through do_shortcode().

I mean, I understand the original issue, I just don't understand why is it still an issue :)

But again, maybe I'm missing something.

Replying to domainsupport:

Replying to asafm7:

Even with comments blocks, the comments themselves aren't a part of the template structure, they are saved elsewhere in the database and are only retrieved later.

Am I missing something?

Can't we just do_shortcode() on the block template structure, before blocks are rendered?

I think that the problem was / is that the do_shortcode filter is run on the entire HTML after blocks have been rendered. This means that anything that has a shortcode in the template content has the shortcode rendered whether it's user content or a shortcode block or whatever! Eeek!

[domainsupport]

Replying to andergmartins:

For those who want to stay on 6.2.1 and need to restore the support for shortcodes on templates, you can try this workaround.

Add the following code as a plugin in a PHP file in the plugins folder:

But be aware that support was removed for fixing a security issue, and restoring shortcode support you are probably bringing back the security issue.

Just a thought ... but could this code be modified to look at each part of the $parsed_block and search for shortcode blocks (perhaps with a suitable regex) and then just run do_shortcode() only on the shortcode block content? Surely that would allow shortcode support without the security risk ... ?

[danwol702]

Replying to domainsupport:

I think that the problem was / is that the do_shortcode filter is run on the entire HTML after blocks have been rendered. This means that anything that has a shortcode in the template content has the shortcode rendered whether it's user content or a shortcode block or whatever! Eeek!

Wow!

So rather than running do_shortcode at a more sensible time (I assume that's why classic themes are still ok?) someone decided that just not having shortcodes at all and not telling anyone would be better?

[domainsupport]

Replying to asafm7:

Well yes, exactly.

If this was the case, let's just move do_shortcode() to an earlier position, before blocks are rendered (or even before they are parsed).

This way, user content is never going through do_shortcode().

I mean, I understand the original issue, I just don't understand why is it still an issue :)

But again, maybe I'm missing something.

I think because even if you add it at an earlier position, you are still running do_shortcode() on the rendered block content for all blocks. So you're still in the same sticky wicket. The problem is automatically choosing which blocks have do_shortcode() enabled and which don't. The given example, the Yoast block, which wouldn't have shortcodes working if you blocked shortcodes by default on all but core blocks. So it's not a straight forward issue.

[asafm7]

You don't need to do anything special. Just pass the whole raw template content through do_shortcode(). The raw template content doesn't include user-generated content. I'm pretty sure I've done it before.

Replying to domainsupport:

Replying to andergmartins:

For those who want to stay on 6.2.1 and need to restore the support for shortcodes on templates, you can try this workaround.

Add the following code as a plugin in a PHP file in the plugins folder:

But be aware that support was removed for fixing a security issue, and restoring shortcode support you are probably bringing back the security issue.

Just a thought ... but could this code be modified to look at each part of the $parsed_block and search for shortcode blocks (perhaps with a suitable regex) and then just run do_shortcode() only on the shortcode block content? Surely that would allow shortcode support without the security risk ... ?

[domainsupport]

Replying to danwol702:

Wow!

So rather than running do_shortcode at a more sensible time (I assume that's why classic themes are still ok?) someone decided that just not having shortcodes at all and not telling anyone would be better?

Yes ... except that a "more sensible" time doesn't exist to run shortcodes on all blocks when some blocks can have user content.

[domainsupport]

Replying to asafm7:

You don't need to do anything special. Just pass the whole raw template content through do_shortcode(). The raw template content doesn't include user-generated content. I'm pretty sure I've done it before.

If that's the case then I'm sure the Security Team will come up with something pretty soon. I hope you're right.

[gmariani405]

Replying to andergmartins:

For those who want to stay on 6.2.1 and need to restore the support for shortcodes on templates, you can try this workaround.

Add the following code as a plugin in a PHP file in the plugins folder:

<?php
/*
Plugin Name: Fix shortcode
Plugin URI:
Description: Restore shortcode support on block templates
Author: Anderson Martins
Version: 0.1.0
*/

add_filter('render_block_data', function($parsed_block) {
    if (isset($parsed_block['innerContent'])) {
        foreach ($parsed_block['innerContent'] as &$innerContent) {
            if (empty($innerContent)) {
                continue;
            }

            $innerContent = do_shortcode($innerContent);
        }
    }

    if (isset($parsed_block['innerBlocks'])) {
        foreach ($parsed_block['innerBlocks'] as $key => &$innerBlock) {
            if (! empty($innerBlock['innerContent'])) {
                foreach ($innerBlock['innerContent'] as &$innerContent) {
                    if (empty($innerContent)) {
                        continue;
                    }

                    $innerContent = do_shortcode($innerContent);
                }
            }
        }
    }

    return $parsed_block;
}, 10, 1);

But be aware that support was removed for fixing a security issue, and restoring shortcode support you are probably bringing back the security issue.

Fixed it, this looks to be working now.

<?php
/*
Plugin Name: Fix shortcode
Plugin URI:
Description: Restore shortcode support on block templates https://core.trac.wordpress.org/ticket/58333
Author: Anderson Martins, Gabriel Mariani
Version: 0.2.0
*/

function parse_inner_blocks(&$parsed_block)
{
    if (isset($parsed_block['innerBlocks'])) {
        foreach ($parsed_block['innerBlocks'] as $key => &$inner_block) {
            if (!empty($inner_block['innerContent'])) {
                foreach ($inner_block['innerContent'] as &$inner_content) {
                    if (empty($inner_content)) {
                        continue;
                    }

                    $inner_content = do_shortcode($inner_content);
                }
            }
            if (isset($inner_block['innerBlocks'])) {
                $inner_block = parse_inner_blocks($inner_block);
            }
        }
    }

    return $parsed_block;
}

add_filter('render_block_data', function ($parsed_block) {

    if (isset($parsed_block['innerContent'])) {
        foreach ($parsed_block['innerContent'] as &$inner_content) {
            if (empty($inner_content)) {
                continue;
            }

            $inner_content = do_shortcode($inner_content);
        }
    }

    $parsed_block = parse_inner_blocks($parsed_block);

    return $parsed_block;
}, 10, 1);

[domainsupport]

Replying to asafm7:

This demonstrates my thinking:

It is a (working) draft, so try at your own risk :)

I mean, if that works then great! Have you tested it on a block that would previously have rendered shortcodes in user content?

[asafm7]

​https://wordpress.slack.com/archives/C02RQBWTW/p1684420353792009?thread_ts=1684420210.321779&cid=C02RQBWTW

Replying to domainsupport:

Replying to asafm7:

This demonstrates my thinking:

It is a (working) draft, so try at your own risk :)

I mean, if that works then great! Have you tested it on a block that would previously have rendered shortcodes in user content?

[azaozz]

Please note: any workaround, including the workarounds posted in comments here, seem to "revert" the security fix and may make a site insecure. It's not a good advice to use such code in production.

[kaylam]

Replying to azaozz:

Please note: any workaround, including the workarounds posted in comments here, seem to "revert" the security fix and may make a site insecure. It's not a good advice to use such code in production.

Are you including using Template Parts in your assessment of "any workaround?"

[vanko]

This v2 of the fix code working thank you!

Replying to gmariani405:

Replying to andergmartins:

For those who want to stay on 6.2.1 and need to restore the support for shortcodes on templates, you can try this workaround.

Add the following code as a plugin in a PHP file in the plugins folder:

<?php
/*
Plugin Name: Fix shortcode
Plugin URI:
Description: Restore shortcode support on block templates
Author: Anderson Martins
Version: 0.1.0
*/

add_filter('render_block_data', function($parsed_block) {
    if (isset($parsed_block['innerContent'])) {
        foreach ($parsed_block['innerContent'] as &$innerContent) {
            if (empty($innerContent)) {
                continue;
            }

            $innerContent = do_shortcode($innerContent);
        }
    }

    if (isset($parsed_block['innerBlocks'])) {
        foreach ($parsed_block['innerBlocks'] as $key => &$innerBlock) {
            if (! empty($innerBlock['innerContent'])) {
                foreach ($innerBlock['innerContent'] as &$innerContent) {
                    if (empty($innerContent)) {
                        continue;
                    }

                    $innerContent = do_shortcode($innerContent);
                }
            }
        }
    }

    return $parsed_block;
}, 10, 1);

But be aware that support was removed for fixing a security issue, and restoring shortcode support you are probably bringing back the security issue.

Fixed it, this looks to be working now.

<?php
/*
Plugin Name: Fix shortcode
Plugin URI:
Description: Restore shortcode support on block templates https://core.trac.wordpress.org/ticket/58333
Author: Anderson Martins, Gabriel Mariani
Version: 0.2.0
*/

function parse_inner_blocks(&$parsed_block)
{
    if (isset($parsed_block['innerBlocks'])) {
        foreach ($parsed_block['innerBlocks'] as $key => &$inner_block) {
            if (!empty($inner_block['innerContent'])) {
                foreach ($inner_block['innerContent'] as &$inner_content) {
                    if (empty($inner_content)) {
                        continue;
                    }

                    $inner_content = do_shortcode($inner_content);
                }
            }
            if (isset($inner_block['innerBlocks'])) {
                $inner_block = parse_inner_blocks($inner_block);
            }
        }
    }

    return $parsed_block;
}

add_filter('render_block_data', function ($parsed_block) {

    if (isset($parsed_block['innerContent'])) {
        foreach ($parsed_block['innerContent'] as &$inner_content) {
            if (empty($inner_content)) {
                continue;
            }

            $inner_content = do_shortcode($inner_content);
        }
    }

    $parsed_block = parse_inner_blocks($parsed_block);

    return $parsed_block;
}, 10, 1);

[SergeyBiryukov]

Please keep the ticket open for now, it should be closed when code changes are made to WP core to address the issue.

[lanacodes]

I would also like to draw everyone's attention here, as I have practical experience of what this vulnerability can cause:
This vulnerability in block templates makes vulnerabilities in shortcodes unuath vulnerabilities, which can be very serious.

I alone have reported more than 400 shortcode stored XSS vulnerabilities in plugins. Among them in plugins with 100k+ and 1M+ and 3M+ active installs.
Obviously, users should update these plugins.

Don't share code that enables shortcodes in block templates.
Don't make it possible to enable the shortcode in the block templates in the settings.

[pigsound]

Replying to uxl:

There is a workaround if you need to place a shortcode in a template:

Using the block inserter, add a "Template Part" block, give your new custom template part a name for your own reference if you wish, and then add the shortcode inside the new template part.

[pigsound]

this did the job for me, so i did not have to roll back to the previous wp version and don't have to us a plugin that reactivates the security issue – thank you!

[domainsupport]

Replying to pigsound:

There is a workaround if you need to place a shortcode in a template:

Using the block inserter, add a "Template Part" block, give your new custom template part a name for your own reference if you wish, and then add the shortcode inside the new template part.

this did the job for me, so i did not have to roll back to the previous wp version and don't have to us a plugin that reactivates the security issue – thank you!

I'm afraid that if your template part contains blocks that show user generated content then you are re-activating the security issue.

[agendah]

What is the practical difference between doing

wp_kses_post(do_shortcode())

and

wp_kses_post(do_blocks())

? Shouldn't core re-enable shortcodes in templates this way. Otherwise, with same logic, we should also remove blocks from block templates as they are vulnerable. Having nothing to draw eliminates vulnerabilities.

EDIT: I actually read the replies this time. Presumably

<!-- wp:heading -->
This
<!-- /wp:heading -->

is prevented injection in user content but

[someshortcode]

isn't and solution is to do parsing for both before user content. Database content is fine if it's wp_template or wp_template_part but not anything else. And not wrap entire template with do_shortcode, but rather direct block content of wp:shortcode. Similar to that fix plugin listed above but only for a curated list of blocks.

[domainsupport]

I've just tested this solution from @ciantic and it works. Furthermore it renders the shortcode on a per-block basis so doesn't fall foul of the security flaw that has caused this issue ​https://wordpress.org/support/topic/wordpress-v6-2-1-breaks-the-shortcode-block-in-templates/page/2/#post-16745883

All we need now is a solution for inline shortcodes.

Oliver

[nicwinner]

Can anyone demonstrate precisely how to reproduce the issue?

Does the security patch produce the issue when upgrading from v5.9.5 to v5.9.6?

Is it limited to only ​Block themes (aka Full Site Editing or FSE themes) and does not present on ​Classic themes?

[bjf2000]

@nicwinner No idea how to reproduce or even to determine if shortcodes are used, but all the security updates I checked have the same release notes and so mention the same shortcode change. In your case:
​https://wordpress.org/documentation/wordpress-version/version-5-9-6/

I haven't seen anyone say that classic themes are included in this issue. We have Astra (plus Elementor), and I'm not exactly sure which it is but am leaning toward FSE.

[desrosj]

In 55828:

Editor: Restore shortcode support for block templates.

Follow up to [55761].

Props youknowriad, Clorith, desrosj, antpb, Otto42, johnbillion, jorbin, rmccue, timothyblynjacobs, mikeschroder, peterwilsoncc, audrasjb, matveb, noisysocks, xknown, ehtis, isabel_brison, talldanwp, gziolo, chriscct7, davidbaumwald.
Fixes #58333.

[desrosj]

In 55829:

Editor: Restore shortcode support for block templates.

Follow up to [55761].

Props youknowriad, Clorith, desrosj, antpb, Otto42, johnbillion, jorbin, rmccue, timothyblynjacobs, mikeschroder, peterwilsoncc, audrasjb, matveb, noisysocks, xknown, ehtis, isabel_brison, talldanwp, gziolo, chriscct7, davidbaumwald.
Merges [55828] to the 6.2 branch.
See #58333.

[desrosj]

In 55830:

Editor: Restore shortcode support for block templates.

Follow up to [55761].

Props youknowriad, Clorith, desrosj, antpb, Otto42, johnbillion, jorbin, rmccue, timothyblynjacobs, mikeschroder, peterwilsoncc, audrasjb, matveb, noisysocks, xknown, ehtis, isabel_brison, talldanwp, gziolo, chriscct7, davidbaumwald.
Merges [55828] to the 6.1 branch.
See #58333.

[desrosj]

In 55831:

Editor: Restore shortcode support for block templates.

Follow up to [55761].

Props youknowriad, Clorith, desrosj, antpb, Otto42, johnbillion, jorbin, rmccue, timothyblynjacobs, mikeschroder, peterwilsoncc, audrasjb, matveb, noisysocks, xknown, ehtis, isabel_brison, talldanwp, gziolo, chriscct7, davidbaumwald.
Merges [55828] to the 6.0 branch.
See #58333.

[desrosj]

In 55832:

Editor: Restore shortcode support for block templates.

Follow up to [55761].

Props youknowriad, Clorith, desrosj, antpb, Otto42, johnbillion, jorbin, rmccue, timothyblynjacobs, mikeschroder, peterwilsoncc, audrasjb, matveb, noisysocks, xknown, ehtis, isabel_brison, talldanwp, gziolo, chriscct7, davidbaumwald.
Merges [55828] to the 5.9 branch.
See #58333.

[miyarakira]

Editor: Restore shortcode support for block templates.

If the solution to fixing the security vulnerability while still supporting shortcodes was to put do_shortcode before do_blocks.. What about all the "content" filters - the_content, widget_text_content, and widget_block_content - all of which applies do_blocks then do_shortcode? And the Post Content block, which applies the the_content filter and can also have nested Post Content blocks?

[gimbalspinner]

Sorry if this was made clear. But what exactly does 6.2.2 fix? As far as I can tell, shortcodes are still broken for me if I don't activate the plugin made by @andergmartins. Is this about fixing the underlying vulnerability, but still using template parts as a workaround? Are "inline shortcodes" as in using the shortcode block in the FSE still broken?

[Pirenko]

Replying to gimbalspinner:

Sorry if this was made clear. But what exactly does 6.2.2 fix? As far as I can tell, shortcodes are still broken for me if I don't activate the plugin made by @andergmartins. Is this about fixing the underlying vulnerability, but still using template parts as a workaround? Are "inline shortcodes" as in using the shortcode block in the FSE still broken?

It is working fine for me after updating to 6.2.2. No need for any custom code from @andergmartins.

[domainsupport]

I'm afraid the solution in v6.2.2 does not work for us. Although it re-enables shortcodes in templates, it does so by executing the shortcodes before the content filters which means that superfluous <br> and <p> tags are injected into the shortcodes.

This is especially destructive for <textarea> elements as the value is changed.

I have raised a separate ticket for this: 58366

[walacky]

Some shortcodes still do not work even after the update to 6.2.2

[desrosj]

@walacky If your issue is similar to what @domainsupport is describing, please comment on #58366 with more details. Unfortunately we can't do much investigation with "some shortcodes still do not work".

As far as this ticket is concerned, please leave it closed as it was addressed in 6.2.2. If there are additional cases still experiencing issues, please open new tickets so that they can be milestoned and triaged appropriately.

[WraithKenny]

For the record, when using Gravity Forms (a fairly popular plugin) the patch and the various fixes on the thread don't work to resolve the issue.

On WP 6.2.2, using a FSE Block Theme, inserting a Gravity Form block in the Footer template part works in the Editor, but on the theme side (front end) a shortcode is printed instead.

Thought you'd like to know.

(Deleting the Gravity Form block, and replacing it with the shortcode directly, fixes the issue on the themeside, but removes the editor functionality of course.)

[WraithKenny]

One of the weird parts of getting the issue with Gravity Forms to appear seems to involve activating/deactivating the latest version of Gutenberg plugin. I have no idea why that's the case though.

Edit: Deactivating the prior version of Gutenberg didn't cause the issue to reproduce. But upgrading the *deactivated* plugin did cause the issue to reproduce. How weird is that?

[WraithKenny]

Gravity Forms fixed the issue in their plugin, so nevermind I guess

[sao987]

I have posted a thread in community forum but it appears nobody could help (Link: ​Here).

Basically shortcode still does not work in navigation block on WP 6.2.2, it works in in sidebar and header, but not navigation menu block. Because of very limited navigation block designs I think it's even more important for navigation block to support shortcodes...

[sao987]

My problem has been solved with the help of people in the community forum...