Remove option to link to diffs in watchlist feed instead of the page itself, which was disabled by default.
This makes it consistent with the contributions feed when Change-Id: Ie33e2ba90e7a7566d0e0925220b8fd12b1928513 is merged.
For these changes feeds it makes sense to always link to the actual diffs.
See also bug 10268.
Change-Id: I0917844219be773ce24b4c6bac9b7d0d5a4b922d
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I758fa4ad80ac95e2ddd3770bcb9b7d2e57ec34ea
The previous behavior enforced a minimal maximum of 10, even if
$wgFeedLimit was set to a lower value.
Also grepped everything for $wgFeedLimit and fixed all other
error-prone (but correct) uses.
Bug: 50886
Change-Id: Ia81bbadfcf4270b0f932b543265ca37f364530f3
It exposes field /rc_type/ as ApiQueryRecentChanges does thus allowing
user to define which (edit, external, new, log) changes to show in feed.
Bug: 47219
Change-Id: If22827129b04d423711f921307dc820d4840d9d1
I added support for 'wlshow' parameter, which allows user
to decide if to include or exclude bot/minor/anon/patrolled
edits from feed watchlist.
Plus: I bound the params checkup and params' descriptions with
ApiQueryWatchlist (Yurik's suggestions).
Change-Id: Idab489fc017dcf226ea39f2f1766e06064e4ec0a
The effect of setting this option was later overwritten in the code; I
just moved an if a few lines down.
Also some null comparison cleanup.
Change-Id: I2a85673330681c6ff7facc25a7bbfb6972fe8fd5
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
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
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.
sed -i 's/$wgContLanguageCode/$wgLanguageCode/g'
These are now the same, always. Per and since r15827.
$wgLanguageCode wins due to being the one set by LocalSettings.
$wgContLanguageCode definition at includes/Setup.php kept for now.
"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.
Authentication is via a token entered in preferences, if not blank. If
you set a token in your preferences, the following sort of link will
generate the RSS feed:
api.php?action=feedwatchlist&list=watchlist&wluser=Simetrical&wltoken=91c1ef18279f9c24ccf67a79e899ae4d2a3201bc
I haven't actually added the <link> tag to Special:Watchlist, since I've
done enough coding for one night. Someone else can feel free to do
that (otherwise people might get kind of confused :) ).
An auto-generated random token is suggested to the user on the pref page
so that they don't have to be too creative. Pref help text is rather
underemphasized in the default style, though.
It would be worth considering making this opt-out instead of opt-in,
but that would require some voodoo magic to get the default prefs to
work right (since we'd need a different value for each user). We might
set the default to some function of user id + secret site-specific value
to avoid having to store the values in the database.
Since the feature is implemented via the API, it only works if the API
is enabled. Some API people might want to review my code for sanity.
Bug: 471
