For Vector-2022.

The image in is in MediaWiki:Badlist but has an exception to be used for this article.

So I think Badlist is working as expected here (but I am not disagreeing this is a problem).

Other solutions include:

• adding this file to https://en.m.wikipedia.org/wiki/MediaWiki:Pageimages-denylist
• adding the nopageimage class to the infobox image

In T306246#7857705, @Jdlrobson wrote:

The image in is in MediaWiki:Badlist but has an exception to be used for this article.

So I think Badlist is working as expected here (but I am not disagreeing this is a problem).

I think search results should be treated like transclusions. And bad images do not render in transclusions.

In T306246#7857712, @Jdlrobson wrote:

Other solutions include:

• adding this file to https://en.m.wikipedia.org/wiki/MediaWiki:Pageimages-denylist
• adding the nopageimage class to the infobox image

It's good to think about possible ways to approach this, but this isn't much of a long-term solution. Adding to MediaWiki:Pageimages-denylist means copying MediaWiki:Bad_image_list there. Also, I've tried it but I see no effect. Maybe cache issue, will try again in an hour or so. nopageimage class would be unworkable, you'd need a bot to insert it everywhere and also have that bot go to edit war with users who remove it because they don't know what it does or just remove it accidentally.

This problem also occurs in the Wikipedia App (tested with the WMF iOS app). That is, typing "ana" to search in the app shows the image. A robust low-level solution is needed so MediaWiki:Bad_image_list images are never displayed except at the appropriate article.

It's been a few hours. MediaWiki:Pageimages-denylist didn't seem to do anything. The nopageimage class seems to work, but I have to test if it was the div or the class that did the job. Regardless, that solution is unworkable for this purpose. The search should never render an image that's listed on MediaWiki:Bad_image_list. Files are on the bad image list because they can be disruptive in an unforeseen context. Search results are an unforeseen context.

For reference btw, I created this task in response to a VPT thread. I also filed T306286 as an alternative to using thumbnails at all.

The image was never added to https://en.wikipedia.org/wiki/MediaWiki:Pageimages-denylist. Once it is, per https://www.mediawiki.org/wiki/Extension:PageImages#Can_I_exclude_certain_page_images?, you will need to change a link on the article to force it to refresh the page image. Purging isn't enough.

EDIT: I see that you made the changes on a test wiki. Did you change a link on the page after making that change?

@Ahecht is correct. @AlexisJazz I don't see any edits to [[en:MediaWiki:Pageimages-denylist]]. However, this page is primarily for common page images that span multiple articles due to the inclusion of a template. Presumably, you want to try the notpageimage method, which was made exactly to solve this problem, but I also don't see any edits to the offending article. Are you testing locally or on a different wiki?

Unless I'm mistaken this particular problem relates to one article (only that article uses this page image according to File usage on other wikis) and can be fixed with on edit. Why is that unworkable and not a long-term solution? Why does this need a bot? Search is behaving as expected here. PageImages has its own filtering mechanisms, and I think it would be overly complex for search results to apply two types of deny list here.

After reviewing the code for both pageimages and MobileFrontend, it looks like the easiest solution is just to transclude {{MediaWiki:Bad image list}} into MediaWiki:Pageimages-denylist on Wikis where it is desirable to have the former blocked from search results. No need for manually copying one over to the other, no need for a bot. I don't have access to test this, but from the source code it should work.

In T306246#7862294, @Ahecht wrote:

The image was never added to https://en.wikipedia.org/wiki/MediaWiki:Pageimages-denylist. Once it is, per https://www.mediawiki.org/wiki/Extension:PageImages#Can_I_exclude_certain_page_images?, you will need to change a link on the article to force it to refresh the page image. Purging isn't enough.

EDIT: I see that you made the changes on a test wiki. Did you change a link on the page after making that change?

No, I didn't know that. I tried it now: https://commons.wikimedia.beta.wmflabs.org/w/index.php?title=Main_Page&diff=277845&oldid=277844 (after https://commons.wikimedia.beta.wmflabs.org/w/index.php?title=MediaWiki:Pageimages-denylist&diff=277842&oldid=277771) but I still see the image in the ajax search.

