Last modified: 2012-12-31 14:11:07 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T33298, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 31298 - Badimage list should supress image display in thumbnails, Categories and Special:Filelist
Badimage list should supress image display in thumbnails, Categories and Spe...
Status: NEW
Product: MediaWiki
Classification: Unclassified
File management (Other open bugs)
unspecified
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-10-01 18:35 UTC by alex.farlie
Modified: 2012-12-31 14:11 UTC (History)
2 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description alex.farlie 2011-10-01 18:35:13 UTC
I raised an issue related to this on #wikimedia-tech in freenode earlier,
but I felt I'd put this  one on bugzilla formally.

MediaWiki already has a 'restricted use' image list.

However, this only limits the use of images to a specific article, it does not
at present supress the actual display or request of images.

Therefore, I would like to request that (based on a user preference option)
MediaWiki should suppress the display and request of images that are on the 
bad image list (or tagged with certain templates) in respect of [[Special:Filelist]] thumbnails, and on non Article namespace pages (such as in Categories, Templates or File Description pages).

Such a suppression should be such that as far as the client browser is concerned, the suppressed media does not exist, and is never requested.

This suppression would not affect the policy currently used in relation to 
why images get placed on the restricted list, which would continue as at
present.

Thanks
Comment 1 Bawolff (Brian Wolff) 2011-10-02 21:06:21 UTC
I don't think that's a good idea. The badimage list's primary purpose is to stop shock images from being used outside of the article which they are meant to illustrate, not to generally hide such images. If we don't want images displayed at all, we should either not upload them, or we should have some custom extension to do fine grained filtering based on user preference (And since it sounds like the wmf plans to fund making such an extension (or at least I think they are. I'm not following the massive amount of drama surrounding the personal image filter), we should just wait for that).
Comment 2 alex.farlie 2011-10-02 21:21:38 UTC
I've already said in my original message that it should be based on a user preference.

If the image filter does 'server-side' suppression so that images are filtered out before being requested, then this 'bug' can be closed.

Also some way of allowing external filters to suppress images based on content
flags in HTTP headers would also be appreciated, but that's probably more of 
a technical issue with HTTP itself, then Mediawiki :)...
Comment 3 Bawolff (Brian Wolff) 2011-10-02 21:30:14 UTC
(In reply to comment #2)
> I've already said in my original message that it should be based on a user
> preference.

I know, that's my main objection to doing this (Current bad image list isn't meant to filter based on people's wishes, its meant to stop certain types of vandalism. We shouldn't be mixing and matching purposes imho).

> If the image filter does 'server-side' suppression so that images are filtered
> out before being requested, then this 'bug' can be closed.

It might, said technology doesn't exist yet ;)

> Also some way of allowing external filters to suppress images based on content
> flags in HTTP headers would also be appreciated, but that's probably more of 
> a technical issue with HTTP itself, then Mediawiki :)...

Well that's actually bug 982

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links