Put Brad Jorsch (anomie) as lead developer (as he's the one
who does most of the review work etc. these days).
Made Yuri's lead developer time frame end in 2013 (as he
last commited to the api in 2013 AFAIS).
Change-Id: I640ddf251340214b4520d3072e22dfe6b54815fb
Unbounded modification = replication lag. And this function is specifically intended for clearing very large watchlists which would easily escalate to pageable lags of several minutes.
This reverts commit 66b07ea381.
Change-Id: Ie34be712884407e671d715e56bda3bff4a7e78f4
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
Link to the actual differences in the API contributions feed.
Related to bug 10268 (which is for watchlist, which already has this as an option disabled by default).
Change-Id: Ie33e2ba90e7a7566d0e0925220b8fd12b1928513
Requested by bot runners, who often accumulate huge watchlists
and have trouble resetting them.
Requires POST and a token to prevent accidents or abuse.
Same token as individual or list watching.
Bug: 65058
Change-Id: Id8476a1ba8b2661cf6451cacf3121d5c2d0675cf
This partially reverts r73950 which removed $wgServerName on the ground that it
was only used for {{SERVERNAME}}. When it was pointed out that $wgServerName was
also used by several extensions, the response was not to restore the variable, but
to proceed to remove it from extensions as well.
It is a useful variable to have, as the discussion on Id819246a9 makes clear
(see Tim's comment on PS12 and Timo's reply). So let's reintroduce it, and expose
it in mw.config and ApiQuerySiteInfo as well.
Change-Id: I40a6fd427d38c64c628f70a2f407b145443ea204
For browser testing, I need a reliable way to determine the branch in use
on a target wiki. One could parse the generator name forged when
querying the siteinfo, but that yields:
MediaWiki 1.24alpha instead of master
MediaWiki 1.24wmf2 instead of wmf/1.24wmf2
I am not really willing to reverse engineer the version to figure out
the branch, instead just expose it over the API.
Bug: 62509
Change-Id: If3db8f480ce0d590522741d40fb8e43b753efb41
action=query&meta=siteinfo&siprop=extensions calls
$gitInfo->getHeadCommitDate() to attempt to find the commit date, but
does not check whether that function returned false before using the
value. This resulted in displaying the current date for "vcs-date" when
the function failed.
Bug: 64821
Change-Id: Ic39a74abe5160b3b7fbfb7c15323328d6b317560
Prior to change I7c957e1e, API logins were done as if the "keep me
logged in" checkbox was checked. That change altered this for no
apparent reason.
Bug: 64727
Change-Id: I7fcca2a1eabcac3b2c232cd05d9989af85cc3ed0
action=parse&prop=modules now provides the ResourceLoader modules used
on the page (included in the ParserOutput object). This is intended to
be used by the live preview functionality.
Bug: 24134
Change-Id: Ib5032e4eeaf6bb97dac965c580a5107437c7bbd4
These files have all had treatment before, and these occurrences have either
been missed or have been introduced after.
Change-Id: I06cdab4616b5bff47c85152df28f18c861730a23
Blockinfo is currently the only piece of information
(apart from tokens) in the users API which might change
depending on the permissions of the user making the
query. There is no point in making the API request
uncacheable if blockinfo is not requested.
Change-Id: I533f622b7d9077589f148fbb6de98b15ef1c212a
In I1b7396ceb, we were trying to log failures to Special:Log, but
since $this->dieUsage throws an exception, the log entry insertion
was being rolled back.
This is similar to I36cd645d which was for index.php calls.
Change-Id: I136ba66d2f939fcdd0c9326e04d686a30449bf4c
Follows-Up: I8f1da51187b281fe4afc0d5a0c49f5caf3612e92
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 API takes multi-valued parameters as key=value1|value2|value3, not
key[]=value1&key[]=value2&key[]=value3, in part because the latter is
overly verbose when the API encourages use of large arrays.
But when someone, not knowing this, does accidentally use the verbose
syntax, they should get a warning instead of having the parameter be
silently ignored.
Bug: 64057
Change-Id: I32a16efb8028d7f6d120d20dfc886f08ed9ec97d
Removed 'Remember my login' from Preferences, as it was unwanted. It adds
to the complexity of the user preferences
Bug: 52342
Co-Author: Tyler Romeo <tylerromeo@gmail.com>
Change-Id: I7c957e1e1aaecf47f7c47bc063b5d3b364644afc
Prior to fc20c30d20, the feed was cached for 10 seconds. That
change accidentally removed varnish caching. Re-add the caching,
and upping to 15 seconds for good measure (15 second delay on the RSS
feed shouldn't matter, people generally read those asynchronously
anyhow. I was thinking of maybe even uping to 30 seconds). Users
can still manually set an smaxage parameter via the url if they
don't like the default cache time.
This assumes nothing private (e.g. per user) is ever on the RSS
feed. Reading through the ChangesList code this appears to be
the case, as everyone is getting the feed from a shared
memcache entry.
Bug: 63249
Change-Id: I268d0a53067738ba96bee74c593358b0b28cc083
API queries must be completely ordered for proper behavior; otherwise
you may get into a situation where a query returns the same continuation
value that was provided. Various modules that have been using timestamps
in/as their continuation parameter can easily run into this problem.
Normally we'd have to add additional fields to the relevant indexes to
be able to make this work without having filesorting queries (which
MySQL really doesn't do well, it fetches all matching rows and only
applies the limit after[1]). But InnoDB has a "feature" where it
effectively appends the table's primary key to all other indexes,[2]
which makes these queries be properly indexed in that situation.
Apparently we're ok with this, since Icc43b62f was merged depending on
this feature.
Also, this change fixes some MySQLisms and other oddities done to
ApiQueryRecentChanges in Icc43b62f.
[1]: https://dev.mysql.com/doc/refman/5.5/en/limit-optimization.html
[2]: https://dev.mysql.com/doc/refman/5.5/en/innodb-table-and-index.html
Bug: 24782
Change-Id: I4c9f8c0c2bfd831755d4fa20a18f93fef1effd28
It's pretty much like action=opensearch but can be used as a generator
which can be handy when you need to retrieve both the list of pages and
some information about them.
Change-Id: Iaffe30a0f7402e1316c4885a805692a34bbe1a6a
Also removed true as second parameter to it from CloneDatabase.php
since it is the default value of that parameter.
Change-Id: I727ebae2bd4df0e26019985ce8c7ce73381c5642
One of the causes (if not the cause) of bug 56269 is if something
manages to throw an exception that makes it to MediaWiki::run's
last-resort exception catcher while having an open database transaction:
the transaction never gets committed or rolled back, so it gets
implicitly rolled back and a warning is raised.
The API has the opposite problem in bug 63145: it catches the exception
but then does the normal DB shutdown which *commits* the transaction.
This is certainly the Wrong Thing to do.
Ideally, neither of these would ever happen because any code using
transactions would have its own try-catch that would catch any
exception, rollback the transaction, and then rethrow the exception. But
it happens anyway, so let's have both of these last-resort exception
handlers do the rollback, and also log the exception so the throwing
code has a better chance of being properly fixed.
Bug: 56269
Bug: 63145
Change-Id: I8f1da51187b281fe4afc0d5a0c49f5caf3612e92
ApiFormatFeedWrapper, for example, has nothing particularly useful to do
when given an API error to print. So allow for punting errors to the
default formatter instead.
Bug: 63150
Change-Id: Ifc034d4c7861905e382c42dc22585f0cd2beaf3f
Always include redirects. Search results are worse without them
and MWSearch has never respected this option anyway.
Change-Id: I0ebe321a3b14e7960aa98e3225dc5a19ba916e7d
* Moved ApiRunJobs to a special page instead of going through
ApiMain and having to fight the logic there. As a separate
internal API, this does not show up on the API help page and
is no longer effected by $wgEnableAPI.
bug: 62233
Change-Id: I1db6f526d02e130a66ee03289858a734d89e6c00
list=logevents&leaction has param values with *, which gets bold, when
there was two of them in the same line.
Bug: 61834
Change-Id: Idace9afd4f3a2dce9be539b209a02fa318df8f45
The immediate impetus behind this change is this series of events:
1. CirrusSearch hooks ApiBeforeMain to handle some setup that requires
the User object.
2. So User is loaded from the session.
3. OAuth checks the headers as part of loading User.
4. OAuth sees that the headers are invalid, and since it was called from
the API it throws a UsageException, expecting the API to catch it and
return an appropriate response to the client.
5. But nothing does so, leading to an unhelpful "Internal Error" page
being returned to the client.
We can do better than that.
Bug: 62312
Change-Id: Ib5735661eec6ebe57eaa69c67b399e703cc90fc4
I should have done it at the beginning instead of trying to
extract it from recent changes.
Same for SpecialRecentChanges and SpecialRecentChangesLinked
(subclasses).
Created a new API module for it: ApiFeedRecentChanges.
It's somewhat un-API-like and hackish, but all feed modules are.
Old URLs redirect to new ones, so this should be fully
backwards-compatible assuming sane feed reader clients.
Change-Id: I06ee0f01d896bc66545a1800b24693ce7524e433
