A move method that doesn't check for things like moving a page on top of
itself or moving to a namespace with a different content model does not
seem like it's what callers would expect, and not what Title::moveTo
ever did. If there's a caller that really wants this behavior, we can
make moveUnsafe public.
I also made the $reason and $createRedirect parameters to move()
optional to match Title::moveTo() behavior. However, I made $reason
default to null instead of '', to distinguish between an empty edit
reason provided by the user and no edit reason provided at all (e.g., a
move done internally without specific user request).
Depends-On: I971e619eb76c4474fe037fad258f9c496717bf41
Change-Id: I6ddcc9f34a48f997ae39b79cd2df40dd2cc10197
We don't want to depend on the entire site configuration when we only
need a few specific settings.
This change additionally means that these services no longer see a live
version of the settings, but rather a copy. This means in tests you
really do have to call overrideMwServices() if you want services to pick
up your config changes.
ResourceLoader and SearchEngineConfig will need more work to port,
because they expose their member Config in a getter, and the getter is
actually used.
Parser and NamespaceInfo are also relatively complicated, so I split
them into separate patches.
Tested with 100% code coverage. \o/
Depends-On: If6534b18f6657ec1aba7327463f2661037f995b3
Change-Id: I1a3f358e8659b49de4502dc8216ecb6f35f4e02a
If IPs cannot upload files, hide link to list of files
which they uploaded.
Also simplify the code: User::getID() should always return int,
so $id !== null was always true. And add references to some tasks.
Bug: T220674
Change-Id: Ia9e1516393d6e85858cceb02bb09405148adaf51
When ContribsPager is using an auxiliary table like ip_changes or
revision_actor_temp for the main action of the query, we already had
code in place to let it use the auxiliary table's denormalized timestamp
field for the ordering. What we didn't have was code to let it also use
the auxiliary table's denormalized timestamp field for *continuation*.
With the schema defined in tables.sql, the simplest thing to do would be
to be to add a redundant JOIN condition between rev_timestamp and the
denormalized timestamp field which would be enough to allow
MySQL/MariaDB to propagate the continuation conditional on rev_timestamp
to the denormalized timestamp field.
Unfortunately many Wikimedia wikis have rev_timestamp defined
differently from table.sql (P8433), and that difference is enough to
break that propagation. So we need to take a more difficult route,
restructuring the code tell IndexPager to explicitly use the
denormalized fields for ordering and continuation.
On the plus side, since we're doing that anyway we can get rid of the
code mentioned in the first paragraph.
Bug: T221380
Change-Id: Iad6c0c2f1ac5e1c610de15fe6e85a637c287bcd8
The method User::isBlocked() attempts to answer two questions:
(1) Does the user have a block?
(2) Is the user prevented from performing this action?
The method can answer #1, but it cannot answer #2. Since User::getBlock() can
also answer #1, this method is redundant. The method cannot answer #2 because
there is not enough context in order to answer that question.
If access is being checked against a Title object, all access checks can be
performed with PermissionManager:userCan() which will also check the user's
blocks.
If performing all access checks is not desirable, using
PermissionManager::isBlockedFrom() is also acceptable for only checking if the
user is blocked. This method does *not* determine if the action is allowed,
only that the user's block applies to that Title.
If access is being checked without an existing Title, User::getBlock() can be
used to get the user's block. Then Block::appliesToRight() can be used to
determine if the block applies explicitly to a right (or returns null if
it is unknown or false if explicitly allowed). If the user is creating a new
Title, but the text of the title is not yet known (as in the case of Wikibase),
access should be checked with Block::appliesToNamespace().
Bug: T209004
Change-Id: Ic0ad1b92e957797fee8dcd00bd1092fe69fa58f1
We're moving away from globals to Config this patch attempts to
clean off some globals whose values can be nicely gotten via the
use of Config.
Bug: T72638
Change-Id: I25516873c215b74cdd425d023e877e5cdc3d6149
Special:Userlogout now requires a token
Api action=logout requires a csrf token and the request to be POSTed
Patch author: bawolff
Bug: T25227
Change-Id: Icb674095956bb3f6c847c9553c53e404402ea774
Tell Linker::userToolLinks() and Linker::userToolLinksRedContribs()
to omit parentheses, and load the CSS that fills them in.
Change-Id: Ie979537abed226e945cf1918b3ee240ae78ee24e
Now that Partial Blocks feature is being enabled on multiple wikis
a new filter (Block Type) is added to Special:BlockList to facilitate
viewing the different blocks in place.
Bug: T191549
Change-Id: I0bc8c6eaff22930c2e3c12ae5e77e03287910db9
BlockRestriction was initially created as a static class and there is no reason
why this shouldn't be available in the service container.
Also renaming as BlockRestrictionStore to keep up with the new emerging naming patterns.
Bug: T219684
Change-Id: If0b954f286d4759de2e3e41a0eb788e74bd72996
The timestamp displayed in the link is not from the last refresh
but from when new changes are available.
I don't think this distinction is consequential. The fundamental
meaning is that clicking the link will bring changes newer than
the timestamp.
I considered using a relative timestamp (2h ago) like is
proposed in the task but I didn't think it was worth it
for the following reasons:
1. Client-side formatting with momentjs is hacky
at best and I couldn't find a way to have it
respect user's preferences.
2. I don't think it makes the meaning of the timestamp
in the message any clearer. I'll admit the meaning
of the current timestamp is not explicit but I think
it works when you don't think too much about it.
3. A relative timestamp requires a setInterval with
decreasing interval to keep it up to date.
("A few seconds ago" -> "2 minutes ago", "1h ago", etc)
Bug: T200353
Change-Id: I9058d47645914783227d1520adb78e75399b5504
The change in I1678f7ec broke the workaround in I992aa50f by adding
the rev_id column to the ORDER BY clause. We need to extend the aliasing
to rev_id => revactor_rev to re-fix it.
Bug: T220991
Change-Id: I62dc3803621da982e526d7402ab8e7b08f8336bc
Right now, it uses a deprecated way to set rigor causing it to read from
master on GET, giving out errors
Change-Id: I89bbe20080998bde2156680c631700b52f4e4712
HHVM does not support variadic arguments with type hints. This is
mostly not a big problem, because we can just drop the type hint, but
for some reason PHPUnit adds a type hint of "array" when it creates
mocks, so a class with a variadic method can't be mocked (at least in
some cases). As such, I left alone all the classes that seem like
someone might like to mock them, like Title and User. If anyone wants
to mock them in the future, they'll have to switch back to
func_get_args(). Some of the changes are definitely safe, like
functions and test classes.
In most cases, func_get_args() (and/or func_get_arg(), func_num_args() )
were only present because the code was written before we required PHP
5.6, and writing them as variadic functions is strictly superior. In
some cases I left them alone, aside from HHVM compatibility:
* Forwarding all arguments to another function. It's useful to keep
func_get_args() here where we want to keep the list of expected
arguments and their meanings in the function signature line for
documentation purposes, but don't want to copy-paste a long line of
argument names.
* Handling deprecated calling conventions.
* One or two miscellaneous cases where we're basically using the
arguments individually but want to use them as an array as well for
some reason.
Change-Id: I066ec95a7beb7c0665146195a08e7cce1222c788
This will allow us to treat the request to the temp
container as securely as those on a private wiki.
Bug: T220265
Change-Id: I43a7212481665e05ae23c44ab1788d8988b80a4b
This is to make phan-taint-check happy. Technically this is
a breaking change, but I am unaware of any extensions actually
having their names be arbitrary html, and support for this
is not documented anywhere.
Bug: T216348
Change-Id: I065d7e57f36e079e0b02180379e2df1f8535f3a8
* Title: phan false positive
* McrUndoAction: fixed improper use of @param
* UploadSourceAdapter: fixed wrong type
* XmlTypeCheck: Use null so phan doesn't think we're trying to call the
function ''
* Database: phan false positive
* SpecialBlock: Use phan's advanced type documentation so phan knows
specifically what's being returned
* ChangesListSpecialPage: phan false positive
* BatchRowUpdate: Have default callback take a parameter so phan doesn't
think too many arguments are being passed
* MimeAnalyzer: left FIXME for relying on PHP 7.1 unpack() signature
* LanguageConverter: Specify types for $mTables since phan couldn't
determine it automatically
* preprocessorFuzzTest: Implement User::load() method signature
Change-Id: I08080ab636c5fe67ea6a4e14b2212d7523606e21
Certain groups of widgets always exist if the form is loaded, or always exist
if partial blocks is enabled. Others depend on certain user rights or config
variables. Check these widgets in groups rather than checking for the
existence of each one individually.
Change-Id: I6950ebc22f4564aadaf6d6acd5ca36534d8b9962
wpCreateAccount default is dynamically changed if the user
has not posted the form or interacted with the field in any way
Bug: T218554
Change-Id: Ied68dc60d57ed35ed3285c5cf89b772c8c4e41d1
