February 22, 2021 – Updating and moving this generic article forward for a new bug in Gutenberg. I don’t know how many users have run across this one yet, but I have. I have several snippets of HTML code that I like to reuse. I do this because it streamlines getting things I want to regularly add to my posts added without having to lookup or re-enter the code over and over again. Things like podcast embeds and the like (the subject of the previous bug I wrote about here, actually) well, they changed the way that reusable blocks work, again.
This bug report touches on the problem that I am experiencing: Comparing old and new Reusable block UX methods. #29178. It doesn’t quite cover the problem, though. Part of the usefulness of the reusable blocks was the ability to explode said blocks back down into base elements, such as code blocks and text strings and whatever. The ability to take pieces out of the reusable block has changed along with the editability of the blocks, and the dot next to the publish button stays present even if I completely remove the reusable block from the document being edited, because I have to change the block in question in order to be able to remove it.
Here is a snippet of my screen as an example. One of the blocks that I frequently did use was an HTML block that was just a horizontal rule (named “Separator”) that I could manipulate to suit my own visual issues. Basically, I wanted the rule to be of a particular length and a particular number of pixels. I am not really a coder, I’m just a user who is forced on occasion to fiddle with code, and I’m okay with this situation, as long as it doesn’t mean I have to code every single time I sit down to write something.
As you can see from the image, the block now sees itself as a group, not a single HTML code block like the Audio Embed block next to it. This is because I inserted the block and then saved the document I placed the block in. As soon as the code block is inserted into a document, it turns itself into a group. Unless you know to turn off saving reusable blocks at the prompt, this error will occur every time you use a reusable block and then save the document the block is placed in.
If you place the reusable block and then try to delete it, the group remains without the block you’ve added. The best part of this is that saving after you think you’ve removed the reusable blocks and not noticed the prompt is that if you save blocks that you thought you completely removed from your document, the editor creates empty group blocks in place of the reusable block that you had previously created. Without the ability to just remove the block and not have it turn itself into a group; without the ability to explode a block and reduce it to simple code and text, the end user is left with having to leave multiple tabs open set to various configurations of files just to be able to assemble a single document. A process that simply isn’t feasible on a mobile platform, for example.
h/t to paaljoachim for creating three bugs reports to deal with these issues 29267, 29268, 29269. The conversion back to standard blocks function was moved to a button on the bar from the pulldown menu at the end of the bar (bug 29268) I honestly don’t know if the overlapping squares button would break reusable blocks into standard blocks before I noticed the other new behavior that was so frustrating, but as of 3/9/21 it was working to do the job I wanted done. Thank you to mtias for pointing this out.
November 4, 2020 – This bug 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.
Using the encoder I can now put the transmogrified code strings into the code block and get displayed text that looks like the verse block does just by pasting the actual code into it:
<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 remains 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.
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.
