Change 828553 had a related patch set uploaded (by Matthias Mullie; author: Matthias Mullie):

[mediawiki/core@master] Introduce SearchResultThumbnailProvider & move hook + NS_FILE thumbs in there

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

Change 828556 had a related patch set uploaded (by Matthias Mullie; author: Matthias Mullie):

[mediawiki/extensions/PageImages@master] Drop some code that now lives in core

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

Notes about current implementation & differences with acceptance criteria:

This thumbnails are for desktop only and not mobile

Article thumbnails will also be shown on mobile, per T306883#8192742

All article namespace will have thumbnails

This is a little more nuanced and varies per wiki.
The namespaces for which thumbnails are generated are configured in PageImages.
On some wikis this includes a few additional namespaces; e.g.: Commons (also Category)
It's also possible that there are wikis where the main namespace is not configured to generate thumbnails, or where the PageImages extension is not available; e.g. wikibooks & wikisource.
For pretty much all other wikis, though, this simply defaults to the main namespace.
See T307034#7938839

AFAICT, this also applies to the new go bar autocomplete thumbnails.
There is no code handling that discriminates how namespaces are handled.
They've turned thumbnails off completely on Commons & officewiki, but all other wikis either show thumbnails when they have them, or a placeholder image if there's none (even for namespaces for which no image is ever generated)

We could narrow it down to only NS_MAIN thumbnails if we explicitly don't want thumbnails for any other namespace (even if enabled via PageImages)
This is not currently the case (because I think it could be useful for some specific cases, e.g. Categories on Commons, or Lexemes/Properties on Wikidata), but LMK if that needs to change and we explicitly only want NS_MAIN to show thumbnails.

For namespaces that already have thumbnails like files, leave the design and behaviour as is. No change required

While not impossible to *not* change the existing thumbnails for NS_FILE results, it would be a lot simpler (and more consistent) if we make the exact same changes.
Differences, AFAICT:

• the new thumbnails seem to be ~90px in size, compared to the current 120px
• there's a bit more padding between thumbnail and search result text
• instead of being entirely contained within a 120px bounded box, the new thumbnails fill the available space, and are positioned up top
• the thumbnails gain a 1px solid #C8CCD1 border

Right now, these changes have also been applied to NS_FILE results.
From a dev-perspective, being able to use the same code throughout is much prefered, but if we do not want any of these changes, let me know which to special-case for NS_FILE results and I'll see what I can do!

Articles that do not have thumbnails will have a placeholder image

As described above, this too is not limited to NS_MAIN pages, but "pages for which the namespace has been configured to generate thumbnails, as per PageImages config."
As per above: LMK if that needs to change.

Examen the handling of NSFW/explicit images used in the Go bar and determine if that solution works here and is appropriate

This will be covered in T306246

Determine how to display thumbnails for results in other language wikis

I can't trigger this on my machine, but it appears that no thumbnails (for files) are currently being shown for cross-wiki results.
Given that there is no prior expectation that cross-wiki results would have thumbnails, and that an actual implementation could be very prone to error (e.g. what in the case of images with the same name on both wikis or on Commons), I decided to stick with that.
Let's open a new ticket if we ever want to reconsider.

Give the thumbnail a specific CSS class that they can target and hide

I've added 2 classes:

• mw-search-result-ns-<id> on the div containing the full result (where <id> is the numeric id of the namespace the result is from; e.g. 0 for main namespace, 6 for file)
• searchResultImage-thumbnail on the table cell containing the image/placeholder

This way, they could target thumbnails entirely, or only for specific namespaces.

In T306883#8201274, @Sneha wrote:

In that case we can make all thumbnails (article/files) follow the same design on Desktop. And leave mobile as is?

Yes and no.
Changes on desktop are going to affect mobile's existing thumbnails either way, unless we explicitly treat them differently.
Dealing with multiple separate implementations is far more complex & brittle than trying to figure out 1 solution that works for both/all cases (even more so in a community that also builds things on top of what we produce - they too rely on some consistency)

