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.
To get Down the Road in your inbox or reader, click here to subscribe!
Last updated on 5 March 2020 by Jim Grey