WP Perspectives Issue 10: Are Third Party Gutenberg Blocks a Poisoned Pawn?

In this issue: A look at content lock-in and Gutenberg addons. Also, the latest posts on WebTNG, and some useful links from around the web.

Dynamic WordPress – Are Third Party Gutenberg Blocks A Poisoned Pawn?

As a kid I played a lot of chess. My high school team were Washington-Baltimore area champs. In chess there is the notion of a “poisoned pawn,” that is the chance to take an opponent’s piece for free, to be a pawn up. It is called a “poisoned pawn” because even though you are materially ahead, you end up in a bad position and can lose the game. I’m using the analogy of the poisoned pawn to discuss the issue of content portability, or to flip it, the issue of content lock-in. An issue has been raised in the Dynamic WordPress Facebook group, should third party Gutenberg blocks be avoided because their use results in content lock-in?

The Question of Theme Lock-in

Questions about content lock-in have evolved over time. When page builders were making their debut theme authors started adding page builder features to themes. The Theme Team led by Justin Tadlock introduced the notion of “theme portability.” It was decided that for WordPress.org there should be a separation between theme and plugin features. Themes should provide styles and layout. Other features should be in plugins. For example, themes had started adding support for Custom Post Types, that is for content types like a Portfolio or a Team section. The problem was that if the Custom Post Type was created in the theme’s code, then when users changed themes they would lose access to the content. In this case, including the Custom Post Type in the theme was a “poisoned pawn” because you got these extra features included with the theme, however, long term you lost flexibility because you couldn’t change themes. Instead, Custom Post Types should be created in a plugin thus leaving users free to change themes without loosing access to their content.

The Divi theme was released in the early days of page builders. The Divi page builder is bundled with the Divi theme. Many users like Divi because with Divi it is relatively easy to create an attractive site. Divi uses shortcodes behind the scenes for content layout. A problem with Divi using shortcodes for layout is that if user changed themes then shortcodes are left behind littering the page. Beaver Builder was the first page builder to avoid shortcodes and to enable content layouts using CSS. A result of this is that if you disable Beaver Builder your content loses the formatting, but it is not littered with shortcodes. At the time, Chris Lema, who was and remains a big Beaver Builder fan, highlighted the issue when he wrote that “if you use Divi then it had better be forever.” In response, Elegant Themes released a standalone plugin version of the Divi builder, thus allowing users to change themes without turning their content into shortcode soup. For example, on the left is a page created with Divi and on the right is the content after Divi is disabled.

What About Plugin Lock-In?

Users are accustomed to the fact that if you change a plugin that provides shortcodes then you may need to go through your pages and remove the old shortcodes. Practically speaking, the size of the cleanup is in proportion to how extensively shortcodes were used. WordPress.org has never had a policy against plugin lock-in.

Remember the Divi Builder? It not only uses shortcodes for layout, but also to add actual content. For example, instead of using HTML image tags to add images to the page, Divi adds images using shortcodes. If you disable the Divi builder you are left with a bunch of shortcodes and you can’t just delete them because you will lose content. The fix is to recreate the content, which isn’t as hard as it sounds, because you can often use copy and paste, but it a manual process that can take a lot of time.

If you use a modern page builder to create pages, like Beaver Builder or Elementor, when you deactivate them your content remains, but you lose the formatting. For example, on the left is a Beaver Builder page and on the right side is the content after Beaver Builder is disabled. As you can see, it would be much easier for an end-user to fix the layout for the page on the right, than to fix the shortcode soup from the Divi example above.

Given the need to fix pages after the builder is disabled, the longstanding wisdom is to only use a “page” builder for “pages” and not for regular post content. The idea is that a typical site may have a dozen or so pages, but could have a hundred or more posts. Fixing a dozen pages is manageable, but fixing a hundred posts is a daunting task. So the question is, how much “poison,” or technical debt, do you incur when using a plugin? What is the tradeoff for the features and convenience?

Finally Getting Around to the Gutenberg Problem

Gutenberg as a WYSIWYG HTML block editor has a lot going for it. It supports a wide range of HTML elements without the need to edit code, however, people find core blocks to be very basic. Many third party Gutenberg addons are providing enhanced versions of core blocks and pretty much every Gutenberg addon comes with its own container block because the core version is so limited. There is also a move to duplicate advanced page builder modules or widgets, such as icon lists, Google maps, image hotspots, and flip boxes. Increasingly Gutenberg is being looked at as an alternative to page builders, even more so now that Full Site Editing is on the horizon. Many people are recognizing that third party addons are making Gutenberg more usable, are “saving” Gutenberg, and are empowering users.

