Intermittent rendering of URL to images in Discourse?

[Matija_Nalis]

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:

Difference between graffiti and mural

I find this discussion quite interesting, and would like to thank to everybody who is participating. To get a better understanding, I’d like to show you 12 numbered pictures, and would appreciate if you would give a response whether you consider it “graffiti”, “mural” or “neither” (also add optional comments if you’d like to explain why in cases when it is not clear!). 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12.

• Here is how it looks during editing (all 12 images are visible in preview pane):
  

  

• and here is how it looks after the post is submitted: (only some of images show, majority do not):
  

  

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

[Minh_Nguyen (Minh Nguyễn)]

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.

[Casey_boy]

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.

[nukeador (Rubén Martín)]

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

[Matija_Nalis]

Is it any better now

Doesn’t seem to be better for me - 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).

[nukeador (Rubén Martín)]

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.

[Matija_Nalis]

@nukeador

The previews look better now, right?

Yes, looks fixed now!

@nukeador

A workaround is to edit an old message with incorrect previews and save it

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?

[nukeador (Rubén Martín)]

@Matija_Nalis

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.

[Matija_Nalis]

@nukeador

might be a huge processing task to do for all posts

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): ?)

@nukeador

How many do require this? I might be able to do that manually for you.

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.

[nukeador (Rubén Martín)]

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.

[Matija_Nalis]

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?

[Duja]

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.

[osmuser63783]

Not quite. Have a look at this post:

Clarification on the mapping of bathing places

I’ve never seen marked lanes in the sea but I have seen areas for swimming that are marked by a rope, buoys or some other barrier. Here is an example, this is what I understand leisure=swimming_area to be: I haven’t seen this in the UK either but in tourist resorts in the Mediterranean, and in lakes elsewhere. Swimming outside the marked area is often forbidden or discouraged as there may be algae, jet skiers or other hazards. I don’t think that’s the same as an open-air seawater swimming …

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.

File:Selce (35285386320).jpg

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.

[Minh_Nguyen (Minh Nguyễn)]

@osmuser63783

I actually prefer this approach to embedding the image directly because it shows where the image is from.

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.

Improve/increase size of inline images

Wikimedia wikis, including Wikimedia Commons, require contributors to agree that a hyperlink is sufficient attribution. However, you can of course provide more explicit attribution as a courtesy. I would recommend continuing to link to the file description page rather than the raw image. The raw image URL is not a permalink: it will break (becoming unreachable) if someone uploads a new revision, for example to perform a touchup or correct metadata. Commons also has a system for tracking images…