In T306246#7862382, @Jdlrobson wrote:

@Ahecht is correct. @AlexisJazz I don't see any edits to [[en:MediaWiki:Pageimages-denylist]]. However, this page is primarily for common page images that span multiple articles due to the inclusion of a template. Presumably, you want to try the notpageimage method, which was made exactly to solve this problem, but I also don't see any edits to the offending article. Are you testing locally or on a different wiki?

I'm an interface admin on Betacommons, so that's where I test.

Unless I'm mistaken this particular problem relates to one article (only that article uses this page image according to File usage on other wikis) and can be fixed with on edit. Why is that unworkable and not a long-term solution? Why does this need a bot? Search is behaving as expected here. PageImages has its own filtering mechanisms, and I think it would be overly complex for search results to apply two types of deny list here.

You are mistaken. If you spot one rotten apple full of worms, the whole batch is fodder.

• Enter "genit" for a genital piercing.
• Enter "apad" for the evolved version of Prince Albert.
• Enter "autof" for a guy sucking his own cock. Let's hope the article on autofocus isn't too popular with children.
• Enter "clit" for various clitoris images. Let's hope the children who live in Clitheroe aren't too interested in reading about their town.
• Enter "christina p" for another clitoris image.
• Enter "dyd" for a cock piercing

Don't even think about saying "so it's 7 pages" or something like that. All of MediaWiki:Bad_image_list is bad.

In T306246#7862851, @Ahecht wrote:

After reviewing the code for both pageimages and MobileFrontend, it looks like the easiest solution is just to transclude {{MediaWiki:Bad image list}} into MediaWiki:Pageimages-denylist on Wikis where it is desirable to have the former blocked from search results. No need for manually copying one over to the other, no need for a bot. I don't have access to test this, but from the source code it should work.

MediaWiki:Pageimages-denylist just doesn't seem to work at all for this purpose. Until we can figure out if/how that's supposed to work, we can't test if transclusion works. If that would work, that would be acceptable.

In T306246#7862924, @AlexisJazz wrote:

MediaWiki:Pageimages-denylist just doesn't seem to work at all for this purpose. Until we can figure out if/how that's supposed to work, we can't test if transclusion works. If that would work, that would be acceptable.

That might be a configuration issue with the test wiki, as it works fine on enwiki (you can play around with this page).

Please also read the format https://www.mediawiki.org/wiki/Extension:PageImages#Configuration

You are mistaken. If you spot one rotten apple full of worms, the whole batch is fodder.

Yes but that's an editorial concern. A bot is not going to know which ones are inappropriate and which are not (and Wikipedia is not censored), thus a human needs to decide which articles have inappropriate page images and remove them on a case-by-case basis. Perhaps a bot would be useful for syncing the contents of [[MediaWiki:Bad_image_list]] and [[MediaWiki:Pageimages-denylist]] for now.

In terms of long term, the only actionable suggestion I could see here is making PageImages consider [[MediaWiki:Bad_image_list]] as well as or instead of the [[MediaWiki:Pageimages-denylist]]. I'm not sure if there is a good reason why it maintains its own list and what the downsides/benefits of them both using that list would be. Perhaps there was a reason a dedicated list ([[MediaWiki:Pageimages-denylist]] ) was used instead (none of the current maintainers were around when that decision was made).

In T306246#7864393, @Jdlrobson wrote:

Please also read the format https://www.mediawiki.org/wiki/Extension:PageImages#Configuration

From what I've seen in the code, the format is irrelevant. It does a DB query of all links from that page that are to the file namespace. As long as they are linked (and are actual links, not the image being displayed), they will be excluded. Since it works properly on enwiki, I suspect this is a configuration issue with https://commons.wikimedia.beta.wmflabs.org. Maybe it's querying https://commons.wikimedia.org/wiki/MediaWiki:Pageimages-denylist?

PageImages probably needs MediaWiki:Pageimages-denylist to exclude some images that are fine for their purpose but not useful for PageImages. However, PageImages should also exclude items at MediaWiki:Bad_image_list. A picture of anal sex is fine at an article about that topic but there is no encyclopedic value in showing it when searching.

