David Shanske

As someone who maintains a very specific set of WordPress plugins, over the last few years, I’ve been asked why I have not updated them to the block editor. The simplest reason is I don’t use the block editor, and I write the plugins for me, not for a commercial purpose, so while I keep saying I’m likely to give in and actually write some simple blocks just so people other than me can use them, it has been a hard road for me to take on such a project for others.

So, why don’t I use the block editor? Or why haven’t I embraced blocks in any way? It comes on two sides of the fence. The user and the developer side.

The traditional WordPress post is based around a single content field, in which HTML is saved. Now, you can enhance that with filtering, but anything that isn’t that content has to be handled separately.

So, compare this to blocks. Blocks are these pieces designed to be used in content. That allows you to do other things..have more complicated code for each block, or just a simple HTML structure.

However, this is exactly what HTML is for. I wouldn’t object to blocks for site-building, but for writing a post, I just want a nice rich HTML editor.

When blocks are saved to content, they end up as a combination of rendered HTML with the block code in HTML comments so it can be parsed and rerendered when edited. It also supports dynamic content, which would not be rendered when saved.

I’d actually considered this long before Gutenberg was proposed for Microformats. Microformats are embedded in HTML as classnames…I’d thought of creating an editor that stored this in content, and parsed it out in the editor.

So, it’s more than need most of the time for what I want to write. I’m either writing an article…a quick note(microblogging style), or sharing an event/link/etc, or sharing a photo. I don’t need most of the stuff being offered.

If you read this quote from the WordPress FAQ, we’re in alignment on this point:

“The classic WordPress editor is an open text window—it’s always been a wonderful blank canvas for writing, but when it comes to building posts and pages with images, multimedia, embedded content from social media, polls, and other elements, it required a mix of different approaches that were not always intuitive.”

So, that covers the user side. What about the developer side?

I am used to developing in PHP, server side. I write code using vim. So, what do I need to write a block according to WordPress?

• I need to learn Javascript ‘deeply’. Can’t say I’m motivated on that.
• I have to set up a build environment to support that if I want to go all in.
• I have no way to enforce Microformats structures in the block editor.  But…if someone wants to do a reply to 15 things in the same post, should that really be a problem for me?

For me, Javascript is meant to handle simple HTML manipulations and for calling server side to update a page. I rarely use it for anything else.

So, what about my IndieWeb plugins?  Well, some of the questions I have there are something a motivated person might be able to help me think of. Also, it is quite possible I’ve completely misunderstood something about blocks by not using them more.

• IndieAuth – Needs absolutely nothing I can think of. It’s an authentication plugin after all.
• Webmention – Other than maybe some settings options in the block editor, nothing here occurs to me.
• Micropub – Is there a simple way to create blocks in PHP so you can convert incoming Micropub posts into blocks? But you’d need some specialty blocks to represent various Microformats properties, which you’d need also for Post Kinds.
• Indieweb Post Kinds actually does a few different things. It creates a taxonomy to classify posts, similar to the old post formats options. This just allows for automatic creation of archives. I also use the selector to change the interface, but this could be done differently. It also uses Parse This to create rich embeds of linked content. But it adds the microformats for different types of Indieweb posts outside of the traditional content block using WordPress filters. That is something I never particularly liked, and wouldn’t mind replacing with something integrated into content. Just not sure if blocks would be better for that, being as you can’t necessarily identify what is the content piece. I very deliberately started the process of decoupling parts of Post Kinds just in case someone wanted a block editor interface to the backend logic.
• Syndication Links – The plugin allows you to add links to a post reflecting another version of that post elsewhere. So, this is fine if you go to a post, and add them in…but not necessarily if you want to trigger syndication and bring back the results in your posts. Of course, it sounds like a dynamic block could possibly do this.
• Simple Location – Probably is not a problem here to make this work as a block plugin, however, the location and other properties are stored in post meta. However, to use post meta dynamically, it needs to be added to the WordPress REST API so it can be polled via the block editor. But this is already a problem for me. Location can either be public or private…so, whether to share the location data to the REST API is based on the value of another field. register_meta has an option for an auth_callback, but that is for updating post meta values. Other than that, probably just a matter of motivation, as before.  But it would be the most likely for me to experiment with if I ever decided to try.
• Indieweb – The Indieweb plugin has several widgets that could be converted to blocks. There is the problem of the logic that allows rel-me links to end up in the header if there is not a visible display, but that could be worked out. Also, always convinced the H-Card Widget could be styled better.

So, there we are. I’d love it if someone commented…to either tell me why I’m wrong about something, or what I might consider.