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.