In T306246#7864393, @Jdlrobson wrote:

Please also read the format https://www.mediawiki.org/wiki/Extension:PageImages#Configuration

You are mistaken. If you spot one rotten apple full of worms, the whole batch is fodder.

Yes but that's an editorial concern. A bot is not going to know which ones are inappropriate and which are not (and Wikipedia is not censored), thus a human needs to decide which articles have inappropriate page images and remove them on a case-by-case basis.

It is very simple: if the image is on MediaWiki:Bad_image_list it's not appropriate. No editorial concerns here. "Wikipedia is not censored" does not apply here, I'm not saying anything about article content. If you actually view the article about anal sex, you should see an illustration. But not when you are searching for something unrelated.

Perhaps a bot would be useful for syncing the contents of [[MediaWiki:Bad_image_list]] and [[MediaWiki:Pageimages-denylist]] for now.

If @Ahecht is right and transclusion works, we can transclude Bad_image_list on Pageimages-denylist for now.

In terms of long term, the only actionable suggestion I could see here is making PageImages consider [[MediaWiki:Bad_image_list]] as well as or instead of the [[MediaWiki:Pageimages-denylist]]. I'm not sure if there is a good reason why it maintains its own list and what the downsides/benefits of them both using that list would be. Perhaps there was a reason a dedicated list ([[MediaWiki:Pageimages-denylist]] ) was used instead (none of the current maintainers were around when that decision was made).

I see the difference in functionality, bad_image_list prevents adding the image inline in articles other than listed exceptions, denylist prevents PageImages from considering it, but I doubt there's much of a use case for having both.

I see File:Ambox_important.svg is on the denylist on enwiki. Transclusion of Ambox_important.svg should never be hindered and I'm guessing PageImages at some point picked Ambox_important.svg as the page image sometimes when an article had cleanup tags? But in that case the class should work fine.

If anything, MediaWiki:Bad_image_list is essentially a subset of MediaWiki:Pageimages-denylist.

I fully concur with AlexisJazz and Ahecht here. This has a clear issue to resolve: make the search results ignore the bad image list. The possible bad outcomes are really bad—@Jdlrobson, can we note that this is a blocking issue for the deployment of New Vector?

From my reading of this ticket, it seems that transcluding {{MediaWiki:Bad image list}} into MediaWiki:Pageimages-denylist could be the easiest solution here, as @Ahecht suggests.

@AlexisJazz when you say MediaWiki:Pageimages-denylist just doesn't seem to work at all, do you mean that in the context of looking at: the new search results, with the new Vector 2022 skin, on betacommons? The reason for that may be that thumbnails for the new search are disabled on commons, and betacommons inherits that configuration. https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/refs/heads/master/wmf-config/InitialiseSettings.php#7969

'wgVectorWvuiSearchOptions' => [
	'default' => [
		'showThumbnail' => true,
		'showDescription' => true,
	],
	'+frwiktionary' => [
		'showDescription' => false,
	],
	'officewiki' => [
		'showThumbnail' => false,
		'showDescription' => false,
	],
	'commonswiki' => [
		'showThumbnail' => false,
		'showDescription' => false,
	],
],

Outside of those wikis, the proposed solution should be visible on the new search. It can be tested elsewhere like beta-enwiki for example.

In T306246#7878200, @Jdrewniak wrote:

From my reading of this ticket, it seems that transcluding {{MediaWiki:Bad image list}} into MediaWiki:Pageimages-denylist could be the easiest solution here, as @Ahecht suggests.

@AlexisJazz when you say MediaWiki:Pageimages-denylist just doesn't seem to work at all, do you mean that in the context of looking at: the new search results, with the new Vector 2022 skin, on betacommons? The reason for that may be that thumbnails for the new search are disabled on commons, and betacommons inherits that configuration. https://gerrit.wikimedia.org/r/plugins/gitiles/operations/mediawiki-config/+/refs/heads/master/wmf-config/InitialiseSettings.php#7969

