WordPress v6.2.1 Breaks the Shortcode Block in Templates

@ciantic does that affect the security in any way? Is that side-stepping the fix and revealing the vulnerability again?

But I agree with @ipstenu that yes, shortcodes weren’t exactly great in templates, I tried to do it the ‘proper’ way, find blocks and the like but some of them didn’t exist and indeed some plugins relied on shortcodes to work.

Andt the overhead of learning node.js and setitng up a local dev environment is way too high now. I can hack PHP code, but just to do the simple things I used to do on my old pre-FSE site, it’s a big ask to learn a whole language to put fairly minor logic in, or as I was putting a category dropdown on a search form. Yes, weirdly, no-one has a block to do that basic thing.

Obviously an issue for many (or some). My momentary recommendation is to restore your website(s) with a backup prior to this; or, have your host do a rollback with their server backups (providing this is made available to you).

I’m just now checking my Rough Pixels website, but so far, everything seems fine.

Thanks very much for explaining @rbrunskill. Will be helpful for the future.

What??? Give it back. Now.

There aare many reasons, why shortcodes should be allowed in templates. One of them for me is that they can be inline, something, what is not valid for any other blocks. So e. g. On one of my webs I have a short code [total], that shows total number of my listing’s, and I can then put it in any sentence, any paragraph, heading etc, like “we do have [total] listings. There is currently now other easy way how to do it in WordPress.

I uunderstand, that often plugin authors use shortcodes instead of blocks, and it destroys the block wysiwig feeling for the users. And I am totally open to find a solution for this problem. But not without discussing by breaking functionality on live websites in third level update. This is insane.

BTW you should ask, why plugin authors do it this way. You will probably find out, that they simply do not want to learn React, as they are whole live PHP programmers. Make an easy way, how to create wysiwig block, without need to use node, learning JS etc…. Simply the same way how they can do it now with shortcodes with one simple short function or with some admininstation, and they will not have to use shortcodes.

Oh schnap rubin-sev ! that was awesome! Corrected Contact Form 7 and Smash Balloom IG Feed Plugin shortcodes using your method

I’d keep an eye on it if you’re using the template-part work-around, there’s a some likelihood it was missed and will be removed too. The other workaround by running do_shortcode from the block innercontent also does not work properly with all shortcodes

Same problem : since WP 6.2.1,
shortcode not running in Block template.
shortcode running OK in Pages

@ciantic I’m going to try your suggestion. If it works I’ll owe you a beer! ??

Thank you! Template part workaround fixed my site!

Albeit I probably reintroduced the security issue. WordPress team please keep working on a new solution.

thanks

“[Shortcodes] maybe should have been disallowed from the start, since Full Site Editing is the way to go.”

@ipstenu

This is probably not the most helpful comment to make here, but I feel like it needs to be said: maybe this is an exhibit in the argument that Full Site Editing is not the way to go. It is not a useful tool to me as a longstanding WordPress theme developer, and it is not something any of my clients need or want access to (and I emphatically do not want them to have access to it).

Coincidentally, yesterday I made the decision to revamp my new base theme to not use the new HTML-based template structures, because I’m tired of trying to find hackish workarounds for the absence of PHP in templates.

So, to make this a somewhat constructive comment, I would encourage everyone to think about whether your theme really needs to support the Site Editor, and if it doesn’t, stick with PHP templates! It only took me about four hours to thoroughly restructure my theme to use PHP templates, eliminating awkward workarounds (which in my case was not shortcodes, but a combination of ACF Blocks and misusing Block Patterns).

If you’re all-in on the Site Editor, this is obviously not the answer to the problem… but if, like me, you’re just trying to give your users access to the Block Editor for content management but still controlling the overall theme structure with code, it really doesn’t make sense to abandon PHP-based templates.

Several of my large current projects broke. Currently, without creating a whole custom block it is very challenging to have custom queries that include custom fields. One way to do this is roll a custom WP_Query and add a shortcode to a archive-cpt template. Secondly, for the plugin FacetWP the filters/facets are added through shortcodes in the archive templates where they are used. This no longer works either. I think FSE requires easier query data manipulation in the query block (custom fields, etc) and some other mechanism for query filtering controls before we remove the capacity for shortcodes.

