Last modified: 2011-08-25 20:05:24 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 29954 - Add API method for TitleBlacklist
Add API method for TitleBlacklist
Product: MediaWiki extensions
Classification: Unclassified
TitleBlacklist (Other open bugs)
All All
: Unprioritized enhancement (vote)
: ---
Assigned To: Ian Baker
Depends on:
Blocks: noncoreapi
  Show dependency treegraph
Reported: 2011-07-18 17:35 UTC by Neil Kandalgaonkar
Modified: 2011-08-25 20:05 UTC (History)
2 users (show)

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


Description Neil Kandalgaonkar 2011-07-18 17:35:41 UTC
Create an API method so uploading applications like Extension:UploadWizard can check if a title is going to fail the blacklist.

The minimal implementation would add an API method just to this extension. 

(The best possible implementation would check the same hooks that extensions *like* TitleBlacklist use to block files, so it would be compatible with any similar extension; in which case it's not really a bug on TitleBlacklist. But, it might be better to start smaller)
Comment 1 Brion Vibber 2011-07-19 00:11:50 UTC
I think we want a sort of 'if I try to create a page named like this, would it be ok?' call, sorta like a pre-flight check before you actually go issue your edit or upload. :)

This can then cover:
* basic title validity
* upload filename checks
* TitleBlacklist title checks
* possibly a subset of AbuseFilter rules?

and this could return you a fairly sensible error message, possibly a nice localized one (so we can give sane output about custom blacklist rules for instance, rather than a generic message).
Comment 2 Sam Reed (reedy) 2011-07-19 01:08:18 UTC
Ideally it's kept as generic as possible (and probably core api), and "emulate" it going through all possible validation methods as much as we possibly can...
Comment 3 Neil Kandalgaonkar 2011-07-19 06:15:48 UTC
I agree a generic preflight check thing would be nice, but TitleBlacklist is a good place to start.

One could make an omnibus method that looked for common extensions like TitleBlacklist and AbuseFilter, but If you're going to do this generically you need to directly invoke the hooks associated with page creation (instead of waiting for page creation to call those hooks). But it's not easy to tease apart which might be simple checks for titles and which might have side effects.
Comment 4 Ian Baker 2011-07-19 18:01:32 UTC
Yeah, invoking page creation hooks without creating a page sounds clever, but also fragile.  Like, if it works now, there's no guarantee that a future extension won't break it by using those hooks to invoke DML.

I'd be into the notion of making a generic API that, if existing validation classes are present, will call them all and aggregate the results.  It would require new code for each validation extension, but it'd allow us to at least centralize that, rather than having each new consumer of the data implement all of them separately.

At the moment, though, I think I'm going to build a TitleBlacklist API.  We can move that very same code into a more generic API when/if we need to add support for a second validation extension.
Comment 5 Sam Reed (reedy) 2011-07-19 18:14:42 UTC
Having a hook, or some relevant global, would allow things to be able to grab into the validation logic, rather than into our somewhat convoluted methods that end up into the extensions as is.

Something to look at later definitely
Comment 6 Ian Baker 2011-08-25 20:05:24 UTC
API built and deployed.  We'll hopefully start using it this week.

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