Last modified: 2011-03-22 23:07:44 UTC
Commons reports that the list that blocks DSC902458 etc uploads is not functioning.
I am not aware of a list that blocks such uploads, only a list that warns when such files are uploaded. That list is working, I entered as filename "DSC000001.jpg" and I get a warning: The name of the file you are uploading begins with "IMG", which is a non-descriptive name typically assigned automatically by digital cameras. Please choose a more descriptive name for your file.
It's done via MediaWiki:Titleblacklist and MediaWiki:Titleblacklist-custom-filename
That's an extension, changing category.
*** Bug 27339 has been marked as a duplicate of this bug. ***
*** Bug 27700 has been marked as a duplicate of this bug. ***
I just reproduced it here from both a sysop and non-sysop account: http://commons.wikimedia.org/wiki/File:DSC902458.jpg Did not get blocked by title blacklist.
Can seemingly reproduce locally. But not too familiar with code. Will poke it when I've got a bit more time
No idea about how it's supposed to work $wgHooks['EditFilter'][] = 'TitleBlacklistHooks::validateBlacklist'; It would seem, that creating a file page doesn't hit this hook call, at all. Blocking redirects to non existent blacklisted titles seems to work fine, as does "The title "Meh on wheels" has been banned from creation. It matches the following blacklist entry: .*? on wheels" Just no hits for image uploads for whatever reason..
That and there seems to be no code actually preventing any sort of new titles from being created. Almost seems like we're barking up the wrong tree...
<vvv> Reedy: probably someone removed check for page creation permission from upload module <vvv> Was it rewritten in 1.17? <Reedy> I think so <snip> <vvv> Reedy: it looks like UploadBase assumes that 'edit', 'upload', etc are not per-page restrictions <vvv> Reedy: oh, and it also allows to upload images even when they are create-protected
UploadBase::verifyPermissions() ?
Fixed with r84573 and r84575 However, seems I broke some error handling in r83979, will investigate
Actually properly fixed in r84581