There are a couple of user options related classes already,
and the T321527 work on dynamic defaults is going to add
even more. Let's move them into a separate namespace
to make core a bit more organized.
Old name is kept as an alias for compatibility purposes.
Bug: T321527
Bug: T352284
Change-Id: I9822eb1553870b876d0b8a927e4e86c27d83bd52
Remove hardcoded "Main Page" and use whatever the main page of
the wiki is. Many wikis have their main page in a different
title than the default or even in a different namespace entirely.
With the hardcoded title this produces broken/redlink for the doc
examples and makes it overall less useful.
Most typical examples; Mediawiki.org itself, Wikidata.org, etc.
Bug: T235207
Change-Id: Ia9eee76544cad153166dd5a2eb8e8c1bf3a38b74
Mostly used find-and-replace:
Find:
/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?)[\s\*]+/\s*(private|protected|public) (\$[a-z]\w+;\n)((?=\s*/\*[\*\s]+@var (I?[A-Z](\w+)(?:Interface)?))\n|)
Replace with:
\3 \1 \4
Followed by some manual review to make sure I'm not changing too much,
omitting some changes that looked too complicated and anything that
caused test failures, and some whitespace fixes.
Change-Id: I6ec7587607df4f1a4f448a096c3e44c4e5270b70
This covers all occurrences of /onfig->.*get( '/ in includes/.
Undoubtedly there are still plenty more to go.
Change-Id: I33196c4153437778496f40436bcde399638ac361
In a similar vein to I46033d5ddda055c275dbda71d5c38c4a7a858c9d
The documentation to WikiPage::doUpdateRestrictions is changed to remove
`|string|null`. ManualLogEntry::addTags can handle a string but it's
unexpected in the RevisionFromEditComplete hook. From codesearch,
ApiProtect is the only caller passing in $tags, and that's coming from
a PARAM_ISMULTI, which presumably can only be an array or null.
Bug: T302918
Change-Id: Icd8a7391f7a8c21b0cdb1f734e65ee5661c1075f
Allow specifying the title used for rendering error messages in
ApiErrorFormatter.
Then, specify one in ApiEditPage (and a few similar modules that deal
with single pages) once we've figured out which page is being edited.
Bug: T247661
Change-Id: Ic3d70efc23744ef6e90abc445f3babebf45c4697
'apierror-protect-invalidlevel' potentially wants updating at a later point as the
message isn't necessarily clear what the error is; the protection may be valid
but the users right to do so is not.
Bug: T270713
Change-Id: I72fe67264baa4123599ec424a7d780192ca54bcc
This trait is not needed in ApiBase and its presence here is
proving to be problematic. See I795db12.
In this patch, the trait usage (more precisely the 'use statement')
has been removed from ApiBase and accordingly the signatures of
ApiWatchlistTrait::getWatchlistValue() and ::setWatch() have been
altered to now require User object.
With these changes, the abstract getUser() method in the trait is no
longer needed, so it has been removed also.
All core usages of the affected functions are fixed in this patch.
The trait is used in only one extension according to codesearch tool,
the extension will be fixed in Ic22e163.
Bug: T262175
Bug: T248512
Follow-up: Ia18627b9824dca81f44f0571e8420d89b7626cf6
Change-Id: Idabcea71edfca9e7ed42000a258c99ff407873d4
This introduces an ApiWatchlistTrait that refactors out common code
across APIs that allow you to watch pages. Some methods have been
migrated from ApiBase and changed completely, but codesearch suggests
they aren't being used outside the API modules in this patch.
Bug: T248512
Bug: T248514
Change-Id: Ia18627b9824dca81f44f0571e8420d89b7626cf6
It is the job of git and svn to provide this information/metadata.
The form was different, some with short, some with long month name
some with leading zero at the day, some without.
The year is also present in the Copyright clause
Change-Id: If006907b82b9e45f13cfa2e45d41107a95570e1a
Links generated by the API are now aware of the user's preferred
language and will show documents in that language if available.
To test, log in to mediawiki.org and set your language preference to 'es',
then on an MediaWiki installation with this patch view the generated
expanded API help at `api.php?action=help&recursivesubmodules=1&modules=main`.
Each link to documentation on mediawiki.org should take you to its
translated /es subpage, if one exists.
Bug: T104518
Change-Id: I339a1f3ae1bce9d759cf251899d57c32b1def91e
This allows for removing $wgContLang from many API modules where it was
only used to call $wgContLang->formatExpiry() in a way in which the
results don't actually depend on the language.
Change-Id: Ib0f25f288b9b87d2e4131297c552e5971696db87
API warnings and error messages are currently hard-coded English
strings. This patch changes that.
With a few exceptions, this patch should be compatible with non-updated
extensions:
* The change to ApiBase::$messageMap will blow up anything trying to
mess with it.
* The changes to the 'ApiCheckCanExecute' hook will cause a wrong
(probably unparsed) error message to be emitted for extensions not
already using an ApiMessage. Unless they're currently broken like
Wikibase.
Bug: T37074
Bug: T47843
Depends-On: Ia2b66b57cd4eaddc30b3ffdd7b97d6ca3e02d898
Depends-On: I2e1bb975bb0045476c03ebe6cdec00259bae22ec
Depends-On: I53987bf87c48f6c00deec17a8e957d24fcc3eaa6
Depends-On: Ibf93a459eb62d30f7c70d20e91ec9faeb80d10ed
Depends-On: I3cf889811f44a15935e454dd42f081164d4a098c
Depends-On: Ieae527de86735ddcba34724730e8730fb277b99b
Depends-On: I535344c29d51521147c2a26c341dae38cec3e931
Change-Id: Iae0e2ce3bd42dd4776a9779664086119ac188412
- Add 'tags' parameters to appropriate API modules
- Add tag-adding logic to appropriate functions that carry out
relevant functions
- ManualLogEntry::{set,get}Tags to handle adding tags to log
entries in a cleaner fashion
- Use ManualLogEntry::setTags in LocalFile::recordUpload2
Bug: T97720
Change-Id: I98c52da7985623bfdafda2dc2dae937b39b72419
Some were being logged, and some weren't. Let's log them all
automatically when PARAM_DEPRECATED is processed, instead of requiring
each module to manually log them.
Bug: T117569
Change-Id: Ia38aeeccd0b9857b12b28914f509284483fbcca8
Nothing in this patch should result in changed output for format=json or
format=php except as noted in RELEASE-NOTES-1.25, and changed output for
format=xml should be similar or cosmetic. However, other code accessing
the result data directly may need to be updated.
Bug: T87053
Bug: T12887
Change-Id: I3500708965cb8869b5aed1543381aad208dadd13
ApiResult was a mess: some methods could only be used with an array
reference instead of manipulating the stored data, methods that had both
array-ref and internal-data versions had names that didn't at all
correspond, some methods that worked on an array reference were
annoyingly non-static, and then the whole mess with setIndexedTagName.
ApiFormatXml is also entirely annoying to deal with, as it liked to
throw exceptions if certain metadata wasn't provided that no other
formatter required. Its legacy also means we have this silly convention
of using empty-string rather than boolean true, annoying restrictions on
keys (leading to things that should be hashes being arrays of key-value
object instead), '*' used as a key all over the place, and so on.
So, changes here:
* ApiResult is no longer an ApiBase or a ContextSource.
* Wherever sensible, ApiResult provides a static method working on an
arrayref and a non-static method working on internal data.
* Metadata is now always added to ApiResult's internal data structure.
Formatters are responsible for stripping it if necessary. "raw mode"
is deprecated.
* New metadata to replace the '*' key, solve the array() => '[]' vs '{}'
question, and so on.
* New class for formatting warnings and errors using i18n messages, and
support for multiple errors and a more machine-readable format for
warnings. For the moment, though, the actual output will not be changing
yet (see T47843 for future plans).
* New formatversion parameter for format=json and format=php, to select
between BC mode and the modern output.
* In BC mode, booleans will be converted to empty-string presence style;
modules currently returning booleans will need to use
ApiResult::META_BC_BOOLS to preserve their current output.
Actual changes to the API modules' output (e.g. actually returning
booleans for the new formatversion) beyond the use of
ApiResult::setContentValue() are left for a future change.
Bug: T76728
Bug: T57371
Bug: T33629
Change-Id: I7b37295e8862b188d1f3b0cd07f66ac34629678f
There's a bunch of stuff that probably only works because the database
representation of infinity is actually 'infinity' on all databases
besides Oracle, and Oracle in general isn't maintained.
Generally, we should probably use 'infinity' everywhere except where
directly dealing with the database.
* Many extension callers of Language::formatExpiry() with $format !==
true are assuming it'll return 'infinity', none are checking for
$db->getInfinity().
* And Language::formatExpiry() would choke if passed 'infinity', despite
callers doing this.
* And Language::formatExpiry() could be more useful for the API if we
can override the string returned for infinity.
* As for core, Title is using Language::formatExpiry() with TS_MW which
is going to be changing anyway. Extension callers mostly don't exist.
* Block already normalizes its mExpiry field (and ->getExpiry()),
but some stuff is comparing it with $db->getInfinity() anyway. A few
external users set mExpiry to $db->getInfinity(), but this is mostly
because SpecialBlock::parseExpiryInput() returns $db->getInfinity()
while most callers (including all extensions) are assuming 'infinity'.
* And for that matter, Block should use $db->decodeExpiry() instead of
manually doing it, once we make that safe to call with 'infinity' for
all the extensions passing $db->getInfinity() to Block's contructor.
* WikiPage::doUpdateRestrictions() and some of its callers are using
$db->getInfinity(), when all the inserts using that value are using
$db->encodeExpiry() which will convert 'infinity'.
This also cleans up a slave-lag issue I noticed in ApiBlock while
testing.
Bug: T92550
Change-Id: I5eb68c1fb6029da8289276ecf7c81330575029ef
Refactor out 'infinity' vartiant values which used in blocking and
protecting actions. This patchset adds GlobalFunction wfIsInfinity.
Bug: T68646
Change-Id: I60cc55a5bbd43c72916a1c2ea3807457d4e33765
This also adds some new ApiBase::PARAM_* constants to generate more
helpful help, and a method to override the default description message
for the use of ApiDisabled and ApiQueryDisabled.
Bug: 71638
Change-Id: Ic0c3d232e0498d58a043037e2e0c6f0b1c3edad3
The current token handling is a mess. This simplifies things greatly:
* *All* tokens are obtained from action=query&meta=tokens, rather than
being spread over action=tokens, action=query&prop=info,
action=query&prop=revisions, action=query&prop=recentchanges, and
action=query&prop=users. All these old methods are deprecated.
* Similarly, there is only one hook to register new token types. All old
hooks are deprecated.
* All tokens are cacheable.
* Most token types are dropped in favor of a 'csrf' token. They already
were returning the same token anyway.
* All token-using modules will document the required token type in a
standard manner in action=help and are documented in machine-readable
fashion in action=paraminfo.
Note this will require updates to all extensions using tokens.
Change-Id: I2793a3f2dd64a4bebb0b4d065e09af1e9f63fb89
The format for 'props' was never specified and the list for 'errors' is
impossible to keep updated when considering that many errors come from
MediaWiki backend code and extension hook functions. And since there
doesn't seem to be any real use case for either of these, let's just
kill both of them instead of wasting effort on trying to fix them.
Note that neither getResultProperties nor getPossibleErrors are called
from any extensions in gerrit, and none of the other deprecated methods
are called outside of the implementations of those two methods. Removing
the obsolete methods is left to the maintainers of the extensions, as
keeping them hurts nothing and is needed to maintain compatibility with
earlier versions of MediaWiki.
Change-Id: Ie11a401d60c834059fbf1b5625ca8ea093b3337c
In general, the web UI does a check of the watchlist preferences along
the lines of "watch if watchdefault, or if watchcreations and the title
doesn't exist". So there's no way to have it watch edits but not
creations. Make the API behavior match this.
For API action=protect&watchlist=preferences, we want to use
'watchdefault' always to match the behavior of the web UI.
For Special:Upload, the code is all there to do a "watch if
watchdefault, or if watchcreations and the file doesn't exist". But for
some reason that code wasn't being used in favor of just using
watchcreations all the time. Fix that, too. And have the API use that
instead of checking if the file page exists.
Bug: 56766
Change-Id: I57fc46d9a97b3ea2169173727db842d0d7ecf81d
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
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
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
