Pasting Flickr embed codes into WordPress blocks no longer works

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:

<p><a href="URL_of_Flickr_image"></a></p>

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.

Pay parking

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:

  1. Convert the automatically created default block to a Custom HTML block.
  2. After pasting the Flickr embed code, manually delete the <script> tags.
  3. 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.

Pay parking

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 six days a week, click here to subscribe!
To get my newsletter with previews of what I’m working on, click here to subscribe!


Comments

15 responses to “Pasting Flickr embed codes into WordPress blocks no longer works”

  1. arhphotographic Avatar

    Hi, I spent best part of a half hour of head scratching posting yesterday’s blog before I discovered the first option you mention. Progress???? It would have been nice to have been informed beforehand.

    1. Jim Grey Avatar

      Yes. It’s enormously frustrating to find something you rely on has changed with no warning.

  2. Dan James Avatar

    Hmm, annoying, especially for a prolific blogger like you Jim.

    I’m still using the old WP editor (they pestered me to change for a while and I ignored it and they stopped!) and whilst I use my images from Flickr, I just go to the image there, view all image sizes, right click on the 1024px one (which it opens first by default) and copy the URL, add insert this in the post in WordPress, using Add via URL.

    It’s not super slick and you just get the image, not any link to the image page in Flickr (which is fine for me), but only takes about 30 seconds for an image, so still pretty efficient. And saves me uploading big files into WP and burning up my storage allowance so much.

    We had a wellbeing survey come round at my dayjob the other day, and it asked what kind of things cause stress and anxiety at work in my team. I could genuinely answer that software (and sometimes hardware) updates are near the top of the list, especially when they appear to be a downgrade, ie theyr’e more complicated and take longer, than an upgrade.

    As a manager I want to be positive about any changes and “sell” this to the team, but when you can’t see the point yourself, and it causes frustration and exasperation all round, it’s hard!

    1. Jim Grey Avatar

      Flickr’s terms of service requires that if you use an image from Flickr elsewhere on the Web, the image is clickable and links back to the Flickr page from which it comes. I’ve always adhered to that.

      I find the block editor to be superior to all the old editors. I love it. I still love it despite this frustrating change.

      1. Dan James Avatar

        I’ll have to change at some point I’m sure!

        I have always honoured the original photographer on Flickr with a link when I’ve shared anything using a Creative Commins licence.

        Don’t need to worry about me using my own photos though, I give myself full permission!

        1. Jim Grey Avatar

          Yeah, I feel like Flickr’s TOS shouldn’t hold on my own images. But it’s not written that way and I’m a rule follower at heart.

  3. arhphotographic Avatar

    What about the ability to resize, in WordPress, is that no longer available?
    Andrew

    1. Jim Grey Avatar

      In non-justified mode the block is not giving the resize handles. In justified mode the resize handles appear but if I expand the image it pixelates, suggesting that it’s bringing in one of the smaller sized images from Flickr.

  4. arhphotographic Avatar

    Thanks for the information.

  5. Rachel Avatar

    Hi Jim! I understand your frustration and I’ll pass along this feedback to the support team. I agree that getting some kind of explanation makes a big difference, and out of curiosity I did some spelunking to see if I could figure it out.

    Here’s what I found: When I checked the browser console while pasting in the Flickr embed code, I saw a message about the “received plain text” (what I pasted in) and the “processed inline HTML” (the hyperlink tag you described). I traced that back to this function and this function in the WordPress block editor’s code — so there’s some underlying processing that happens in the original (WordPress.org) block editor.

    I then tested out the Gutenberg plugin on a self-hosted WordPress site, to get the beta version of the block editor and see if it happens outside of WordPress.com’s additional script tag stripping. Indeed, I can reproduce this issue in the 6.6.0 beta version of the block editor, whereas in the release version the embed code works as expected. (WordPress.com often runs versions of WordPress that are still in beta, which is why it’s happening on WordPress.com now.) I haven’t tracked down the exact change, but I did open an issue to report it to the Gutenberg project:

    https://github.com/WordPress/gutenberg/issues/17942

    Thanks for reporting issues like this, and for sharing your feedback about your support experience!

    1. Jim Grey Avatar

      Rachel, I’m very grateful to you for noticing this post and for investigating this condition! And of course I’m thrilled to learn that this condition was a regression after all. Thank you very much for writing a bug report! And let me just say that as someone who led testing teams for a long time that your writeup is fabulous — fully actionable, well detailed. I’ve subscribed to the issue so I can follow along. Again, thank you!!

  6. Galois Avatar

    Hi, Jim. I did open an issue in the Spanish forums, too:
    https://es.forums.wordpress.com/topic/editor-de-bloques-e-insercion-de-imagenes-via-flickr/

    Greetings. 🙂

    1. Jim Grey Avatar

      Muchos gracias mi amigo! I’ve followed the issue on GitHub and look forward to it being resolved.

  7. slywy Avatar

    I thought it was just me but now see it isn’t. Very frustrated by something that worked seamlessly to something that works only with a tedious workaround that I accidentally discovered. (I think mine may be somewhat different but similar principle.) Very frustrated indeed.

    1. Jim Grey Avatar

      It is frustrating. I think they accidentally broke this, and have acknowledged that, but are not moving fast to fix it.

Leave a Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: