Follows-up I1343872de7, Ia533aedf63 and I2df2f80b81.
Also updated usage in text in documentation and the
installer LocalSettingsGenerator.
Most of them were handled by this regex:
- find: (require|include|require_once|include_once)\s*\(\s*(.+?)\s*\)\s*;$
- replace: $1 $2;
Change-Id: I6b38aad9a5149c9c43ce18bd8edbab14b8ce43fa
Squiz.WhiteSpace.LanguageConstructSpacing:
Language constructs must be followed by a single space;
expected "require_once expression" but found
"require_once(expression)"
It is a keyword (e.g. like `new`, `return` and `print`). As
such the parentheses don't make sense.
Per our code conventions, we use a space after keywords like
these. We appeared to have an unwritten exception for `require`
that doesn't make sense. About 60% of require/include usage
was missing the space and/or had superfluous parentheses.
It is as silly as print("foo") or return("foo"), it works
because keywords have no significance for whitespace between
it and the expression that follows, and since experessions can
be wrapped in parentheses for clarity (e.g. when doing string
concatenation or mathematical operations) the parenthesis
before and after basiclaly just ignored.
Change-Id: I2df2f80b8123714bea7e0771bf94b51ad5bb4b87
Also update some previous inconsistencies pointed out by Krinkle in change IDs:
* Ide20743a2e84ff68549286120e6cff9d9f396f54
* I811ca957b6588085d67606ebc0cd4033a1e53839
Change-Id: Ife33b931870d0d7e04fcb40974997436d27f528f
Greatly simplifies query result iteration by the clients
by providing a mechanism to track sub-iterations (props in generated set)
Assuming the client has the param=>value dictionary with the original request
parameters, client will only need to perform this operation in their language
to get all results from the server regardless of what query they make.
$request = array_merge( $request, $result['continue'] );
Related changes:
* Moved dieContinueUsageIf() from ApiQueryBase to ApiBase
* Internal calls will also return unused param warnings
* Reworked query unit tests for easier testing
Change-Id: Ieb45241fc6db2109f1d92fa3381165ec30701b63
ApiAccountCreationTest::testInvalidEmail() no longer
needs LocalSettings to have $wgEnableEmail = true;
Change-Id: I97803be116fda8194e46fe0021c7b32d7b703b1d
This need to be made a global feature that will be applied to any test.
This reverts commit 2025a89d5b
Change-Id: Ia7165b78b4f80738ed9b769319e159cd86fc7bdf
· Use env(1) in shebangs instead of hardcoding paths.
· $IP is already set in the constructor of Maintenance classes.
· Add sapi guard to some phpunit files.
Change-Id: I6c6fd6c61e2861b5992f2ccd67a4e3f62e2c445e
* $wgAPIGeneratorModules is now obsolete and will be ignored
* Removed generator tests - obsolete because there is no more list
Change-Id: I014260a42226854a2178345dc3cd0f50b41b3c08
* PageSet can now be used in any action to process titles/pageids/revids
or any generator, redirects resolution, and converttitle functionality.
* action=purge proper usage of MustBePosted()
* Add supports for all pageset capabilities - generators, redirects, converttitles to
action=purge and action=setnotificationtimestamp
* BREAKING CHANGE: ApiPageSet constructor now has two params instead of three, with only the
first one keeping its meaning. ApiPageSet is now derived from ApiBase.
* BREAKING CHANGE: ApiQuery::newGenerator() and executeGeneratorModule() were deleted.
Change-Id: I7a3d7b6eb015d21ec1a9b9d9c6af9d97663f3f9a
* Several tests to verify query with prop=, list=, and generator
* Moved query related tests to query\ dir
* Added a generic ApiTestCase::editPage() to simplify page creation
* Fixed minor warnings complained by jenkins/phpcs
Change-Id: I5e3984d797178ae03f048792c7bac8e6a881aa41
Fix almost all occurences of the following sniffs:
Generic.CodeAnalysis.UselessOverridingMethod.Found
Generic.Formatting.NoSpaceAfterCast.SpaceFound
Generic.Functions.FunctionCallArgumentSpacing.SpaceBeforeComma
Generic.Functions.OpeningFunctionBraceKernighanRitchie.BraceOnNewLine
Generic.PHP.LowerCaseConstant.Found
PSR2.Classes.PropertyDeclaration.ScopeMissing
PSR2.Files.EndFileNewline.TooMany
PSR2.Methods.MethodDeclaration.StaticBeforeVisibility
Change-Id: I96aacef5bafe5a2bca659744fba1380999cfc37d
All tests based on APITestCase can be slow. I've also seen more than one
Jenkins failure due to GlobalTest::testMerge timing out.
Also, added a meta-test on APITestCase to make sure that all its
subclasses are marked with @group medium or @group large, to prevent new
tests from re-causing the bug.
Change-Id: I48630736a3d06574876fd1fa3d90899cfbc48012
Added the "resetkinds" option to action=options, so that when the
"reset" option is set, the user can control which kinds of options
are reset, rather than having to do all or none.
Also added documentation to the "change" parameter, since passing
it option keys without any "=value" after it will result in resetting
that specific option to its default value.
Change-Id: Id5bc1fffa0d487c0f152b79115205d2722f380d3
Before change I98df55f2 it was possible to set arbitrary preferences (ie.
with anything as the key) using the action=options API. That change
removed this ability by enforcing full validation of the preferences, also
introducing several regressions which were fixed by follow-ups.
Per the discussion on bug 40124, this changeset aims to restore this
ability, but in a slightly restricted way: arbitrary preferences' names
must start with userjs- prefix, to avoid any possibility of conflicting
with new MediaWiki versions or extensions.
The contents of these preferences is not escaped, sanitized nor validated
in any way; script authors are expected to sanitize them themselves to
prevent XSS attacks and other security vulnerabilities.
This commit also adds the User::getOptionsKinds() method (to determine
whether given preference keys are used by MediaWiki itself or an extension,
intended to be used via the API, or entirely unknown) and enhances the
User::resetOptions() method to allow for resetting only preferences of
chosen kinds.
These changes allow for fixing of Special:Preferences not to clear those
additional fields when saving user settings.
Change-Id: I5f9ba5b0dfe7c2ea5458d836f03429cf6d93969d
1) ApiCreateAccountTest::testInvalidEmail
Failed asserting that exception of type "UsageException" is thrown.
Also explicit log out the user
Change-Id: I1d90c2b78bbcef494dc91822feeba37eebb8ca20
The ApiCreateAccountTest::testValid() test does multiple API request
which might end up being a bit slow. That randomly cause random
failures when running the test suite which tends to confuse people.
Change-Id: I35a6670c61c7917522b2472a3a8e782e97e837f4
Created new API action "createaccount" that
allows access to account creation. Takes
username, password, email, realname, token,
and optionally mailpassword and reason.
Errors are given in an errors array. Note
there is no way to natively handle CAPTCHAs
as there is no uniform implementation of
presenting CAPTCHA links to user. Right now
the best an extension can do is return an
error in AbortNewAccount, which will then
be displayed as an error in the Api result.
Change-Id: Ibdb1e50d434fb857683e1e4ff5a4a5a91c6b7c3a
Preferences options using HTMLForm's "multiselect" type are stored in
the user preferences table as one key with a boolean value for each
option in the multiselect. The validation code added in change I98df55f2
does not take this into account, and therefore considers all of these
option keys invalid.
This changeset fixes that, and adds a unit test to verify correct
behavior.
Change-Id: I137c74a6045c7b39e2119a8edde2705738879bc9
Change I98df55f2 broke action=options&reset=1, causing it to return an
error "No changes were requested" rather than resetting the options as
it should. Unfortunately, that change also broke the unit test that
would have caught this regression.
This changeset fixes the bug and the unit tests.
Change-Id: I7fe63640d54efab4572538e9d08f5b75c61243a4
Previously, there was no validation whatsoever and the module would
happily write any preference you asked it to. This, combined with the
fact that the code using the 'editfont' preference didn't perform any
validation or escaping, led to a CSS injection vulnerability.
Using Preferences::getPreferences breaks some existing test cases
because a MockUser doesn't have groups for preferences.
Change-Id: I98df55f2b16ac1b6fce578798b6f58b5dad96775
The edit conflict tests can take quiet a while to execute, definitely
more than the default 2 seconds we allocated to test. Marking the class
with '@group medium', in the comment, instructs PHPUnit to apply a
timeout of 10 seconds.
Change-Id: Icdd78ea43c91eeca7d4a00bfe6bb368bb3b8f891
query=revisions can be used with rvprop=content to retrieve the
content of revisions. The contentmodel should always be included
with the content (just like the contenformat is), so the client
is able to interpret the structure contained in the content blob.
Change-Id: I67cf48f905ff83a86992e1a54f7ad0feaf2b2c94
Changeset Iec98e472 changed the behavior of action=parse&page=... when
passed a page that does not exist: previously, it would return a
"missingtitle" error instead of assuming an empty page. As some people
had been depending on this old behavior, restore the error checking.
Change-Id: I4c76ce458ceb01e233c6074cd9251879013ec143
Before the ContentHandler merge, using action=edit&appendtext=... on a
non-existent page would treat the page as if it existed but had no
content. After the merge, it throws an error incorrectly claiming that
appending is not supported for wikitext.
The fix is to create a new, empty content object when appending and
there is no existing content.
Change-Id: I61f2cf3911a7d9d8553fc3f745e545cb1bcfd270
List of query generators is now not built using reflection, instead it
is defined in code. Per Domas, make this a hard coded list instead of
loading all the child classes.
Added $wgAPIGeneratorModules for people to register their API generator
modules.
Change-Id: I12da92da33527e414c9b125a50b82c9bdbb3ed99
This introduces the ContentHandler facility into MediaWiki,
see docs/contenthandler.txt.
For convenient review, a squashed version is available at
https://gerrit.wikimedia.org/r/27191
The ContentHandler facility is a major building block of the Wikidata project.
It has been discussed repeatedly on wikitech-l.
Change-Id: I3804e2d5f6f59e6a39db80744bdf61bfe8c14f98
