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:
Here is how it looks during editing (all 12 images are visible in preview pane):
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
repeat step 2. several times (I did 11 times) for different pictures
notice that all pictures are shown in editor preview pane
submit post
notice that in submitted post, many URLs lack pictures and contain only filename instead
try refreshing, opening in other browser etc - the images are still missing
click edit icon
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.
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.
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.
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).
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?
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.
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.
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?
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.
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.
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.