Prior to this issue (which has affected some big projects this week) I was actually thinking about the possibility of the shortcode block becoming more powerful in the FSE world by becoming a white label block for custom php-driven functions. Like a movable action hook that site developers could, in the ui, create an action that custom code could tie into. It would be an amazing way to allow flexibility for dynamic code customization with the familiarity of add_action…

EDIT – I eventually found plugins to replace the shortcode functionality – not totally happy about the bloat of adding 2 extra block repository plugins (Plus Addon blocks with has an Ajax search bar with category drop down, PostX) just for two minor things I previously did in a line or paragraph of PHP code!

But I found a bug in their restriction:

All through this I realised I had a widget plugin – Recent Posts Widget Extended – happily working through a Shortcode Block in the footer template. It seems weirdly they missed widgets with shortcodes? Or that widget has a weird work around even though it’s not been updated for months? And no, it wasn’t a template part cos I had to make it one to save the old block.

Needless to say I replaced it with PostX anyway; because who knows how long it will last and also whether it’s just a missed security hole.

But yes I second people in this thread saying there is a massive barrier to entry now, learning REACT/node.js and installing a dev environment just to adapt or customise an existing snippet of PHP code, plugin or widget is a really big ask.

There should be a secure core PHP Block, this would solve ALL of this, something that acts like the PHP of old but in the new system? It’s possible, the xyzscripts Insert PHP Snippet plugin did exactly this, until this update broke it. And Block Logic which I use which allows you to put PHP logic statements like is_home() && !is_paged() in blocks. These should be in core? Or at very least standard visibility settings on every block like Sticky became standard.

• This reply was modified 1 year, 6 months ago by timbearcub.
• This reply was modified 1 year, 6 months ago by timbearcub.
• This reply was modified 1 year, 6 months ago by timbearcub.

And, in their defence, it’s 2023, and using shortcodes in the modern block-templates maybe should have been disallowed from the start, since Full Site Editing is the way to go.

@ipstenu

Yes, you could have done this by creating a new project called BlockPress and leaving PHP based WordPress alone with the JavaScript block nonsense.

You can easily check the user feedback for the Gutenberg plugin and the active install number of the Classic Editor plugin.

You’d be amazed to see the amazingly complex things that average users use shortcodes and plugins for. You are taking it away from the users and saying “here you go, but you can edit blocks within the limits we want”. But everyone used shortcodes, everyone knew how to do it, even if it was more complicated and “not so user-friendly”.

So yep, you really shouldn’t have mixed the classic editor with shortcodes with the block editor. Moreover, you should have done this by creating a separate CMS for the blocks, but no one would use that, just as no one used Gutenberg as a plugin.

Well, you’ve removed the shortcodes from the block templates, now we’ll see again how many people choose blocks instead of shortcodes.
Then I hope you will realize that it would be more worthwhile to develop Core based on user feedback.

@lanacodes I assume you mean ‘you’ as in WordPress. Not ‘you’ as in Mika (notice how I said THEY in my post, it’s not me)

The reason I say they probably should have blocked them from the get go is because I happen to know that there is a goal to reduce shortcodes as much as possible and (in a perfect news) get rid of them. FSE is the direction the project leaders decided, and it’s not my call to make if that’s right or wrong.

And I left a 5 star review for Gutenberg. YMMV.

Yeah I don’t get the Gutenberg hate, but the very least they should have disallowed some blocks like Shortcode they were phasing out in the Full SIte Editor. That was dumb of the WP devs. People are going to use the old ways unless you tell them otherwise or guide them to new stuff.

But as I said, what would have been better is to build a bridge via say, an official PHP block – or indeed listening to what users and devs want. Because the PHP legacy won’t disappear overnight, and my experience of FSE and the ‘new’ way of creating themes is it’s really frustrating if you want to do more than the basics and can’t find a plugin to do what you need? By limiting what people can do, people of course turned to ‘hacky’ solutions like shortcodes. That’s not their fault, the functionality should be there in the first place. Or some translation across from PHP to REACT/js.

There’s a need to do certain things that were common in PHP themes which now are really hard – I gave up trying to create a player for my podcast frontpage excerpt posts as I could not work out how to plug into the Query Block Loop in a block fashion – even AI gave up on that and gave me the way I used to do it with PHP! Stuff like that, it feels like FSE makes some hard things really easy, but the most simple things REALLY hard. And it shouldn’t.