Someone at WordPress noticed my complaint and wrote up this detailed bug report in the WordPress GitHub (account required). It’s gotten a little attention in the intervening months, with its most recent update in April. But the bug persists.
An aside: As a fellow who makes his living in the software industry, I’m not at all surprised that WordPress hasn’t fixed this bug. I can’t imagine that this one ranks high on the to-fix list, as Flickr embeds are probably not a critical function. You can fix only so many bugs. Reading the report, there’s broad agreement that it is a bug, and some work has been done to get at its root cause.
The workaround I initially found is to create an HTML block, paste the Flickr embed code into it, delete the <script> tag from it, and convert it to a regular block. It’s a lot of steps for a simple result, but it works.
But recently I stumbled upon an even easier workaround. Create an Image block and press Ctrl-V to paste the Flickr embed code. Bam, the image appears. This method strips the <script> tag for you! It’s so much easier.
Grab handles appear on the image. Drag them to size the image to your liking.
Boom, that’s it, the next blocks flow around the image. At least, it did until the most recent block editor update. It’s broken now. After step 2 above, you can no longer select the block with the image in it. It appears to merge with the next block. If you click the image and use the block tools to delete the block, it deletes the next block but leaves the image in place. The only way to delete the image is switch to the Code Editor and remove the code that embeds the image. Here’s a screencast that illustrates what’s happening. This has got to be a bug.
I have found a sort-of workaround. Insert the image, size it, then left or right align it. It gives the desired end result, as you can see at left.
The only trouble is, you still can’t select that image block. I can’t resize it, I can’t move it, I can’t edit the caption. I can’t even delete it.
The only way to interact with the image block after that is in the code editor.
I opened a case with WordPress.com Support and described this regression. The support engineer said that the block editor was never designed to work in the way I described. I replied that it had indeed worked that way until a couple days before I opened the support case.
The engineer then asked me to either use the Text & Media block, or use the Classic Editor block, to do what I wanted.
This is an example of the Media & Text block. It doesn’t support Flickr embeds; unfortunately, I use Flickr to host most of the images here. Also, the default text is huge and you have to format it to try to match it to the rest of the post’s default text size. You get a slider to do that, and you have to match it by trial and error. It doesn’t actually flow the text around the image, as you can see.
It does work to use the Classic Editor. I’ve done it here: this paragraph and the image at right are in the Classic Editor block, and the paragraphs that follow are in Paragraph blocks.
It was surprisingly challenging to remember how to use the Classic Editor after all these months in the Block Editor, but I figured it out.
However, I was still sure I had found a bug, and I said so very directly to the support engineer. I shared an old post with the engineer that showed how I had flowed text around an image. I pointed the engineer to the underlying code behind the post to prove it: there were dimensions in the code for the image. Those wouldn’t have been there had I not used the grab handles to shrink the image. The engineer finally said, “Okay, I see you were able to do this before. It seems unusual that it was possible to do this before, but I can certainly report this change to the Block Editor devs. for you.”
No, it wasn’t unusual. This is how it actually worked.
Furthermore, following the steps I described above to flow text around an image results in a block you can no longer select, and can only delete by switching to the Code Editor. In what universe is that not a bug?
If anyone from WordPress happens to read this, I’d be grateful if you’d check what I’m saying here and, if I’m right, open a bug ticket for it. I’d surely like to see this fixed as I encounter this bug every day.
Most of the time when I open a support case with WordPress.com I get active troubleshooting. I’ve found several bugs over the years and most support engineers are happy to get to the bottom of it with me and, when I’m right, write a bug ticket. They even email me a link to the ticket so I can follow it and see when it gets fixed.
But every now and then a support engineer repeatedly tries to tell me that whatever bug I’m encountering is how the system is supposed to function, or that I am wrong about how the system used to work. That makes me nuts. I feel gaslit.
I know this support engineer doesn’t know me and has no idea I’ve been making software for a living since the late 80s. That I was a quality engineer for 17 of those years. I’m adept at identifying bugs.
Harrumph, enough ranting. I hope someone at WordPress.com figures out that this condition exists and puts it in the queue to be fixed.
Software engineers all over the world continuously deliver new and changed functionality to WordPress.com. This is great when you like the changes, and not so great when you don’t. Especially when you have to learn all new steps to do something you’d already learned to do and were happy with.
One major change was the new block editor. It was a whole new way of approaching creating content. I found it to be easy to learn and I like it a great deal better than any other editor WordPress has ever offered.
One thing I especially liked about it was how easily I could embed images from Flickr, which is where I host most of my images. In the old editors, embedding a Flickr image was a multi-step process. One of those steps was manually stripping out of the embed code a <script> tag that WordPress tripped up on.
WordPress actually doesn’t allow <script> tags in posts. This is wise, because those tags execute in your browser code that’s stored elsewhere. That code could be malicious. The code Flickr wants to run in your browser is harmless, but there’s no way for WordPress to know that.
In the block editor, simply pasting the Flickr embed code into an empty block stripped the <script> tag and made the image appear. Yay!
But this functionality was recently removed with neither warning nor explanation. Pasting a Flickr embed code into a block now results in a blank block.
But not an empty block. When you switch the block to HTML view, some HTML code appears. WordPress converted the Flickr embed code to the image’s simple URL wrapped in a hyperlink tag, wrapped in a paragraph tag, like this:
This is a malformed hyperlink, in that it specifies the link target (the page to go to, here the URL of the Flickr image) but no text or image to which to attach the hyperlink. The browser correctly renders this as blank.
Thinking I’d found a bug, I opened a case with WordPress.com support. They told me that simply pasting the Flickr embed code should never have worked because of the <script> tag. They didn’t explain why.
I pointed out to them that before this change, blocks flawlessly stripped out <script> tags. I asked if they would restore the old functionality. They said with no explanation that they would not.
They gave me two alternatives. The first is to paste the Flickr image’s URL into an empty block. This does work, but the image is of a fixed size, which is narrower than the block on some screens. I did it below, so you can see. There doesn’t appear to be any way to increase the image size. I almost always want the image to scale to full width, so this alternative won’t work for me.
The other alternative they offered is to paste the Flickr embed code into a block of type Custom HTML. This adds three extra steps I didn’t have to do before:
Convert the automatically created default block to a Custom HTML block.
After pasting the Flickr embed code, manually delete the <script> tags.
Open the block menu and choose Convert to Blocks to show the embedded image rather than its underlying HTML code.
This is not onerous, but it is disappointing because several days ago I did not have to do these steps. A real benefit I gained with the block editor is now lost. These steps give me the same end result I had before, at least.
In my work as a software engineering manager in a company that delivers a software product over the Internet, I’ve personally led engineers to deliver changes that have caused users frustration. There are a lot of valid reasons to do it. But users hate to be surprised by changes that alter their workflows, especially when they don’t know why it had to change.
I’d love it if WordPress.com would revert to the old functionality so I can just copy and paste those Flickr embed codes and move on. But I’d have an easier time accepting this loss of functionality if someone had given me even a flimsy explanation of why.
I was wrong. It’s stupefyingly easy. You just paste the Flickr embed code directly into an empty block. The image appears instantly! It also hyperlinks back to the Flickr page from which it came, per Flickr’s terms of service.
This is far easier than how we all had to embed Flickr images in any previous WordPress editor. Given that I use Flickr to host my photographs, Gutenberg is making creating posts significantly faster for me!
WordPress has been working for a long time on a new post editor, which they’ve named Gutenberg. The folks at WordPress.com are slowly rolling it out to users, allowing them to opt in to test it. As soon as it was available to me I took the plunge, and have written several posts with it now.
Gutenberg didn’t. That’s not to say it’s like any past WordPress editor; it’s not. It doesn’t offer Microsoft Word-style editing like every other editor in the universe. Each paragraph, photo, everything is its own element known as a block.
I thought this would be the most overthought editor design ever. But then I started typing my first post, and the majority of things I wanted to do fell right to hand or were quickly discoverable.
I make software for a living. Let me tell you — the quick learnability they have delivered is no mean feat. Within a couple posts I didn’t want to use the old editors anymore. I even converted my in-progress posts to Gutenberg.
To add any kind of content, you press Enter to create a new block. If you want a text element, just type. If you want any other kind of element — image, YouTube embed, pull quote, anything — hover over the block with your mouse, click the plus-in-a-circle icon that appears, and choose the kind of content you want from the list that opens. The block will then give you every clue you need to create, link to, or embed that content.
Moving blocks around isn’t a cut-and-paste operation, as it is in every other editor. You hover over the block with your mouse and some controls appear that let you drag and drop the block, or move it up or down in the document.
There are a few quirks yet that I hope they iron out.
First and foremost for me: you can’t directly embed Flickr images. You’d think you could use “Insert from URL,” but it doesn’t work for Flickr (yet?).
Fortunately, there’s a workaround: create an image block and hover over it. A toolbar pops up. Click the icon that looks like three dots stacked vertically. From the menu that appears, choose Edit as HTML. You’ll see some block code in there; triple click to select it all. Then paste in the image’s HTML embed code from Flickr. Then click away from the block. You will get a message about it not being in block format. Click Resolve, and then scroll down and click Convert to Block.
A helpful commenter explained that you can insert a Flickr image simply by pasting its embed code into an empty block. Bam! Easiest Flickr embedding ever in WordPress!
This is far easier than it was in the old editors, which had limited Flickr embed functionality. I always switched to HTML view and pasted the embed code there, which was more a pain than the workaround method in Gutenberg. But still, here’s hoping that WordPress streamlines this even more.
Another quirk is that while typing, if you delete the first letter of a word it also deletes the space before it. I have to assume this is a bug.
On my theme, at least, paragraph spacing is different (it’s most noticeable before and after images, as the image isn’t evenly spaced with the surrounding paragraphs). And image captions are centered, where the old editor left-aligns them.
There also isn’t a way to set the text Publicize uses when it sends your post to your social media accounts. I’ve been going back and doing that in the old editor; it seems to hold the formatting okay. Gutenberg creates code that is very different from the old editor’s so that wasn’t a given.
Again, I’m shocked by how easily and quickly I’m taking to Gutenberg. I look forward to WordPress improving on these quirks and adding missing functionality.
Sign up for my newsletter!
Sign up for my monthly newsletter, Back Roads, and be the first to know what I'm working on!