WordPress’s new editing experience in WordPress 5.0 is built on the idea of Blocks, in that each piece of content on a page is a Block. Blocks are meant to be much more user friendly, with interactive interfaces that allow you to edit/create content in-place, right in the editor.
As a WordPress plugin developer, you might be thinking that Blocks are a replacement for shortcodes. After all, shortcodes are clunky compared to nice user interfaces. And let’s face it, making your plugin’s users write code, even if that code is a shortcode, feels wrong.
For the most part, you’re right: Gutenberg Blocks are a better user experience than shortcodes. However, that blanket statement isn’t always true.
Not everything is a block (yet).
From widgets, to 3rd party page builders, to customized functionality in child themes, Gutenberg Blocks are far from being the standard source of output in WordPress. At the time of this article, we might even be 10 years away from Gutenberg Blocks fully replacing all editing areas in WordPress, if ever. The likelihood of output not being from Gutenberg either in a theme, a form builder, a plugin, or something else high, and is going to remain high for many years to come.
Blocks and Shortcodes must be feature-equal
Therefore shortcodes are not dead, and plugin developers should not abandon their shortcodes. Any output you have through a Gutenberg Block should be able to be accomplished through a shortcode as well. That is, if you want your users to have a good experience, and avoid a ton of unsolvable support tickets.
That means that you should be rendering your Gutenberg Blocks server side, and you should use a separate helper function to generate that output. That way, your shortcodes can use that same helper function, and you don’t need to maintain separate sets of code for Blocks vs Shortcodes.
Note: Some developers have taken the approach of putting their shortcode as the output of their Gutenberg Block. While the right idea, in practice it will cause headaches. Gutenberg will literally save the shortcode into the post_content field of the database, and any change to your Block code will cause it to break entirely. A better approach is to save some JSON as the output and use that data to render the Block on the server-side (see link above).
The concept of a Block generating a shortcode is the right idea – just be careful not to rely on shortcode text inside of your Gutenberg Block’s output render.
Build shortcodes first, then turn them into Blocks.
It can be tempting to jump into building Gutenberg Blocks without considering shortcodes at all. After all, building shortcodes later should be a breeze compared, right?
The problem with that approach is that you might accidentally do something cool with a Gutenberg block that can’t be done with a shortcode. That would mean your shortcodes and your Gutenberg blocks don’t have feature-parity, and it means your users can’t use your plugin’s output anywhere they need/expect.
Shortcodes work in Gutenberg
Another important thing to consider when building your plugins, especially if you have limited time/resources (who doesn’t?), is that shortcodes do work inside of Gutenberg. So if you don’t have time to build Gutenberg Blocks as well as shortcodes, build the shortcode only. It provides your users with full functionality, even if it is not as nice as it could be in Gutenberg.
Gutenberg Blocks are really a “nice to have”, while shortcodes are still a “must have”.
To sum it up
Ultimately, making sure you don’t abandon shortcodes will prevent headaches and prevent frustrating your users. Like it or not, shortcodes aren’t going anywhere soon, and we should all write code in a way that makes it easy to maintain both blocks and shortcodes side-by-side, re-using the output functions.