'wgVectorWvuiSearchOptions' => [
	'default' => [
		'showThumbnail' => true,
		'showDescription' => true,
	],
	'+frwiktionary' => [
		'showDescription' => false,
	],
	'officewiki' => [
		'showThumbnail' => false,
		'showDescription' => false,
	],
	'commonswiki' => [
		'showThumbnail' => false,
		'showDescription' => false,
	],
],

Outside of those wikis, the proposed solution should be visible on the new search. It can be tested elsewhere like beta-enwiki for example.

Pretty sure I tested with Minerva and the "does not work" meant "still seeing the thumbnail", but thanks for making me aware vector-2022 and Minerva behave differently in this regard.

Idea: We change PageImages to take into account the badimagelist automatically and mark all images on the badimage list as "non-free"-candidates for the purpose of PageImages (Pageimages always selects a 'free' and/or a 'non-free' candidate). This means the image will not be used in lists that get used outside of the page itself.

It's a bit of a hack, but would be quite effective I think.

In T306246#7878200, @Jdrewniak wrote:

From my reading of this ticket, it seems that transcluding {{MediaWiki:Bad image list}} into MediaWiki:Pageimages-denylist could be the easiest solution here, as @Ahecht suggests.

The only caveat is that the link table won't update unless MediaWiki:pageimages-denylist is null edited or purged with the forcerecursivelinkupdate option.

In T306246#7898606, @TheDJ wrote:

Idea: We change PageImages to take into account the badimagelist automatically and mark all images on the badimage list as "non-free"-candidates for the purpose of PageImages (Pageimages always selects a 'free' and/or a 'non-free' candidate). This means the image will not be used in lists that get used outside of the page itself.

It's a bit of a hack, but would be quite effective I think.

That's not a bad idea, but it would require more coding than just adding another row to wgPageImagesDenylist at LocalSettings.php.

In T306246#7862382, @Jdlrobson wrote:

PageImages has its own filtering mechanisms, and I think it would be overly complex for search results to apply two types of deny list here.

As I'm not seeing much progress I created https://meta.wikimedia.org/wiki/Phasing_out_Pageimages-denylist. Whether this is really the right path, I'm not 100% sure. Across all projects, this will take dozens if not hundreds of hours of combined effort to wipe out all usage of denylist. I've done this before. Is it impossible? Probably not, depending on usage on other projects. Is it a good use of community time? It better be damn "overly complex" to apply two lists if this is the solution.

Trying to catch up here. What happened to the suggested solution of transcluding of MediaWiki:Bad image list on MediaWiki:Pageimages-denylist? It seems like the most reasonable way forward. It meets the English Wikipedia use case, while also giving flexibility to other projects that want to fine-tune page images with a feature-specific list.

What are the current blockers to moving forward with that?

In T306246#8008661, @ovasileva wrote:

Trying to catch up here. What happened to the suggested solution of transcluding of MediaWiki:Bad image list on MediaWiki:Pageimages-denylist? It seems like the most reasonable way forward. It meets the English Wikipedia use case, while also giving flexibility to other projects that want to fine-tune page images with a feature-specific list.

What are the current blockers to moving forward with that?

Per https://www.mediawiki.org/wiki/Topic:Wv7qxbp3jvhf9qju that is not supported

And even if it was supported, I can't imagine any reason for any project to ever want this. If anything, with a transclusion/botcopy solution every project would have to implement the exact same solution because nobody wants images from the bad image list to show up in search results.

OK. i looked into this again... First of all, i don't think we can see this is in any way relevent to the vector-2022 deploy. Don't forget that over 60% of traffic already is on mobile and has always had this experience.

Second: the badimagelist... even for the whitelisted pages themselves... are we really losing that much if we just deny these images completely ? The best I can come up with is the Hero image in the top of the apps... but that is a simple repeat.

The formats for both deny lists are exactly the same, so we can just have two denylists in pagesimages and not have the whitelist functionality work at all. That is a really simple solution for about 500ish pages that are the whitelist of the bad_image_list...

Just a simple config change