When we say "mobile", we're basically talking about a specific skin, one that (simplified) essentially receives a bunch of data from other parts of the code and adds some other chrome and CSS on top of it.
The code that produces that data is usually not even aware of such details, nor should it be: it needs to work in all cases (because we have had other skins in the past, have multiple ATM, and might have more in the future)
Some changes can quite easily be done within the skin (e.g. simple CSS tweaks), while others are much harder to do (e.g. there's a lot of legacy on how thumbnails (or thumbnail-like things, like an audio player) are rendered, some of which spread across multiple extensions...)
Either way, the less consistent things are, the more work.
t's not as simple as "leave them alone" - I am actively making changes to that code for the desktop.
Either mobile also gets them (and I have to make sure things continue to look well enough there), or I do extra work to try to figure out a way to make mobile continue to look like what it did before.

As I described in above mail (I hadn't seen this comment until now) - with the current patches, mobile will be undergoing the same thumbnails treatment as desktop:

• they will also get thumbnails & placeholders for namespaces for which thumbnails can be provided (NS_MAIN for most wikis)
• the changes to thumbnails (90px, extra padding, top fill, border) will also be applied (to both new thumbnails & existing NS_FILE thumbnails)

If we plan for this to go to mobile eventually, we can just keep what we already have now.
If we will not want article thumbnails there, it would be relatively easy to just hide them with CSS from within the mobile skin (using the 2 new classes)
If we will not want the changes to how thumbnails are displayed... I'm not sure how I'd accomplish that yet, would need to look into it :p

LMK which of the above we do/do not want!

@matthiasmullie thanks for all this explanation - everything makes sense to me, I look forward to seeing if @Sneha is okay with it too.

The only concern I have is that I think we didn't want to add more thumbnails for mobile because of performance/data consumption concerns. Does showing thumbnails for the article namespace on mobile add significant data needs for mobile users? If so, does hiding them in CSS fix that?

@matthiasmullie So from what I understand it is easier to have thumbnail be available everywhere but if we don't want to show on mobile we can hide them with CSS. I think we should hide on mobile.

There are a few reasons we don't want to show thumbnails on mobile for article namespaces 1) We want to keep mobile light weight in terms of data consumption since in some countries it may take a long time to load with images 2) Current layout on mobile is not designed to show thumbnails and adding them will cause alignment issues. If we plan to show thumbnails on mobile later we will need to adjust the layout.

Since file namespace already has thumbnails we don't need to hide it there and it can follow the new treatment. However we should hide it on the article namespace on mobile skin. We can decide to show them in mobile later if we want. Does that work?

Does showing thumbnails for the article namespace on mobile add significant data needs for mobile users? If so, does hiding them in CSS fix that?
We want to keep mobile light weight in terms of data consumption since in some countries it may take a long time to load with images

Hiding them with CSS may or may not prevent them from loading (browsers have some optimizations to prevent loading of images not visible, but "it depends"), but they don't load until the rest of the page is already available anyway, so it should have no impact on the speed at which they're able to see and interact with the page, nor on how it looks (even if the browser continues fetching thumbnails in the background - they still wouldn't be displayed)

Okay then speed is not a concern. However if the images load on mobile (for some reason we can't control) it is not going to be the best browsing experience and layout is going to be wonky. Can we say with confidence that most users won't see it on mobile?

Users will not see them in the mobile skin.
Even if a browser does fetch them, it will have no affect (other than a few additional redundant requests to our servers), they will never see them.
It will not slow things down or affect their experience.

Change 829191 had a related patch set uploaded (by Matthias Mullie; author: Matthias Mullie):

[mediawiki/skins/MinervaNeue@master] Don't show thumbnails for non-NS_FILE results on Special:Search

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

Change 828554 merged by jenkins-bot:

[mediawiki/extensions/PageImages@master] Allow thumbnails to be provided in a different size

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

Change 828551 merged by jenkins-bot:

[mediawiki/core@master] Move SearchResultProvideThumbnail hook to 'search'

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

Change 828555 merged by jenkins-bot:

[mediawiki/extensions/PageImages@master] Update hook FQCN

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

Change 829191 merged by jenkins-bot:

[mediawiki/skins/MinervaNeue@master] Don't show thumbnails for non-NS_FILE results on Special:Search

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

Change 828553 merged by Cparle:

[mediawiki/core@master] Introduce SearchResultThumbnailProvider & move hook + NS_FILE thumbs in

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

Change 828556 merged by jenkins-bot:

[mediawiki/extensions/PageImages@master] Drop some code that now lives in core

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

Change 837731 had a related patch set uploaded (by Matthias Mullie; author: Matthias Mullie):

[operations/mediawiki-config@master] Show thumbnails on Special:Search for NS_FILE + PageImages

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

In T306883#8279227, @gerritbot wrote:

Change 828553 merged by Cparle:

[mediawiki/core@master] Introduce SearchResultThumbnailProvider & move hook + NS_FILE thumbs in

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

Tested on enwiki betalabs

• different file types
• different file sizes (esp small files)
• different width/height ratios
• testing the above on mobile and desktop

All look good (will check, of course, in production). There is only couple of edge cases that I filed as QA task T319230 to verify in production (I need more variety of files to test).

Change 837731 merged by jenkins-bot:

[operations/mediawiki-config@master] [beta] Show thumbnails on Special:Search for NS_FILE + PageImages

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

Change 839500 had a related patch set uploaded (by Matthias Mullie; author: Matthias Mullie):

[operations/mediawiki-config@master] Show thumbnails on Special:Search for NS_FILE + PageImages

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

Change 839500 merged by jenkins-bot:

[operations/mediawiki-config@master] Show thumbnails on Special:Search for NS_FILE + PageImages

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

Mentioned in SAL (#wikimedia-operations) [2022-10-06T13:13:06Z] <urbanecm@deploy1002> Started scap: Backport for [[gerrit:839500|Show thumbnails on Special:Search for NS_FILE + PageImages (T306883)]]

Mentioned in SAL (#wikimedia-operations) [2022-10-06T13:13:29Z] <urbanecm@deploy1002> urbanecm and mlitn: Backport for [[gerrit:839500|Show thumbnails on Special:Search for NS_FILE + PageImages (T306883)]] synced to the testservers: mwdebug2001.codfw.wmnet, mwdebug1001.eqiad.wmnet, mwdebug1002.eqiad.wmnet, mwdebug2002.codfw.wmnet

Mentioned in SAL (#wikimedia-operations) [2022-10-06T13:18:19Z] <urbanecm@deploy1002> Finished scap: Backport for [[gerrit:839500|Show thumbnails on Special:Search for NS_FILE + PageImages (T306883)]] (duration: 05m 12s)

Belatedly tagging this with User-notice, bit surprised such a visible design change was made with no communication...

Yes, this change caused a bit of surprise on English Wikipedia and probably should have been advertised before turning on.

In addition, I've filed two bugs against the implementation and attached them as subtasks. IMO both should have been caught in design review for this feature, so I'm concerned that neither were. What kind of design review did this feature get?

I anticipate some further feedback based on the English WP discussion; concerns to highlight include: the choice to crop (and from where the crop is centered I think moreso); the desire and preference for a preference which actually removes the image from results (loading images is resource expensive for the end user), and whether search results are including non-free imagery (see pilicense in PageImages documentation; it looks like mobile and Vector22 search bar also don't observe that API, so at least it's consistent right now). Consider reviewing the English WP discussion.

There is a bug in the implementation of this feature: the image should link to the article, not to the File: page for the image. If people are looking for images, they search in File space. Feel free to split this into a separate phab ticket if necessary.

In T306883#8301790, @Legoktm wrote:

Belatedly tagging this with User-notice, bit surprised such a visible design change was made with no communication...

Or not a lot of testing beforehand, as is more or less customary by this point. The fact that every search result is now a table is atrocious. This is why changes are done via beta features.

Basically I am happy with this surprise.

• External (anonymous) audience might benefit from some visual guidance.
• Sometimes it will be pointless, 20 green views of 20 forrests are not really helpful.

For registered users a preference to opt out/in is strongly recommended.

In any case the number of images needs to be limited urgently to the first 20 results.

• If I ask for limit=500 I receive 500 images. Nobody will need that to understand search results.

Loading in background on mobile of invisible images will consume contingented or expensive volume and terminate this month a week earlier.

• If still loading 100 invisible images with slow connection then simultaneous activity in other browser tab will be stopped until all invisible images have been loaded.
• This is a bad idea, mobile needs to be excluded immediately.

I don't believe that limiting it to the first 20 search results makes sense. If I have 500 search results and want to find the right one, images can be helpful to find the right one.

For Wikidata I would also like images for items with no image property. small logo or icon (P8972) of the class of a given item is a good source for images that are better than the current placeholder. https://commons.wikimedia.org/wiki/File:Font_Awesome_5_solid_user.svg for items about people who don't have an image look much nicer than the current placeholder. Icons that work at 16x16 as required by small logo or icon (P8972) generally make good placeholders.

If I am looking for certain villages with some criteria it does not help me to get 500 images of a church, a town hall, or the monument of a writer or painter, or a farm house.

• I did not ask for 500 images. You are patronizing.
• But this idea is consuming and wasting my bandwith, and in less networking regions my device is blocked for a minute until all these undesired images arrive without any remedy against. This is burning the money of the audience, and a sin against environmental protection.
• There are many use cases why you are searching articles, and looking at hundreds of images is not the one and only one. You may start a text search within result page. Personally I did not need any such image within 15 years at Wikipedia.

I don't find the images helpful either, and have added CSS to avoid displaying them, but I expect they still get downloaded, tying up Wikipedia's bandwidth and mine. The clinching argument may be that, because some of the images are non-free and lack fair-use rationales for their appearance in search results, showing them to me risks putting the WMF in breach of copyright law. (I am not a lawyer, this is not legal advice, laws vary by jurisdiction, etc., etc.)

It seems that they is a bug on the Wikisources.
At least on the French Wikisource, there is *never* an image displayed, even in the case where there is an image on the page.
See for instance the first result on : https://fr.wikisource.org/w/index.php?search=intitle%3A"Les+Rougon-Macquart"&title=Spécial:Recherche&profile=advanced&fulltext=1&ns0=1 (I tried to give a simple example, there is also different case where the image is inside a template, transcluded or retrieved from Wikidata).

Change 841133 had a related patch set uploaded (by Matthias Mullie; author: Matthias Mullie):

[operations/mediawiki-config@master] Explicitly set wgPageImagesNamespaces to none where disabled

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

Change 841133 abandoned by Matthias Mullie:

[operations/mediawiki-config@master] Explicitly set wgPageImagesNamespaces to none where disabled

Reason:

Superseded by https://gerrit.wikimedia.org/r/c/operations/mediawiki-config/+/841893

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

This needs to be disabled in several private wikis, including checkuser wiki where we store CU stuff, or techconductwiki.

Any updates on resolving this? Pics in search results on Wikipedias at all are clogging up the search, and using hacks to suppress the pics doesn't resolve the issue of the pics burning up my bandwidth.

On enwp, and perhaps all wikis, Preferences→Search→Show thumbnails in Special:Search can now be unticked. I don't know whether this prevents transmission of images or simply hides them.

In T306883#8349985, @Certes wrote:

On enwp, and perhaps all wikis, Preferences→Search→Show thumbnails in Special:Search can now be unticked. I don't know whether this prevents transmission of images or simply hides them.

Thanks for the information on this as I don't recall seeing that advertised on en.wiki. In regards to "I don't know whether this prevents transmission of images or simply hides them.", that's something I would like to know the answer to as well.

When opting out via that preference, no article thumbnails will be served at all.

I think too the thumbnails should link to the article, not to the file page.

Rationale: that's the behaviour the users should expect (they are used to navigate by clicking on pictures), also the article is much more relevant than the file page.
Also, the file page can easily be reached from the article, as it's basically the first picture, whereas reaching the article from the file page is much more tedious.

(this has been reported above already, though it isn't really a bug).

Re-checked the following requirements:

• Examen the handling of NSFW/explicit images used in the Go bar and determine if that solution works here and is appropriate (see T306246)

I checked all cases listed in T306246. The majority of the reported searches return now (for first 20 results) images that are not-NSIFW. However, if a search result set has articles with NSFW images, they will be displayed as thumbnails which, arguably, can be more impactful than displaying just text-based search results.
Since the NSFW images discussion has a much broader context, that, probably, doesn't quite fit this task scope.

• Determine how to display thumbnails for results in other language wikis (e.g. like in T309745)

T309745 still needs to be addressed for mobile only (https://phabricator.wikimedia.org/T309745#8273606); Desktop looks as expected.