Cancel

Sarah Gooding

WordPress Developers: Learn How to Convert Shortcodes to Gutenberg Blocks

Gutenberg contributor Gary Pendergast has published a handy sample plugin that demonstrates how to convert shortcode functionality to a Gutenberg block.

The first file shows a basic example of how to register a block with JavaScript and add block inspector controls to the sidebar. The second file is the PHP code for the plugin that converts the existing shortcode logic into a block that will work inside the new editor.

“This sample uses the ServerSideRender element,” Pendergast said. “It’s critical to remember that ServerSideRender is a stepping stone to a full block editing experience: having to call back to the server to re-render is a worse UX than native JS rendering. Use ServerSideRender to get your existing functionality ready for WordPress 5.0 now, and plan to phase it out over time.”

With WordPress 4.9.8’s “Try Gutenberg” callout just around the corner, this sample plugin may be helpful for developers who have created custom shortcode plugins for clients. If you’re not sure where to start, Pendergast’s sample plugin makes Gutenberg block creation more approachable. The Gutenberg handbook has more in-depth documentation for developers who want to improve their blocks beyond this basic example.

Category:
Tags:
7

7 responses to “WordPress Developers: Learn How to Convert Shortcodes to Gutenberg Blocks”

  1. Genuine question: why would someone want to do this? Shortcodes work, and will be usable both within Gutenburg (oh, how I dislike the absurd pretentiousness of claiming the name of a world-changing pioneer for something so mundane as an evolution in an editor) and outside it. If you want to support people using Gutenburg, and people not using it, and not to maintain two piles of code, then why bother with a block?

    Create forum topic from comment

    • why would someone want to do this?

      The primary reason for this would be to enhance your shortcode so that it is more visual based with gutenberg, so for example rather than n instagram shortcode, the new editor (gberg) would render the instagram feed with limited functionality in the editor so the user can see how it will look and flow with their content, visually.

      As a developer there isnt a whole lot of work to make your current shortcode gberg ready – thats the whole point of this article.

      For some people shortcodes are still really tricky. Most of my clients cant grok shortcodes as they are.

      Create forum topic from comment

  2. having to call back to the server to re-render is a worse UX than native JS rendering

    This is harmfully untrue. It is obviously true that interactions that don’t require server side interactions can be much quicker without having to interact with the server. But the notion that users will get a better UX if all the elements on the page rely on clientside render logic is laughable.

    Imagine if all shortcodes were converted to blocks, most authors are going to follow conventions, meaning that they are now going to double their work (and double their errors) creating javascript and php based render logic. Then this clientside logic will be loaded eagerly on every load of the editor, slowing it down and multiplying the likelihood of slow and bug ridden performance.

    Because the editor actually spectacularly fails at faithfully presenting the page as it would look on the front-end, you actually create even more potential problems. You can get styling issues, inconsistencies, script conflicts and inaccurate/broken content.

    The performance gains of clientsiding it all conjures a false mirage. If your shortcode relies on queries and/or filters, it is likely that you will be creating additional requests to the server regardless. The marginal benefits of speeding up rerendering with smaller payloads is offset by the amount of additional clientside logic that is being shuffled down preemptively on every load of the editor. Then you consider shortcode usage in context with what people spend their most time on in the editor: writing and editing words. Once a shortcode is in place and configured, you don’t need redundant components to be loading and slowing down the page. It is an extraordinary waste.

    I do hope shortcode authors are especially careful in how they go about this. Blindly following the dictum that clientside UI and render logic makes for better UX is fool’s gold. This is a case by case kind of thing and it even when it makes sense, its likely that plugin authors will underappreciate the potential net negative of having dozens of different shortcode authors presenting their new block logic on every page load of the editor.

    Create forum topic from comment

  4. I’m a slow learner; it took me years to learn PHP. So when a prominent member of the WP community said “learn javascript deeply” I decided it’s time to retire my shortcode based plugins.. or at least not to change stable tag to 5.0 the next couple of years ;-)

    Create forum topic from comment

  5. I did this yesterday to one of my plugins. Really wish I saw this link then :/

    Regardless, I ended up with something generally similar, and it didn’t take too long.

    why would someone want to do this?

    It was fun. And trying to embrace Gutenberg since at this point, its clearly not going away.

    Create forum topic from comment

You may also like

Newsletter

Subscribe Via Email

Enter your email address to subscribe to this blog and receive notifications of new posts by email.