4 Reasons your Shortcodes are on the Way Out

Loops & Logic’s predecessor is an older plugin called Custom Content Shortcode (CCS) that made extensive use of shortcodes. Much like older page builders used shortcodes and newer ones avoid them, the successor to CCS drops the reliance on shortcodes. Why are plugin makers choosing this path? Don’t they know that not everyone likes to use Gutenberg blocks?

While it’s fair to say that plugin makers shouldn’t be forcing anyone to use Gutenberg, there are reasons outside of the transition to the block builder that explain why everyone is making this change. Here are the top 4.

1 – Poor integration with HTML

Shortcodes are mixed in with post content, which goes through a number of text filters like wptexturize, convert_smilies, wpautop, shortcode_unautop, then do_shortcode. These filters are all search-and-replace of text patterns, which do not semantically “understand” the HTML syntax. This makes it a complicated and fragile process, impossible to reliably integrate with HTML. It can break your work in all kinds of unpredictable ways and is the biggest reason we feel like they’re a technological dead-end.

2 – Sketchy Support for Nesting

Our plugin is often used when you need to build complex loops, such as loops within loops. Shortcodes cannot natively be nested, and while the older CCS plugin got around this with a nesting “-” prefix, it’s inelegant and limited in functionality. A professional frontend building workflow demands a more natural way of expressing nested contexts.

3 – You can’t pass shortcodes as shortcode parameters

We often run into situations where we need to pass a dynamic variable to a shortcode, but you can’t safely do [tag attribute=[another-tag]] with shortcodes. Since we rely on our own markup system rather than shortcodes, we can easily allow <tag attribute={another-tag}> to accomplish this.

4 – WordPress is moving away from shortcodes

The WordPress developer website says that they think you should move your shortcodes to content blocks. The reasoning they give is as follows:

Blocks have visual editing built-in which creates a more rich, dynamic experience for building your site.

Blocks are simply HTML and don’t persist things the browser doesn’t understand on the frontend. In comparison, if you disable the plugin that powers a shortcode, you end up with weird visuals on the frontend (often just showing the shortcode in plain text).

Blocks will be discovered more readily with the block directory coming in 5.5 in a way shortcodes never could be allowing for more people to get more functionality. This is super exciting thinking longer term.

Anne Zazu – Developer Relations @ Automattic

In Conclusion

While shortcodes still have their uses, and L&L still has robust support for shortcodes (you can use the [template id=#] shortcode to insert an L&L template anywhere shortcodes can be rendered), they simply aren’t the future of WordPress as a platform. Breaking free from them doesn’t just help us enable a few more features now, it also ensures we can deliver exciting new integrations and ways to use L&L with blocks and Full Site Editing (FSE) going forward.