My first pure block plugin was QuotesDLX. It was built completely for the block editor. When I released the plugin on AppSumo a year ago, I didn’t get many sales. Adding insult to injury, the plugin hasn’t sold a single copy on my site except the licenses I’ve given to friends, colleagues, and potential reviewers.
I asked on Twitter, “What’s stopping you from trying out QuotesDLX?”
A person responded, “I do not use the block editor at all, so your plugin has no use for me.”
This made me think, “Should I include a shortcode option for my block plugin?”
Blocks versus shortcodes
As mentioned, blocks are like mini-applications that run in the block editor. Blocks have settings that are saved and then rendered on the front end. These settings can be quite complex, especially for layout blocks where shortcode equivalents make no sense. If you’ve ever had to code a responsive component, you’ll know that the attributes can quickly balloon into dozens if you’re not careful.
Shortcodes, however, are slivers of markdown that resemble HTML tags with attributes if you get down to the basics. For example, here’s a shortcode for a plugin I adopted called WP Plugin Info Card:
Code language: AsciiDoc (asciidoc)
The issue with shortcodes is there is typically no interface for generating these shortcodes unless there is an integration with the Classic Editor and TinyMCE. I’d rather pull my hair out than integrate with TinyMCE, but it’s still a necessary evil.
For the most part, shortcodes must be created by hand. And some of these shortcode attributes can get pretty intense.
So, on one hand, you have blocks, which, when designed correctly, provide a visible interface for configuring some desired output. On the other, you have shortcodes, which are more versatile, backward compatible, and work with most page builders, widget areas, and even in the block editor via the shortcode block.
The block editor by numbers
It’s hard to find accurate and relevant information on block editor stats. For example, the Classic Editor is installed on over 5+ million sites. The block editor, pulling stats from WordPress.com and Jetpack-hosted sites, sits at about 81.6 million installs. Granted, this doesn’t consider non-Jetpack users who have the block editor enabled.
According to W3 Tech, WordPress powers roughly 43% of all website traffic (with a 60+ percent CMS market share).
According to ColorLib, the number of sites using WordPress is about 810 million total websites. While the math is flawed because there’s no telling how many actual block editor users there are, the .com/Jetpack counts only factor into about 10% of the total usage of the block editor.
When you factor in shortcodes, the number of compatible sites skyrockets because shortcodes are ready out of the box for most WP installations and are usually compatible with the major page builders.
The downsides of shortcodes
If you’ve ever used the Divi theme, you’ll know the drawbacks of using shortcodes for layouts and other complicated actions. It can quickly morph into something called “Shortcode Hell.” Shortcodes aren’t very visual until you view them on the front end, so looking at shortcode gobbly-goop can quickly remind you of messing with table-based layouts.
Since shortcodes are typically manually created by the user, there is a ton of validation to ensure that the inputs by the user are valid. With blocks, each attribute has a data type and some structure. With shortcodes, it’s a lot more difficult to enforce data types. Furthermore, it’s tough to validate this input since shortcodes are a garbage-in, garbage-out paradigm.
Marrying shortcodes and blocks?
When I adopted Plugin Info Card, it only had shortcodes. When I built blocks for the plugin, the output of the block was run through the same shortcodes that came with the plugin initially. This was to ensure backward compatibility. For each new block, I made sure there was a shortcode equivalent. While this hasn’t resulted in skyrocketing installs, the ease of blocks has made its way into the reviews.
For another block plugin I have called AlertsDLX, I decided against shortcodes. With features like custom SVG icons and the various mode options, creating a shortcode would be like going backward in time.
So, how does one create a shortcode from a complicated block? I’ve thought of a few ways to do this when it comes to blocks, but I struggle with the execution.
One idea I had was to create a block-enabled post type specifically for use with one of my blocks. A user could configure the block, get it working, preview it, and then create a shortcode based on that post ID.
The Post ID would be read in via shortcode, the attributes from the block are parsed, and wallah, you have a block that can work as a shortcode.
The downside of this approach, again, is that the user would have to use the block editor to configure the block. It’s a chicken and egg scenario. Can you create a shortcode from a block if the user isn’t willing to use the block editor?
An alternate approach is to build some type of UI allowing the user to create shortcodes visually, similar to a TinyMCE integration. However, this would reinvent the wheel already running in the block editor.
Not all blocks lend themselves to shortcodes, but if you can swing the overhead of maintaining both a block and shortcode, then creating a shortcode equivalent should be a no-brainer.
However, a complicated block may not lend itself to shortcodes. And the workarounds may be too time-consuming.
Just know that if you create a pure block plugin, you’re relying on users who have the block editor enabled and are actively using it.
What are your thoughts?