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
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 class is used heavily basically everywhere, moving it to Utils
wouldn't make much sense. Also with this change, we can move
StatusValue to MediaWiki\Status as well.
Bug: T321882
Depends-On: I5f89ecf27ce1471a74f31c6018806461781213c3
Change-Id: I04c1dcf5129df437589149f0f3e284974d7c98fa
Rate limits will automatically be checked by definitelyCan(),
authorizeRead() and authorizeWrite(). The authorize methods also
increment the counter.
UserAuthority tracks which limits have already been incremented during
the current request, to avoid duplicate increments caused by code that
still calls pingLimiter directly.
DEPLOY: Risky! We SHOULD not hit rate limits more often, but we might.
Rate limit metrics should be monitored closely, see
<https://grafana.wikimedia.org/d/8oA6CWr4z/mw-rate-limiting-overview>.
Bug: T310476
Depends-On: Iebd62b0487af9172edaeae41c9b31aaf2f20fd06
Change-Id: Ic349f03b7040343815b60b0a2c84a5780326c797
This covers all occurrences of /onfig->.*get( '/ in includes/.
Undoubtedly there are still plenty more to go.
Change-Id: I33196c4153437778496f40436bcde399638ac361
ApiMove::movePage was essentially duplicating the logic from
MovePage::moveIfAllowed, with a few differences:
- Change tags were validated separately, which means we're now checking
them twice (which I hope should be fine).
- Edit blocks weren't spread for talk pages.
- movePage was calling MovePage::move if all checks were successful, and
this wasted time by calling isValidMove again.
Change-Id: I97c2b9366bb24e8c76ffcd2fc59f9abe41e6361d
Make phan stricter about null types by setting null_casts_as_any_type to
false (the default in mediawiki-phan-config)
Remaining false positive issues are suppressed.
The suppression and the setting change can only be done together
Bug: T242536
Bug: T301991
Change-Id: I0f295382b96fb3be8037a01c10487d9d591e7e01
In that case the variable $toTalk is null,
but that is not allow for the moveSubpages() function
Found by phan strict checks
Change-Id: Ib1f67247277f44dc8c9b08eb5a287c701f45f918
Replaces calls directly to PermissionManager with calls to
the Authority object available from Context or the
GroupPermissionLookup service.
This patch does not address use of PermissionManager for
blocks.
Deprecations:
- ApiBase::checkUserRightsAny deprecated passing optional
User parameter
- ApiBase::checkTitleUserPermissions deprecated passing
LinkTarget as first parameter, takes PageIdentity instead
Bug: T271462
Bug: T271854
Change-Id: I5d7cac1c28a37e074750c46cda03283980a07fca
Remove $modulePrefix from ApiMove constructor as unused as it was in
the way for injecting MovePageFactory.
Bug: T252934
Change-Id: I80e23370b84f74cd502e5a76ef973c707e9d8c9b
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
Notably:
* In ApiManageTags, I used a switch instead of a dynamic function name,
so that the call graph will be correct.
* In ApiImageRotate, checkTitleUserPermissions() has always returned
void, this was an error introduced in 4e6810e4a2
Change-Id: Iea22616b8e7e2e0cc804619a54f8690898b2cb82
RepoGroup::singleton() results in
MediaWikiServices::getInstance()->getRepoGroup()
Also avoid getting the service in loops, doing it once before the loop
is cheaper
Change-Id: I29e0c7487e3e498559ff16a567e2fad0c0f8bb69
PHP doesn't care much but I think we humans do because we should
call methods by the name we give them. Method fixed are;
- isOk() -> isOK()
- setOk() -> setOK()
- teardown() -> tearDown()
Change-Id: I6b3f0cf3902887058efa426968da380803869e0b
This will help make MovePage more testable.
In the course of abstracting the logic out of ParserFactoryTest to
FactoryArgTestTrait so it could be used in MovePageFactoryTest, I made
them all unit tests instead of integration. This required some
modification to the Parser constructor so that it didn't access
MediaWikiServices unnecessarily.
Change-Id: Idaa1633f32dfedfa37516bb9180cfcfbe7ca31aa
These global functions were deprecated in 1.34 and services made
available to replace them. See services below;
* wfFindFile() - MediaWikiServices::getInstance()->getRepoGroup()->findFile()
* wfLocalFind() - MediaWikiServices::getInstance()->getRepoGroup()->getLocalRepo()->newFile()
NOTES:
* wfFindFile() and wfLocalFind() usages in tests have been ignored
in this change per @Timo's comments about state of objects.
* includes/upload/UploadBase.php also maintained for now as it causes
some failures I don't fully understand, will investigate and handle
it in a follow up patch.
* Also, includes/MovePage.php
Change-Id: I9437494de003f40fbe591321da7b42d16bb732d6
The code in EditPage and SpecialMovepage does this primarily in web UI
code paths that aren't called by the API. EditPage also has a check in
the internal code path used by the API, but ApiEditPage runs its own
permissions check first and won't reach that code path.
Bug: T216245
Change-Id: I6263c8b60a24f3195dba583463f1ce4b004f82f5
One bug caught: the watch and unwatch params were not being honored.
They have now been removed.
Depends-On: Ia21a974f2b463afc9324182137b95c80db86a6aa
Change-Id: I0e214339c9ae3f0fb5a40c88a84190bc32503151
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
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I49e2a10350a328a8572fcedd44012751a29e1068
Adds support for tagging log entries for the block, import,
managetags, and move API modules, using a 'tags' parameter.
Bug: T97720
Change-Id: I9d75d2cece317a7704c4bc6d734ad3cafe24544e
The move will probably error out anyway, but we want it to do so
properly instead of by throwing a PHP fatal.
Bug: T153693
Change-Id: I19334a28a3f539e0f3d3866353093711f68786ee
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
While rate limiting has been applied to moves via the web UI since rate
limiting was first added, it appears that it was overlooked when ApiMove
was created.
This follows the same model as is followed by the web UI: each
submission to ApiMove is one "hit" for the rate limiter, even though
that submission might result in multiple pages being moved (e.g. the
page, its talk page, and its subpages) depending on the options and user
rights.
Bug: T132874
Change-Id: I564d8bfcc7dd3ad6d92dbbc33519a589697c0d4e
Signed-off-by: Chad Horohoe <chadh@wikimedia.org>
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
* Potentially long running POST requests often use multiple transactions,
talk to multiple services, or defer updates. Try to make sure they have
a chance to complete all of the work. WMF already sets ignore_user_abort()
across the board in config, but this applies it to key spots for all
installs, in addition to bumping the time limit.
* Eventually this can lower the need for high overall time limits.
Bug: T102890
Change-Id: I893ddd773064dcd63b5b24c84c6391974f4b5aee
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
Change Ic5026384 accidentally lost the check when changing from
Title::moveTo (which does the check itself) to MovePage::move (which
doesn't).
Bug: T75985
Change-Id: Ia64a233936c639a6748488e4d25816e87658ffe1
* AbortMove hook is removed in favor of two more specificly focused
hooks: MovePageCheckPermissions and MovePageIsValidMove.
** MovePageIsValidMove is for extensions to specify whether a page
cannot be moved for technical reasons, and should not be
overridden.
** MovePageCheckPermissions is for checking whether the given user
is allowed to make the move.
* Title::moveNoAuth() deprecated
* Title::moveTo() deprecated
* Title::isValidMoveOperation() broken down into
MovePage::isValidMove() and MovePage::checkPermissions().
* Title::getTitleProtection() is now public, and returns
unprefixed fields
Change-Id: Ic5026384b92a0d68d628397ffe1de6e5b6183f02
