Testing images copied automatically

Photographing Yosemite (Unsplash).jpg

File:Photographing_Yosemite_(Unsplash).jpg (19 October 2015) by Luke Pamer luke_pamer, CC-Zero.

English: Yosemite National Park, United States

We began with introducing the Article/Discussion tabs at the top of the page.

Wikipedia and Alex Hollender – Licensed CC BY-SA 3.0
Wikipedia/Alex Hollender – Licensed CC BY-SA 3.0
1 Like

The post above has fragments of the same source HTML than New advanced mobile contribution features coming to mobile

Now I am going to upload the same images manually:

And now I am going to paste the HTML to call the images, stripping out the rest:

<img src="https://space.wmflabs.org/wp-content/uploads/2019/07/AMC_-_Talk_page_UI_-_initial.png" alt="" class="wp-image-359" width="297" height="232"/>

<img src="https://space.wmflabs.org/wp-content/uploads/2019/07/Advanced_mobile_contribution_features_as_of_June_2019.png" alt="" class="wp-image-354"/>

Last attempt stripping as much as possible:

Actually, let me just paste the URLs and see what happens:



I give up. Reporting upstream:


… and upstream it works. The images do render.

I’ll go to sleep hoping to find an answer tomorrow morning. :zzz:

1 Like

The mystery continues. Discourse dev cannot reproduce the problem.

@Ckoerner are these two images by “Wikipedia and Alex Hollender” available in Commons? I wonder whether it would make a difference to have exactly the same files in Commons, and link to them in the blog post, instead of WordPress’ media gallery. This test might help narrowing the problem.

@Ckoerner, I have reviewed all the topics created by the blog, and the pattern is clear: images pointing to Commons render, images pointing to WordPress’ media library don’t render. Can it be something related with the permissions of the directory where these images are stored?

Chris, never mind. Silly me I forgot that from other Discourse instances they are copying those images from WordPress’ media library just fine.

I really don’t know what can be the cause, considering that images in Commons are being copied locally just fine. It seems to be a special condition of space vs discuss-space. I wonder if this is some kind of WikimediaCloud-ism. And I wonder how to debug this, where to look for a logged error.

Meanwhile… can we use Commons images as much as possible, please?


<img src="https://space.wmflabs.org/wp-content/uploads/2019/07/CC0_button.svg_.png"/>

@ELappen_WMF @CKoerner_WMF I’m giving up. I ran the same test at https://discourse-mediawiki.wmflabs.org and got the same problem. Upstream doesn’t know what to say. I take this as a WMCS-ism interfering somewhere in the background.

The (interim?) solution is to disable this setting (which I already did):

download remote images to local - Convert remote images to local images by downloading them; this prevents broken images.

This means that now images from our Blog will be displayed… as long as the URLs stay. This means no problem during the pilot phase, but when we move the Blog to production, the URLs of the images will change.

Bottom line: let’s use Commons images as much as possible. It is a good principle anyway.

ehm… i think i see all the images now… ???

Sorry @qgil-WMF I didn’t see the pings until today. I agree we’d like to recommend using media from Commons whenever possible. The Embed Wikimedia plugin for the blog seems to handle this well and @Samwilson has been very responsive in helping make the plugin work seamlessly with the editorial process. I’m also drafting some documentation on how to add media that favors embedding from Commons than embedding in the blog.

1 Like

Yes, because of the configuration changed. Now the images are being displayed from their remote locations. Discourse is not trying to copy them locally anymore.

A post was split to a new topic: Improving image credit and footer in Space

I think I have fixed HTTPS enforcement (https://phabricator.wikimedia.org/T228138)

I have enabled download remote images to local again. Let’s see if it works now:

1 Like

It works! Finally. :tada:

1 Like