Gutenberg Editor Bug

November 4, 2020 – Updating and moving this generic article forward for a new bug in Gutenberg. This one has to do with inserting coding blocks into the text that I’m working on. Like images, I occasionally have need to reference a specific podcast, either one that has sent me off on this fool’s errand of illumination, or one I want to provide to readers in order to give them some understanding of where I am coming from. Podcasters are as plentiful as the various kinds of life in a rainforest, and their approaches to embedding, whether it is even allowed or not, varies almost as much as the podcasters themselves.

The most plentiful podcaster out there at the moment is NPR. They are everywhere, all the time, and I link their podcasts as frequently as I link podcasts from any other source. However, the current version of Gutenberg does not recognize the embed codes for NPR podcasts, just like it has never recognized most of the embed codes for other podcasts.

This has never been a problem before because I have simply been able to introduce my own code into the text, taking the place of a paragraph, and that has solved the problem. Now the wise coders working on Gutenberg have seen fit take out my ability to write my own code into the text automatically, and I have to go to extreme lengths just to be able to get my code to appear unmolested in the published article.

I had a reusable block that I called Generic Embed. In that block I had assembled the code that rendered something like what I expected to see in the finished blog article. That block isn’t even visible in the block interface anymore. I have to scroll to the bottom of the reusable block list and select Manage all reusable blocks, and then find the block within the list of reusable blocks that I have created.

Looking at that list I can see that it is time to thin the reusable blocks down again. However, I can show you the code that is in the block because there are a couple of blocks that let me do this for you. Here is the code.

<figure><iframe src="embed url"></iframe><figcaption><span style="font-size:8px"><em><a href="webpage">author - page title - date</a></em></span></figcaption><br></figure>

That is the default block for verse. I suspected that block would leave the code alone because I’ve transformed text into verse in the past and it faithfully reproduces the verse exactly as typed within the constraints of the screen that is displaying the text.

If you use the default code block provided with the Gutenberg editor you will have to use an HTML encoder (h/t to the users at Stackoverflow for the tips) to change the code into the escape strings necessary to reproduce the code. Why this process is not automated within the block is beyond me.

<figure><iframe src="embed url"></iframe><figcaption><span style="font-size:8px"><em><a href="webpage">author - page title - date</a></em></span></figcaption><br></figure>

In trying to present the raw code, I discovered that the ever helpful WYSIWYG is trying to make the code do things even when it is NOT SUPPOSED TO DO ANYTHING TO THE CODE except to display it as code. In the various tests I have conducted trying to discover a work-around, hours of trial and error and research into coding and displaying code that I should have learned years ago, I was driven to near madness trying to figure out why I could not just paste text as typed directly into the interface. No. I have to learn how to decode and recode in order to explain anything.

Modern day problems, being driven into a homicidal rage by things that should work one way but don’t because no one ever thought to eliminate that step in the process. However, my lack of formal training aside, this embed error shouldn’t have been allowed out in a supposedly finished product. A product people pay for. Thankfully, I don’t pay for it, or I’d be more pissed off than I am. Maybe you should fix this problem, WordPress?

In the meantime, I will come up with a work around for my podcast embeds, which will involve simply putting a dumb HTML block into the text and then manually adding the code that I want to appear there. It is a more time-consuming process to do it this way, but I will soldier on until the next update for Gutenberg fixes this bug and breaks something else.

Like the image bug that is documented below (but remain fixed, please don’t break that!) the embed bug also produces embedded objects that I cannot manipulate and captions that appear too large, but are manipulable from the settings menu, which does show up above and to the right if you have those menus turned on. The block isn’t there for all intents and purposes and can only be found by clicking off the object and moving the cursor so that it enters the embed, or selecting it from the pulldown at the top of the screen. Also, if you modify the text in the caption you will cause an irrecoverable block error and then have to do the whole thing over again.


The constrictions on adding a horizontal rule to a document have annoyed me from the first day that I worked with WordPress, even before Gutenberg. To be fully honest about my frustrations here, there have been no text editors that have ever been exactly what I wanted when it comes to presenting my words the way I want them seen, with proper margins, font styles, display graphics, etcetera. Every word processor has some deficiency that has left me cold towards it, and so being unsatisfied with all of them as much as I remain unsatisfied with my words themselves, I simply try to make do with whatever tools I have to work with.

I’ve finally come up with a version of the <hr> that displays properly within the Gutenberg editor specifically and WordPress in general.

<hr style="width:44%;height:3px" class="aligncenter">

Now that I know you have to generate escape strings to display code properly in the code box (again, why?) I can now display the code that works for me. Fingers crossed that they’ll automate that process. Or maybe not. That might get broken too if they try it. The verse block works so how hard is it to do a grey background (that for some reason means “code”) that doesn’t screw with your pasted text exactly like the verse box does?


March 14, 2020 – The latest release of the WordPress Gutenberg editor has dumbed down the editor to the point that it won’t work properly in the desktop interface. Basically, I can’t manipulate the images embedded in the text of my articles because the handles that show up at the manipulable edges of images disappear after the image is initially placed.

unusualjuggernaut.tumblr.com (I can’t click on this image in the desktop editor. For all intents and purposes, it isn’t in the document. I can go to the shiney-new block navigation hamburger and select the image block from the list. However, I can right-arrow scroll right out of the caption area but cannot left-arrow scroll back into it. I have to, once again, go to the hamburger and select the image block. This behavior could not be more annoying.)

Color me unimpressed with the latest release. I look forward to the next release, when they fix that bug and I can edit properly again.

Gutenberg version 7.8.1 seems to have fixed the image manipulation problem. I’ll leave the above block as I created it just as a reminder of the annoyance I felt at the time.

Author: RAnthony

I'm a freethinking, unapologetic liberal. I'm a former CAD guru with an architectural fetish. I'm a happily married father. I'm also a disabled Meniere's sufferer.

Attacks on arguments offered are appreciated and awaited. Attacks on the author will be deleted.