Page MenuHomePhabricator

og:image URL refers to full-size thumbnail version of original instead the original
Closed, ResolvedPublicBUG REPORT

Description

Steps to replicate the issue (include links if applicable):

  • Send a link to a file, or an article with a PageImage, on Discord
    • for example, https://commons.wikimedia.org/wiki/File:Accordion2.png

What happens?:

image.png (362×370 px, 18 KB)

Discord makes a request to https://images-ext-1.discordapp.net/external/_BYI8LzaVlCsouEstKryot7azEN6V-7oQBhV2vnJNK4/https/upload.wikimedia.org/wikipedia/commons/thumb/f/fa/Accordion2.png/912px-Accordion2.png?format=webp&quality=lossless&width=213&height=300

What should have happened instead?:
The thumbnail should display.

Software version (on Special:Version page; skip for WMF-hosted wikis like Wikipedia):

Other information (browser name/version, screenshots, etc.):

Event Timeline

This started happening within the last month or so. It doesn't happen for every request for every thumbnail, but seems to be more likely after the first request. Discord uses Google Cloud IPs most of the time.

<meta property="og:image" content="https://upload.wikimedia.org/wikipedia/commons/thumb/f/fa/Accordion2.png/912px-Accordion2.png">

The ogp.me tag is listing the thumbnail variant of the fullsize, instead of the fullsize

TheDJ renamed this task from High rate of broken thumbnails on Discord embeds of links to Wikimedia sites to OGP lists thumbnail version of fullsize instead the fullsize version itself.Jan 26 2026, 11:03 PM
TheDJ renamed this task from OGP lists thumbnail version of fullsize instead the fullsize version itself to OGP lists fullsize thumbnail version of original instead the original itself.Jan 26 2026, 11:11 PM

The ogp.me tag is listing the thumbnail variant of the fullsize, instead of the fullsize

I'm not sure I would consider this a bug. Not all of our images are web-safe (TIFFs for example), so the fullsize thumbnail is necessary for compatibility.

The ogp.me tag is listing the thumbnail variant of the fullsize, instead of the fullsize

I'm not sure I would consider this a bug. Not all of our images are web-safe (TIFFs for example), so the fullsize thumbnail is necessary for compatibility.

The media handler class should take care of that. Png is certainly websafe. So it would be a bug in this particular case.

It does a straight $file->transform(), which indeed has this effect of creating a thumbnail according to the specified instructions. There are other entrypoints that should apply the correct logic before deciding to do a transform. Not sure which is the most appropriate one of the top of my head.

Change #1235542 had a related patch set uploaded (by Func; author: Func):

[mediawiki/core@master] [WIP] Move handling of ThumbnailSteps to TransformationalImageHandler

https://gerrit.wikimedia.org/r/1235542

It's very unfortunate that the original patch for T360589 got merged, the test cases are so broken and assert the wrong behaviour. And the unchanged size was used for the actual scaling, so now we have thumbs smaller than the claimed size in the production storage.

Edit: thumbs via 404 transform are not affected.

Change #1235544 had a related patch set uploaded (by Func; author: Func):

[mediawiki/core@master] ThumbnailImage: Store physical width for the PageImages extension

https://gerrit.wikimedia.org/r/1235544

Change #1235545 had a related patch set uploaded (by Func; author: Func):

[mediawiki/extensions/PageImages@master] Use the physical size of the image for Open Graph tags

https://gerrit.wikimedia.org/r/1235545

Change #1235542 merged by jenkins-bot:

[mediawiki/core@master] Move handling of ThumbnailSteps to media handlers

https://gerrit.wikimedia.org/r/1235542

Krinkle renamed this task from OGP lists fullsize thumbnail version of original instead the original itself to og:image URL refers to full-size thumbnail version of original instead the original.Feb 12 2026, 6:36 PM

It should be fixed now linking to the originals instead. Can someone confirm this?

TheDJ claimed this task.

confirmed fixed

Change #1249927 had a related patch set uploaded (by Neriah; author: Func):

[mediawiki/core@REL1_45] Move handling of ThumbnailSteps to media handlers

https://gerrit.wikimedia.org/r/1249927

03:28 < Neriah63> [12:25:40] <Neriah63> Hi
03:28 < Neriah63> [12:25:42] <Neriah63> https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1235542
03:28 < Neriah63> [12:25:49] <Neriah63> I would think this also requires a change in 1.43/1.44/1.45. Am I mistaken?
03:28 < Neriah63> [12:25:59] <Neriah63> It forced us to add handling in common.js for images that are not handled at 
                  the server level, and because of that it takes 2 seconds for those images to load...
[..]
03:33 < bawolff> Is this causing problems for people using instant commons? Because otherwise it doesn't seem that 
                 critical to backport as most people aren't using $wgThumbnailSteps for local uploads
03:35 < Neriah63> Yes, we have the problem for instant commons.

So maybe this needs backporting.

Change #1249953 had a related patch set uploaded (by Neriah; author: Func):

[mediawiki/core@REL1_44] Move handling of ThumbnailSteps to media handlers

https://gerrit.wikimedia.org/r/1249953

Change #1251297 had a related patch set uploaded (by Func; author: Func):

[mediawiki/core@REL1_43] Move handling of ThumbnailSteps to media handlers

https://gerrit.wikimedia.org/r/1251297

Change #1249953 merged by jenkins-bot:

[mediawiki/core@REL1_44] Move handling of ThumbnailSteps to media handlers

https://gerrit.wikimedia.org/r/1249953

Change #1249927 merged by jenkins-bot:

[mediawiki/core@REL1_45] Move handling of ThumbnailSteps to media handlers

https://gerrit.wikimedia.org/r/1249927

Change #1251297 merged by jenkins-bot:

[mediawiki/core@REL1_43] Move handling of ThumbnailSteps to media handlers

https://gerrit.wikimedia.org/r/1251297