Consider, are third party Gutenberg blocks a poisoned pawn? Are we gaining some convenience now but ending up long-term with being a bad position? Currently, third party blocks, when the plugin is disabled, show in the Gutenberg editor as a problem. Since the supporting plugin is gone, Gutenberg doesn’t know how to render them. This means loss of content or plugin lock-in. Here is an example of what users will see if the block plugin is no longer available.

WordPress has long supported the notion of backwards compatibility and this no doubt is a contributing factor to its growing popularity. Thus there is the assumption that whatever the WordPress editor morphs into in the far future that there will be an easy migration path, that people who use core will be taken care of. That’s not the case, however, for third party plugins. So, should third party Gutenberg blocks be avoided because their use results in content lock-in? The easy answer is yes.

I think it is safe to assume that the features of core blocks will continue to improve. They have incrementally done so and that is very likely to continue. One day we will have a decent container block and layout and styling options will be standardized across core blocks. As core blocks improve, people might be willing to eschew third party container, heading, button and image blocks in their post content. However there are two other dimensions related to third party blocks to think about.

User Expectations

Users are expecting a page builder. The initial vision for Gutenberg was that it should to be limited to being a content editor, then it jumped tracks and the developers started adding page builder features. Or, maybe in the modern world “content” includes text, images, multimedia sources, and dynamic data. There is a narrative that predatory developers and affiliate marketers are driving the adoption of third party Gutenberg plugins and a move away from page builders. However, a relatively easy to use, end user, rich and varied HTML editor is a paradigm shift and there is a strong feedback loop with user expectations. Users see a WYSIWYG drag and drop builder in WordPress and they want the features of page builders. Page builders made their lives easier and they see no reason to move backwards.

Third party plugins that fill in the gaps is “the WordPress way”, by design. Gutenberg provides a robust programmer interface for third party blocks. Therefore, users expect to find Gutenberg solutions using addons. Michael Edwin, in a “joking / not joking” comment, wondered if core blocks were limited on purpose to encourage third party developers, thereby growing the Gutenberg ecosystem? In any case, telling users to restrict themselves to core blocks only is like parents telling their adult kids not to use credit cards. No one is going to listen. You can only hope they do so responsibly.

The Advantages of Dynamic Data

The second consideration is dynamic data. WordPress has never included the ability to display custom fields on the frontend and there is no reason to assume that it ever will. There is probably zero chance that WordPress core will ever natively display ACF, Meta Box, Pods, or Toolset custom fields. Developers and power users have always been aware of the power of dynamic data, but page builders have educated the wider population to its advantages. Full Site Editing is all about dynamic data, but WordPress isn’t just a blogging platform and the standard post fields don’t sufficiently represent modern content. There is now a very strong demand for using dynamic data in post content and third party blocks are making that possible.

Are Blocks Like Content Formats?

Should we look at Gutenberg blocks as content formats? Vinyl records, cassettes, 8-track tapes, VHS videos, CDs, DVDs, and Blu-ray are content formats. Over time the old is superseded by a new format. When that happens you may lose access to your music, you can copy it to the new format, or buy it again. It seems WordPress content has come to an analogous place. When your block addon is no longer supported then you will need to port your content to a new block by editing or recreating your content, or you will lose access to it. This state of affairs is not ideal, but it seems to be the new reality.

Conclusions

Option 1: Don’t Do What I Do

I’m using Kadence Row Layout Block in my post content because the core columns block is very limited. I realize that if the core block gets better then one day I will need to go through my content and swap them. Also, Kadence just released their theme builder, the ability to create content templates for Custom Post Types and I plan to use it. I don’t think that using third party blocks for content templates is any different than using the premium theme building features of page builders. If you change builders then you will need to recreate those templates. I’m using these for my own sites. I think the Kadence developer is talented and will support his products for the foreseeable future. Also, I’m willing to port my content in the future or write some code to convert it when necessary. My case may be atypical, so don’t do what I do.

Option 2: Do This Instead

