It seems some tests are fixed in the meantime without removing the
skipped part for this.
Bug: T195807
Follow-Up: I58261dd70eea3581803987a4a7739c7d55558f42
Change-Id: Ie883b7056cdd0cb6bec81c2f7e4ed54177b4ecb2
Add a new helper to MediaWikiIntegrationTestCase, since deleting pages
seems to be pretty common in tests.
Some calls to WikiPage::factory were also updated to use WikiPageFactory.
Change-Id: I5b5100273a00ac292a1900022ca79708fa254347
Enable specifying type=* to fetch tokens of all available types.
This enables bot libraries/frameworks to avoid querying ApiParamInfo first to know about types of available tokens.
Bug: T290838
Change-Id: Icf2ad3dfe00ca27aaf92cdc5152342fed38d678e
The value in the attribute displaytitle must contain valid HTML. The
sanitizer of the {{DISPLAYTITLE}} parser ensures that only valid HTML
is accepted.
If there is no {{DISPLAYTITLE}} in the wikitext then displaytitle
falls back to $title->getPrefixedText(). Here an HTML encoding of
special characters is necessary. This affects only the replacement of
& by & because other special characters like < and > are not
allowed in the title.
This change affects the displaytitle fallback on the following places:
* ApiParse
* ApiQueryInfo
* InfoAction
* Parser
The displaytitle fallback in OutputPage is also updated to this
behavior although
Sanitizer::normalizeCharReferences( Sanitizer::removeHTMLtags( $html )
also replaces & by &.
Also add test cases with & in the displaytitle to:
* ApiParseTest
* ApiQueryInfoTest
* parserTests
Bug: T291985
Change-Id: I8ee1e2731d9bfa49725d663b34986e7e3073e4ca
Since $wgSkipSkins is meant to only 'remove skin from preferences',
it should not affect parsing with them.
So these skins need to be allowed here.
To achive this, this patch adds getInstalledSkins() method to SkinFactory
to provide the complete. The method supersedes getSkinNames() which does
the same thing but with ambiguous name.
Description of getAllowedSkins() has been corrected as it was slightly incorrect.
Bug: T237856
Change-Id: I0889b823d27f1a2830cc0205f5a21ed4de744e08
The difference is that previously we used microtime(), which provides a
float, and now time() is used, which provides an int, but there is no
difference for the comparison.
Change-Id: If1463e0fc2a2526ab4d2af64830b73ae3bf330f6
No need to manually reset MWTimestamp fake time,
MediaWikiTestCaseTrait::fakeTimestampTearDown() does
that after all tests anyway.
Change-Id: Ie45e837c693d7f21b6c7e25471cdaad6f60a3de9
Returns the prefixed title for the associated page,
if it could exist (i.e. does not do anything for special pages)
Bug: T257014
Change-Id: I49cdc138c6182b323c4933e90dc96c5e06b6ccba
Results in passing a user where previously the fallback
to $wgUser was being used, mostly in tests.
Bug: T255507
Change-Id: Iabe24315b23c0ad1272353186425e71974528d23
array_fill_keys() was introduced in PHP 5.2.0 and works like
array_flip() except that it does only one thing (copying keys) instead
of two things (copying keys and values). That makes it faster and more
obvious.
When array_flip() calls were paired, I left them as is, because that
pattern is too cute. I couldn't kill something so cute.
Sometimes it was hard to figure out whether the values in array_flip()
result were used. That's the point of this change. If you use
array_fill_keys(), the intention is obvious.
Change-Id: If8d340a8bc816a15afec37e64f00106ae45e10ed
This test failed by default in mediawiki-docker-dev or on any other
more (production-like) set up with a protocol-relative $wgServer value.
It passed in CI where it is set to `http://localhost:9412`.
The test also failed when $wgFileExtensions contained additional
entries for any reason.
Fix both of these tests by simplifying their needless inheriting of
live "current" settings and just set them to explicit example values
and them assert the way the code should behave for those values.
Follows-up 27d41f442a.
Remove use of wfExpandUrl() to formulate the "expected" value.
Expected values that are dynamic are an anti-pattern and greatly
decrease confidence in, and self-documenting value of, a test.
Change-Id: I6f7b8d89767ed8eaacbc615a9f22a3b357a6dd58
When block restrictions are queried from the API, return the name
of the action blocked
Bug: T280566
Change-Id: I2e639864cfcdd3854fd67173b138fe8eb6f877cb
Replacing the mock InterwikiLookup used in
MediaWikiTitleCodecTest revealed that that test was,
because of the mock not behaving correctly, testing the
wrong thing - interwiki prefixes are *not* case sensitive,
and are always converted to lowercase in the actual
ClassicInterwikiLookup. Fixed those expectations.
Change-Id: I242431e88860b7700a9f93f77a0fe195fd748800
This adds a new type of block restriction for actions, which extends
AbstractRestriction. Like page and namespace restrictions, action
restrictions are stored in the ipblocks_restrictions table.
Blockable actions are defined in a BlockActionInfo service, with a
method for getting all the blockable actions, getAllBlockActions.
Action blocks are checked for in PermissionManager::checkUserBlock
using DatabaseBlock::appliesToRight. To make this work, this patch
also removes the 'edit' case from AbstractBlock::appliesToRight,
which always returned true. This was incorrect, as blocks do not
always apply to edit, so cases that called appliesToRight('edit')
were fixed before this commit. appliesToRight('edit') now returns
null (i.e. unsure), which is correct because it is not possible to
determine whether a block applies to editing a particular page
without knowing what that page is, and appliesToRight doesn't know
that page.
There are some flags on sitewide blocks that predate partial blocks,
which block particular actions: 'createaccount' and 'sendemail'.
These are still handled in AbstractBlock::appliesToRight, and are
still checked for separately in the peripheral components.
The feature flag $wgEnablePartialActionBlocks must set to true to
enable partial action blocks.
Bug: T279556
Bug: T6995
Change-Id: I17962bb7c4247a12c722e7bc6bcaf8c36efd8600
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
The timestamp in the year 3030 was presumably chosen so as to
always be in the future (since expiry in the past would be ignored).
However, while seemingly clever, this backfires because it gets
shrunk by the default wgWatchlistExpiryMaxDuration value to some
time in August 2021, around the "current" time of day.
And "current" generally is thought of as moving forward at a rate
of 1s/s, bending of spacetime notwithstanding. Thus the test would
sometimes fail in ways such as:
> 1) ApiQueryInfoTest::testExecute
> Failed asserting that two strings are identical.
> --- Expected
> +++ Actual
> @@ @@
> -'2021-08-13T01:23:19Z'
> +'2021-08-13T01:23:18Z'
Fix this by using a mock current time, paired with a suitable
max duration and expiry value.
Also fix some of the other asserted values to not be reflections
of the source code but actually explicit assertions (at least the
details that we know to be constant, given the environment ensured
by ApiTestCase and MediaWikiLangTestCase). This reduces the chances
of false positives from looking at itself too much, and also speeds
up the test a little.
Change-Id: If361aa98bef789b1f841741a7c83bcb2ac9edf05
This is micro-optimization of closure code to avoid binding the closure
to $this where it is not needed.
Created by I25a17fb22b6b669e817317a0f45051ae9c608208
Change-Id: I0ffc6200f6c6693d78a3151cb8cea7dce7c21653
The code didn't properly handle requests for info about non-existing
pages.
Bug: T271804
Bug: T271815
Change-Id: If4e56ff5ecb4a048767833c89847bb58269cad43
The expiry is returned as a separate key, 'watchlistexpiry', to match
other APIs, and because some clients might expect 'watched' to be a
boolean (or blank string depending on the formatversion).
Bug: T268834
Change-Id: I227d6ed42e70ba1ddec0139e8198f536dfba0b46
The InterwikiLoadPrefix hook isn't compatible with Parsoid, as it is
unidirectional and doesn't support enumerating all valid prefixes
(T270444). Set/reset $wgInterwikiCache to mock the interwiki table
for parserTests and other unit tests instead.
This is a soft deprecation, as the used-in-production
Extension:Interwiki still uses InterwikiLoadPrefix, although not in a
way that would break Parsoid (since $wgInterwikiCache is set in
production).
Bug: T270444
Change-Id: If2507017c99c4ee42c104a0890bc45a84d7239d5
Several important extensions (Disambiguator, ProofreadPage, and
SoftRedirector) use the GetLinkColours hook to add additional CSS
classes to links on article pages. Parsoid previously relied on
backdoor knowledge of the way Disambiguator used the page property
table to support these, but they should be exported properly from the
API.
Bug: T237538
Change-Id: I945940aa872541d7e01f1e543ca854231c857fe2
Consistency aside, this is useful for grouping more tests
into separate threads when using directory based suites.
Bug: T50217
Change-Id: Ife9acd5990c4ae4a5fc18371559e93d7d86fb57d
The name change happened some time ago, and I think its
about time to start using the name name!
(Done with a find and replace)
My personal motivation for doing this is that I have started
trying out vscode as an IDE for mediawiki development, and
right now it doesn't appear to handle php aliases very well
or at all.
Change-Id: I412235d91ae26e4c1c6a62e0dbb7e7cf3c5ed4a6
There is native support for all of this now in PHP, thanks to changes
and additions that have been made in later versions. There should be no
need any more to ever use call_user_func() or call_user_func_array().
Reviewing this should be fairly easy: Because this patch touches
exclusivly tests, but no production code, there is no such thing as
"insufficent test coverage". As long as CI goes green, this should be
fine.
Change-Id: Ib9690103687734bb5a85d3dab0e5642a07087bbc
Accidentally broken by I991809acf.
Also added a test that should hopefully prevent this from accidentally
being broken again.
Bug: T245149
Change-Id: Ia7985397db50efe8af81f643f2a0a89d0ece179e
Done automatically using the master version of MW codesniffer and
running composer fix.
Bug: T192167
Change-Id: If6b40f515fde32ab5eff074a90e821c30c791827
Add public, protected or private to function missing a visibility
Enable the tests folder for the phpcs sniff
Change-Id: Ibefce76ea9984c47e08c94889ea2eafca7565e2c
This removes most of the pre-actor user and user_text columns, and the
$wgActorTableSchemaMigrationStage setting that used to determine
whether the columns were used.
rev_user and rev_user_text remain in the code, as on Wikimedia wikis the
revision table is too large to alter at this time. A future change will
combine that with the removal of rev_comment, rev_content_model, and
rev_content_format (and the addition of rev_comment_id and rev_actor).
ActorMigration's constructor continues to take a $stage parameter, and
continues to have the logic for handling it, for the benefit of
extensions that might need their own migration process. Code using
ActorMigration for accessing the core fields should be updated to use
the new actor fields directly. That will be done for in a followup.
Bug: T188327
Change-Id: Id35544b879af1cd708f3efd303fce8d9a1b9eb02
T208768 introduced the PermissionManager service that can now be used
for page specific permission checks. This change replaces calls to
Title::userCan() with the new service in API classes.
Bug: T220191
Change-Id: I768d07a520ca6473a4eefb88c9f587657bc74357
Probably good to start testing this in CI sometime soon.
This also updates a bunch of tests that were forcing an older stage to
force SCHEMA_COMPAT_NEW instead, or to test both ways (until a future
patch removes the _OLD version).
Bug: T188327
Change-Id: Icb9b55cb9d754f2d30d6883005658b9670834756
Field rev_text_id will no longer be populated once the legacy
schema is disabled, so joins against it will not work.
Remove all usages of the 'text' flag in calls to both
Revision::getQueryInfo() and RevisionStore::getQueryInfo()
so that these joins are no longer attempted.
Bug: T198342
Change-Id: I9be6a544c6f68555d4ea856f949f0040d05eac0f
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
When this was originally written, the plan was to read both the old and
new fields during the transition period, while stopping writes to them
midway through. It turns out that the WHERE conditions to do read-both
correctly are generally not handled well by the database and working
around that would require a lot of complicated code (see what's being
removed from ApiQueryUserContribs here, for example).
We can simplify things greatly by instead having it write both fields
during the transition period, reading from the old for the first part
and the new for the second part, as is being done for MCR.
Bug: T204669
Change-Id: I4764c1c7883dc1003cb12729455c8107319f70b1
Depends-On: I845f6ae462f2539ebd35cbb5f2ca8b5714e2c1fb
Depends-On: I88b31b977543fdbdf69f8c1158e77e448df94e11
So we can make the job voting, preventing other tests from regressing.
These tests can be re-enabled whenever they're made to pass.
Change-Id: I959710138e1e1b37b6ba69561c2920a78208bf12
MCR deprecated the Revision class in favor of the broadly similar
RevisionRecord, and more interestingly added the concept of multiple
content "slots" to revisions.
Thus, prop=revisions, prop=deletedrevisions, and so on gain a parameter
to specify which slots are wanted. When this new parameter is not
specified (and any content-related props are specified), a warning about
the legacy format will be issued.
The rest of the modules just needed to call methods or use constants on
RevisionRecord instead of Revision. ApiQueryDeletedrevs wasn't touched,
since it has been deprecated since 1.25 anyway.
This also updates a few non-query modules that don't depend on details
of editing, diffing, or viewing MCR revisions that haven't been figured
out yet.
Bug: T200568
Change-Id: I1327d1784f5cedb006cd74df834cf9a560a77a5d
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
Storing the user name or IP in every row in large tables like revision
and logging takes up space and makes operations on these tables slower.
This patch begins the process of moving those into one "actor" table
which other tables can reference with a single integer field.
A subsequent patch will remove the old columns.
Bug: T167246
Depends-On: I9293fd6e0f958d87e52965de925046f1bb8f8a50
Change-Id: I8d825eb02c69cc66d90bd41325133fd3f99f0226
This allows to response with an invalidreason instead silently ignore
the parameter.
Example request: api.php?format=json&action=query&titles=%20
Response before this change:
{
"batchcomplete": ""
}
Response with this change:
{
"batchcomplete": "",
"query": {
"pages": {
"-1": {
"title": " ",
"invalidreason": "The requested page title is empty or contains only the name of a namespace.",
"invalid": ""
}
}
}
}
Bug: T185846
Change-Id: I6fdaf32792a0e6e37b08176f975c10607093351b
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
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: I46261416f7603558dceb76ebe695a5cac274e417
Tests were failing if class cannot be loaded using `\AutoLoader` but can be loaded by composer's autoloader.
Change-Id: I005c9d99245f4733a9666c4bfe9e39baeaad3960
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
If a client submits data that is not NFC-normalized Unicode or that
contains C0 controls other than HT, LF, and CR, it gets normalized before
the API ever sees it. Which can lead to difficult-to-handle bugs when,
for example, a title is subject to normalization so the client can't
find the specific title it submitted anywhere in the response (T139130).
This patch does two things:
* Detects when normalization was applied to an input value (at the
MediaWiki level, anyway; if PHP or earlier does it we're just out of
luck) and add a warning to that effect.
* For ApiPageSet's 'titles' parameter, split into the individual titles
and add them to the 'normalized' list in the response. This requires
encoding the pre-normalized strings to avoid ApiResult's own
normalization.
Bug: T29849
Bug: T144071
Change-Id: I215fd3edd7a5e1b45292e60768bf6dd5ad7f34de
