These are needed for OAuth grants.
Note that, even if 'editmywatchlist' is not granted, various actions
will still allow for adding but not removing of pages.
Change-Id: Ie33446a228dd6ed0114730935c1bf65667f5ce01
Currently, WatchAction::doWatch and WatchAction::doUnwatch return true
always. Let's have them return a status object instead.
This also cleans up the handling of Status objects in some of the API
modules.
Change-Id: I9dd9f0fd499c37f29fa12bcdb6142238a1f11e4d
See bug 44341 for action=parse, but the problem with interwiki
processing can also be happen in other modules.
This gives clearer error message on some modules
For example action=move:
Bad title "*title*"
instead of:
Unknown error: "immobile-target-namespace-iw"
Change-Id: I86524533dfd778a169b39968999918a1f531efeb
For historical reasons, all our API class had a dummy __construct which
simply calls their parent constructor. This patch removes all such
occurences to save out some bytes.
Change-Id: I667955d7821f780fc5ce23823d74dedb1729b9fa
API was using SVN's version keyword which GIT does not support.
All related methods were either removed, or for those that
could have been used from extensions, emptied out.
api.php?version now shows unrecognized param warning.
Change-Id: I910ca1448ed2ed697ac19b17c486d130aa1d7e03
It's now possible to use uselang with the watch API without
it throwing a warning (cause the parameter wasn't defined).
Idea and some code taken from ApiParse.
Change-Id: I74b7c4286c0c2f44fabc337d5fb744560f71cf71
Doesn't properly work on Special:EditWatchlist, some of the titles being unwatched are not fading out and staying behind.
There's also a small code quality issue unaddressed. Please re-submit for further review.
This reverts commit b46ec8fde5
This patch makes the watchlist editor to use pagination. That would
avoid old browsers crashing (bug 20483).
Patch also add some AJAX operations to the editor, for example to remove
items from watchlist (bug 32151).
The AJAX support is an ALTERNATIVE to the form based method, to keep
support for non javascript users.
This change contains a required change in the API for watch operation,
to allow batch operation, by support titles parameter. The old title
(single page) parameter is still used to keep backward compatibility.
Change-Id: I1d8c66db9ba6456858ef655397935a2b3a421632
action=block/action=unblock can not have the token required because when
using the gettoken param, the token param can not set.
Change-Id: I15317f16c06f150d29c1b17de76f41a6cfa84820
Doxygen choke on text enclosed by '<' and '>' since it tries to
interpret them as HTML or XML elements. This patch adds double quotes
in includes/api/*.php files around the two following strings:
<Firstname>.<Lastname>@gmail.com
<Firstname><Lastname>@gmail.com
Which becomes:
"<Firstname>.<Lastname>@gmail.com"
"<Firstname><Lastname>@gmail.com"
Tested locally, it prevents doxygen 1.8.0 related warnings.
Change-Id: I36d82eb3fd4989ee3ffc65b0b527b83711d1ba69
Added information about the properties of the results of API calls
to action=paraminfo, including information about "property groups":
what should the prop parameter be set to to get that property.
Uses the same format for types as parameters already do.
The output format of some modules doesn't fit this, so the result
properties for them weren't added, or only partially.
Partially implemented modules:
* expandtemplates:
parsetree is in its own tag
* protect, allusers, backlinks, deletedrevs, info, imageinfo,
logevents, querypage, recentchanges, revisions, searchinfo,
usercontribs, userinfo, users, watchlist, upload:
response with partially complex structure
Not implemented modules:
* feedcontributions, feedwatchlist, opensearch, rds:
non-standard reponse
* help:
error is normal response; not very useful for automated tools anyway
* paraminfo, parse, pageprops, siteinfo, userrights:
response with complex structure
Change-Id: Iff2a9bef79f994e73eef3062b4dd5461bff968ab
It's a parctice that dates back to 2006 when the API was first written, and frankly isn't covered by the coding conventions. Same thing with the docblocks, they're all copypasted with some bits changed and don't even make sense if you look at them in the genereated code docs.
I don't feel that any of us depend on this anymore (get a better IDE), so in the inerest of consistancy it's time we said goodbye to it.
* (bug 27655) Require token for watching/unwatching pages
* Previously done for API (bug 29070) in r88522
* As with markpatrolled, the tokens are not compatible and made that way on purpose. The API requires the POST method and uses a universal token per-session. Since the front-end is all GET based (also per convention like in markpatrolled and rollback) they are stronger salted (title / action specific)
* ajax.watch used the API already and was switched in r88554.
* The actual watching/unwatching code was moved from WatchAction->onView to WatchAction::doWatch. This was done to allow the API to do the action without needing to generate a token like the front-end needs (or having to duplicate code). It is now similar to RecentChange::markPatrolled (in that it also a "central" function that does not care about tokens, it's called after the token-handling)
* JavaScript / Gadgets that utilize action=watch in their scripts:
** Effects should be minimal as they should be using the API (see r88522 and wikitech-l)
** If they use index.php and scrap the link from the page, they can continue to do so.
* There are links to the watch action all over the place. I've tried to catch most of them, but there may be some I miss. Migration in most cases is just a matter of adding an array item to the $query for:
'token' => WatchAction::getWatchToken( $title, $user [, $action] )
or changing:
Action::factory( 'watch', $article )->execute();
to:
WatchAction::doWatch( $title, $user );
While replacing the usages in some cases an instance of Article() no longer had to be created, in others $wgUser had to be retrieved from global (which was implied before but needs to be given directly now)
Other notes:
* Article->unwatch() and Article->watch(), which were deprecated as of 1.18 and are no longer used in core, may be broken in scenarios where the Request does not have a 'token' but is making a call to $article->watch()
* Some extensions need to be fixed, I'm currently running a grep search and will fix them a.s.a.p
[1] http://www.mediawiki.org/wiki/ResourceLoader/Default_modules?mw.user#tokens
* Actions come in two flavours: the show-a-form-then-do-something-with-the-result (delete, protect, edit, etc) and the just-do-something (watch, rollback, patrol, etc). Create abstract base classes Action and FormlessAction to support these two cases. HTMLForm is an integral part of the form-based structure.
* Look mum, no globals! :D Fully context-based.
* Implement watch/unwatch, credits and delete actions in the new system as proof-of-concept. This also gives the delete frontend a much-needed overhaul.
* Stub out the newly-deprecated functions from Article.php. This already reduces its linecount by about 15%, and there are plenty more actions still to do.
* Centralising actions like this is going to render a lot of hooks type-incompatible. There's simply nowhere you can put the ArticleConfirmDelete hook, for instance, where it can be passed an OutputPage as the second parameter. On the other hand, we can implement new hooks like ActionModifyFormFields and ActionBeforeFormDisplay, which can do much prettier stuff to the forms, like adding extra fields the 'right' way. Update LiquidThreads to use these new hooks where appropriate.
* Introduced a "cache mode" concept to simplify the header generation code, and to avoid odd results when conflicting cache header requests are received from submodules, or at least to formalise the handling of such cases.
* Made the cache mode private by default, so that code written in ignorance of caching tends to be safe. If different query modules are used in a single request, private caching is preferred over public caching.
* Removed the "must-revalidate" option from all CC headers, this is really specific to page views with a hacked squid in front, I don't think it's applicable here.
* Made the watchlist module private. This is really the definition of private data. There's nothing in the HTTP spec that says the URL for a CC:public request is private and can't be leaked. CC:private provides protection against unknown proxy behaviour.
* In ApiQueryAllmessages: avoid calling $wgLang->getCode() to check if it's necessary to make a new $wgLang when lang= is specified, since this is the only thing that unstubs $wgUser.
* Removed "FIXME: should this check $user instead of $wgUser?" Answer is no.
"I wouldn't object to stylizing the API code to bring it in line with
the rest of MW on principle, but I'm not gonna bother myself." --Roan
<http://www.mediawiki.org/wiki/Special:Code/MediaWiki/60657#c5108>
If you're seeing this commit in blames, tell your blame tool to ignore
whitespace, e.g., git blame -w or svn blame -x -w.
* Instead of hiding read-restricted modules, throw an error when a user without read rights tries to use them
* Do the same for write modules when $wgEnableWriteAPI is false
* Indicate whether a module needs read or write rights in action=help and action=paraminfo
* BREAKING CHANGE: action=purge now requires write rights and, for anonymous users, a POST request
