Intermittent rendering of URL to images in Discourse?

What and who is affected by this issue/request?

At least the posts that contain multiple URLs to pictures (and users trying to view them, of course) .

Specifically in this case, links to commons.wikimedia.org, when put on line by itself, should show the image (and other metadata like filename). And they do while editing in preview pane, and (it seems) for a few seconds after the post is submitted, but after several seconds most of the links lose images.

Where on the platform does it happen?

in such post with multiple images being displayed. Here is an example post where it happens:

How do we replicate the issue?

  1. create a post
  2. put an URL by itself on the line containing some wikimedia commons URL like https://commons.wikimedia.org/wiki/File:Memorial_da_F%C3%A9_(Graffiti)_-_Kobra_02.jpg
  3. repeat step 2. several times (I did 11 times) for different pictures
  4. notice that all pictures are shown in editor preview pane
  5. submit post
  6. notice that in submitted post, many URLs lack pictures and contain only filename instead
  7. try refreshing, opening in other browser etc - the images are still missing
  8. click edit icon
  9. notice that all images are shown again in preview pane

Expected behavior (i.e. solution)

All images should be shown even after the post is submitted.

Other Comments

2 Likes

I’ve encountered this issue on numerous occasions. For the most part, I’ve been employing a workaround of linking instead to the same image on the OSM Wiki (which automatically fetches images from Commons). I don’t know why the OSM Wiki is able to display the images more reliably than its source, but it’s an interesting data point.

1 Like

Yep, just came up with the same issue. Tried adding just two links to Wikimedia commons images. Both images showed in the preview but only one showed when posted.

My workaround was to save the one that didn’t show and then upload separately as an image.

Is it any better now that we are running Discourse 3.1?

Is it any better now

Doesn’t seem to be better for me :cry: - e.g. that graffiti post example from the initial post in this thread still only renders some pictures (even if I clear cache / open it in another browser etc).

I’ve clicked on re-build html for that post, since the previews are created at posting. The previews look better now, right?

A workaround is to edit an old message with incorrect previews and save it, so the previews can be recreated.

2 Likes

Yes, looks fixed now!

A problem with that idea is that such older messages can no longer be edited my the poster (at least, that specific message of mine can no longer be edited my me - even editing icon is missing).

I guess there is no easy way to re-generate previews for all messages with inline images automatically?

Maybe there is, but it might be a huge processing task to do for all posts. How many do require this? I might be able to do that manually for you.

Of course. I hoped more for a chance that only articles actually having inline images would be re-processed.
But I have no idea how hard it is to find (e.g. selecting with multiline regex ^(https?|File): ?)

I do not know, but many (if not every) posts which had more than 1 image that I encountered in the past had this problem (those with only 1 image IIRC worked fine, at least in most cases). But if it is too complicated, I understand it’s likely not worth a trouble. :man_shrugging:

Right now we don’t have the means to re-create everything, so if someone else encounters this problem, it can request admins to re-do the html for a specific post.

Cheers.

I’ve just noticed a fresh post (9 hours old at the moment), where image is not rendered in Discourse. Force-refreshing or trying other browser does not help either; but the linked commons image opens normally when clicked on. It is in the middle of this post: Clarification about the use of Key:brewery - #4 by osmuser63783

Can you @nukeador tell if that is the same problem, or a new one?

That’s an artifact of how Commons hosts images. Namely, the URL in question:

https://commons.wikimedia.org/wiki/File:Halensee_Joachim-Friedrich-Stra%C3%9Fe_Cumulus_01.jpg

does not denote a JPG image; it’s actually a HTML page containing the desired image. To link to an actual image, one has to select one of image previews, linked in fine print immediately below the image, such as

https://upload.wikimedia.org/wikipedia/commons/thumb/1/1a/Halensee_Joachim-Friedrich-Stra%C3%9Fe_Cumulus_01.jpg/800px-Halensee_Joachim-Friedrich-Stra%C3%9Fe_Cumulus_01.jpg
…which can be embedded as an image:


Since most users aren’t aware of the gotcha, it would be beneficial to automatically embed one of the “previews”, but I don’t know if we can solve it on an infrastructural level.

Not quite. Have a look at this post:

Here the post shows a preview of the HTML page, and the preview contains the image. I actually prefer this approach to embedding the image directly because it shows where the image is from.

I checked both posts to see what the difference is.

https://commons.wikimedia.org/wiki/File:Selce_(35285386320).jpg


https://commons.m.wikimedia.org/wiki/File:Selce_(35285386320).jpg

So that’s it! The mobile link (commons.m.wikimedia) doesn’t work, the desktop link generates a preview.

That’s a separate issue to the one above.

3 Likes

Moreover, directly hotlinking the image usually violates the image’s license, whereas embedding the page preview would be more defensible, and the raw image URL isn’t stable.

2 Likes