Be aware that if you use third party block addons you are creating a dependency. You limit the ability to switch blocks and your are relying on the block developers to future proof your content. So, here are some things to keep in mind:

• As we have seen, using core blocks is pretty safe, so use core blocks as much as possible for post content.
• It is probably fine to use third party blocks on pages, where you would normally use a page builder.
• It is also probably fine to use third party blocks in templates.
• If you are going to use third party block plugins then I’d favor developers with a track record who are likely to be around to support their plugins in the future.
• If or when you use third party blocks be aware that you are creating a dependency and the day will come when you have to do some manual cleanup.

Option 3: Opt Out

Of course the other option is to opt out of Gutenberg. I imagine that the Classic editor will be around for years to come. Or, you might wait to see if Gutenberg gets good enough for you, to see if the problems with Gutenberg are addressed, and then decide if you are willing to use it.

Share Our Concerns

We should start sharing our concerns with block developers. “What happens when I disable the plugin?” is a good question to ask to start to raise awareness. It would be good if the they can start to add the ability to fall back gracefully to standard HTML where possible.

Some Experimentation

I guess this is kind of “bonus content.” I spent some time experimenting with blocks while writing this issue of the newsletter and thought I’d share it in case you might find something interesting. I created a page in Gutenberg and added a button with a link to google.com using the core button block and three popular addons.

I wanted to see what happens when their plugins are disabled. What I’ve found is that the mark up is not all the same. Many of them write a number of their settings into the HTML block comment area. WordPress designates a block using HTML comments. For example, here is the core button block code:

Here is the GeneratePress code:

The Kadence code for the button block. Wow.

And the Stackable button block code:

None of them downgrade automatically when their plugin is disabled.

I was curious to see what happened if I disable the third party plugins and remove the HTML comments. Would they get picked up as HTML? Interesting, they were picked up as Classic blocks, much as if the content had come from the Classic Editor.

When you click on a Classic block there is the option to Convert it to Blocks. When I did that, the GenerateBlocks button became a regular link, while the Kadence and Stackable versions became HTML blobs.

The GenerateBlocks button was the cleanest, but they all worked on the front-end as either a button or a link.

These tests make me think that if could be possible for developers to create blocks that degrade in a nicer fashion so as to limit end user refactoring.

Recently Published

• Website Maintenance: My Routines And Tools – Websites need to be cared for and here I share my process.
• Plugin Appreciation: 10 Free Plugins I Like and Use – The free plugins available in the WordPress directory are a major factor in the projects success, help make our websites better, and save us a lot of time. Here are some of the ones I use.
• Full Site Editing and Custom Post Types: What You Need To Know – Full Site Editing is a new paradigm and this article provides an overview.
• Cwicly Gutenberg Toolkit: A New Full Site Editing Solution – This is a very promising theme and plugin that provides ACF access and Full Site Editing options.
• Fluent Support: A New Helpdesk and Ticket Management System – The WP Manage Ninja team delivers a solid WordPress based ticket support system.
• SEO Schema for Custom Post Types: Four Options Compared – Four different plugins and each approaches the process for creating SEO schema differently.
• Custom Post Types and Page Builders: Pods Review – The long awaited Pods 2.8 is released and I do a walk-through showing how to create content templates for Custom Post Types.
• Stackable Blocks Version 3: Overview and Look at Dynamic Data Options – Currently, Stackable Blocks Pro is the blocks addon poised for use with Full Site Editing.

From Around the Web

• Jamie Marsland has a great YouTube channel that is both educational and entertaining, with lots of good WordPress content.
• Elijah Mills of the Oxygen team has a nice video showing the Oxygen custom query builder. It is very powerful and Elijah is one of the best tutorial makers around.

Deals

• The WPVivid lifetime option is on sale at 40% off making this a very affordable and full featured solution.
• WPCodeBox is 35% off for lifetime licenses. This new plugin has seen regular updates and new features.

What’s Up Next?

I’ve never looked at the new Visual Composer. They just released its theme builder and I’m planning to take a look to see how it stacks up with other options. I’m looking forward to The Plus Addons for Gutenberg releasing their dynamic data options and I’d like to take a look at that also.

Thank you for reading. I’d like to hear what you have to say about the newsletter content and what you are excited about. Feel free to comment or send me an email through the contact form.

David McCan
December 15, 2021