$wgPageImagesDenylist = [
	// Page on local wiki
	[
		'type' => 'db',
		'page' => 'MediaWiki:Bad_image_list',
		'db' => false,
	],

The only downside I can see is that it will cause other images that are NEXT on that page to be selected, which might be even more unexpected and more non-safe.

A step up from that is to add create a new config variable name wgPageImagesPageDenyList. This would take a page like Bad_image_list, and flip the logic to only look at pages named there which are not image (the whitelist) and have those pages entirely skipped by the algorithm, instead of scoring certain images lower.

This too would be relatively easy to implement, as its almost a copy of the pre-existing denylist logic, just worked around a bit.

@TheDJ I like that idea. The articles about anal sex/cock piercings/bukkake/etc should simply never have a pageimage.

I have a branch for this, I still need to write a few extra testcases, but hope to have a patch for review somewhere this week.

Firstly: The Bad-image-list is an anti-vandalism tool. If vandal(s) are spamming images of bunny rabbits, the Bad-image-list will contain images of bunny rabbits. Obviously you should not be sabotaging the search functionality of anyone searching for bunny rabbits. This image list also contains effectively zero-percent of our potentially offensive images. If vandals stop trying to use some particular image, that image gets removed from the list. Any vague resemblance with an "offensive image list" is an incidental mirage. Trying to use this as a content censor would be is a clear misuse of this tool. This Phab task should be immediately closed on that grounds alone.

Secondly: Deciding what content is (or is not) appropriate is a clear community content decision. Attempting to block educational community content merely because some people dislike it seriosuly oversteps the most fundamental boundaries. I don't know how many people in this discussion have community experience, but I believe @TheDJ at minimum should be aware of community policy on censorship. DJ, I believe you can reasonably predict the community reaction if the WMF attempts to deploy any sort of censorship software - especially if the WMF does so with zero consideration or consultation with the community.

Anyone who is concerned with "inappropriate" images can seek to revive the 2011 Image filter referendum for reconsideration. Spoiler alert: The final outcome is always the same, for good reasons. If it is helpful/necessary I could attempt to explain why this won't fly, but I don't want to bloat this post if it's not necessary.

P.S. This is currently listed as a "bug report". It is clearly not a bug report - this is a feature request for a hotly controversial feature.

I don't think its as hotly controversial as you make it out to be. There's a vast difference between showing potentially controversial images in context (which is what that referendum was about), where they are carefully placed and vetted by human editors, and an automated tool trying to guess what pictures it should show in popups and search results that ends up showing pictures of anal sex to kids as they are typing in the name of the city where Disneyland is located. There is no requirement that search results or popups contain images (and on desktop there have been no images in search results since the founding of Wikipedia), so no harm is done if the occasional false positive slips through, and those images of bunnies or assholes will still be present in the appropriate articles.

In T306246#8108510, @Ahecht wrote:

There is no requirement that search results or popups contain images

100% agreed, and I warned the WMF about this exact issue six years ago back in the original proposal to add images to article search results.[[ https://www.mediawiki.org/wiki/Talk:Wikimedia_Discovery | [1] ]] I said people were going to show up complaining about images in article search results. We can chose to include include images in the search results, or we can not include images in search results. But if you do add images to search results, you can't expect to censor the ones you don't like.

showing pictures of anal sex to kids

you should look up the history of the Image filter on Meta. The "think of the children" crowd, and even the "don't force individual crime victims to see photos of violent crimes" crowd, definitely lost. @WhatamIdoing (talk) 16:38, 17 March 2016 (UTC)

You have a personal and purely subjective cultural hang up about sex. Ok, fine. However it would be culturally imperialistic for us to impose your opinions of "offensiveness" on the world, while denying or denigrating the equally subjective and equally cultural and equally legitimate concerns of people demanding that Images of Muhammad be removed. And then there are the equally subjective and equally cultural and equally valid demands to censor any image of any woman-not-wearing-a-burka.

I don't have have a link at the moment, but during the Image Filter referendum we literally had people show up sincerely arguing for the burka standard, to censor any exposed female skin beyond the hands feet and eyes. The only argument for your standard above theirs, is that you think the culture in your country is superior to the culture in their country. (I may personally agree with you on that point, but attempting to impose that personal opinion upon all of our readers is a gross violation of our commitment to neutrality.)

You argue "no harm is done". However you can't simultaneously claim your censorship is obviously harmless while denying someone else's censorship as obviously harmful. I'm quite certain you'd summarily reject this Phab task, screaming about the harm, if someone tried to blank every search image containing a woman.

The Bad-image-list is based on each individual community's consensus. I'm pretty sure that the consensus in most english-speaking areas is that graphic sexual imagery is inappropriate in some contexts, which is why enwiki put those images on their bad-image-list. If fawiki found the consensus to put all images of women on their bad-image-list, then those images shouldn't show up in their search results either.

The very first point I made was that the Bad-image-list has absolutely nothing to do with images being offensive. I'll <snip> the largely duplicate explanation here. The Bad-image-list contains almost precisely zero-point-zero percent of "offensive" images.

We deliberately do not have any tools to censor images. Of the tools we currently do have, the Bad-image-list does probably come closest to kinda-sorta-vaguely looking like what you'd like to do. But that doesn't mean it's actually a proper fit for that purpose.

If today is Easter, and people are spamming the lead image of our Easter article onto talk pages or into other articles, we need to be able to put that image on the Bad-image-list. If today is Easter, you clearly did something wrong thing if you broke the Easter image on the Easter search results.

And that's independent of the fact that you are going to have angry people if you attempt to deploy censorship tool into our platform. When British Internet Watch Foundation tried to censor one of our articles for containing "child pornography", our response was to build a new article on the incident - Internet Watch Foundation and Wikipedia - and we slapped that exact image on top of the new article. There are a lot of editors eager to fight any perceived censorship.

Which images on the bad-image-list on enwiki are there because they are perfectly innocent images that are being spammed across wikipedia? The only ones I see on there are there because (a) they are inappropriate except in specific contexts or (b) they are non-free images and Wikipedia policy only allows them to appear on pages for which there is a fair-use rationale in place. Neither of those situations are images we want in search results. I've seen innocent images requested on the talk page from time to time, but those requests are almost always declined (and that sort of vandalism is typically taken care of with a block or an edit filter).

First of all, I wouldn't say anything would be censored. The images will still be there in the articles themselves.

You have a personal and purely subjective cultural hang up about sex. Ok, fine. However it would be culturally imperialistic for us to impose your opinions of "offensiveness" on the world, while denying or denigrating the equally subjective and equally cultural and equally legitimate concerns of people demanding that Images of Muhammad be removed. And then there are the equally subjective and equally cultural and equally valid demands to censor any image of any woman-not-wearing-a-burka.

Not equal. Kids are not sexually active, that's biology. If they want information about sex, we want them to ask someone they trust like a parent or in some cases a teacher. Or they could read a book about it, in fact, they could even learn about it reading Wikipedia articles. If they are not interested, we don't want to give them ideas or confuse them. Unexpectedly shoving images of anal sex in their face clashes with that.

We also don't want any nauseating imagery (gore, blood, pus, etc) to be shoved into anyone's face unexpectedly because the FSM says vomiting up your lunch is bad.

Adding to Foundational Technology Requests per discussion with Web/Design Systems teams

Web/DST sync notes

• Will submit this to Foundational Tech board for review of potential options we could take to technically solve for this.
• Ideal timeline for options: 3 weeks

• Web team to follow-up on community needs and drivers

Next steps: we will analyze possible ways of solving this by removing the images from search and provide next steps on this ticket. However, the decision on whether they should be removed lays within the community on individual projects and we would like to confirm consensus before proceeding.

In T306246#8008801, @AlexisJazz wrote:

because nobody wants images from the bad image list to show up in search results.

There are languages where bad images do not randomly show up because the writing system itself is specific enough. Case in point: the Chinese Wikipedia [and other Sinitic languages using Chinese characters]. To evoke anal sex you need to go for either 肛 "anus" or 交 "crossing, intercourse", both widely understood to return these sort of stuff.

In T306246#8109921, @Ahecht wrote:

Which images on the bad-image-list on enwiki are there because they are perfectly innocent images that are being spammed across wikipedia?

zh has File:2022 Russian Invasion vehicle marking Z.svg except on Z (军事符号), 俄西斯主义. Yeah.

Discussion on enwiki about this subject.