Autoloading classes is a 100% accurate way to ensure the autoloader
worked, but there are cases where if optional dependencies aren't
installed, then autoloading the class will fail. We can re-implement the
logic behind the PSR-4 autoloader, and ensure that classes will be
autoloadable by turning the filename into a class name, and making sure
that class name is the one we found in the file.
Bug: T195823
Change-Id: I5df378180e567c257386482383ef73812592f989
Files like ServiceWiring.php can be safely located in a PSR-4 autoloaded
directory, because they have no classes.
Change-Id: I359b305df9071d6bc5afe4b5f29e762041f4aaef
AutoloaderTest covers the AutoLoader class, and AutoLoaderStructureTest
covers the structure part of the test.
Change-Id: Ic4e7bfd670e1c3413631bda31260cc1cc825b1a2
This ensures that there aren't any classes inside a PSR-4 autoloaded
directory that aren't being autoloaded properly.
Change-Id: I200a8535c2f47a6bf3287a7fe1182151493372f4
With MCR coming up, ApiEditPage is going to need to be able to take
"text" and "contentmodel" parameters for each slot-role, and enumerating
such parameters for every possible slot would probably get rather
confusing as to what is required when, or at least long-winded in
repeating the exact same thing for every possible role.
So let's abstract it: we'll have an "editroles" parameter to specify which
slots are being edited, and ApiEditPage will just declare that
"text-{role}" and "contentmodel-{role}" parameters should exist for each
value of "editroles" in the submission.
Note this patch doesn't introduce anything that uses templated
parameters, just the functionality itself. For testing purposes you
might cherry pick I2d658e9a.
Bug: T174032
Change-Id: Ia19a1617b73067bfb1f0f16ccc57d471778b7361
This makes StructureTest also recognize test classes which look like
use PHPUnit\Framework\TestCase;
class FooTest extends TestCase {
instead of
class FooTest extends \PHPUnit\Framework\TestCase {
This form is preferred, for instance, in Wikibase code.
Bug: T188276
Change-Id: I5bef035df33d317893ad3ba195ecb75f3b09a62f
It is off by default, it's very rarely used (GitHub finds four config
users setting it true), it has over time had fatals going unnoticed or
fixed for years. Let's just kill it.
Change-Id: Idac2341ed7ecf053ee84069df657e424e50b896c
This adds support for a PSR-4 (<http://www.php-fig.org/psr/psr-4/>)
autoloader, so instead of needing to manually list each class, just the
namespace prefix is needed.
Extensions can set a "AutoloadNamespaces" property in extension.json to
register PSR-4 compatible namespaces to be autoloaded.
The implementation is based off of the example implementation
(<http://www.php-fig.org/psr/psr-4/examples/>) with some modifications
for performance, notably cutting down on function calls, and only trying
to look up classes that are namespaced.
The generateLocalAutoload.php script will ignore any directory that is
registered as a PSR-4 namespace.
Bug: T99865
Bug: T173799
Change-Id: Id095dde37cbb40aa424fb628bd3c94e684ca2f65
Adds two new ApiBase::getAllowedParams() keys:
PARAM_MAX_BYTES and PARAM_MAX_CHARS, to set a length
limit for a (string-like) parameter.
This makes it easy to document and enforce database
field length limits (where relying on the database
would either result in unfriendly error messages or
silent truncation, depending on DB settings) and
also exposes them in structured form so API clients
can verify the length without doing roundtrips.
Change-Id: I2e784972d7e11cad79fdef887bbcde297dbd9ce0
* Use getStartupModules() instead of hardcoding these two module names.
* Also collect any other module that is registered with raw=>true.
Change-Id: I5f75cc8f99b90f58d76b7e87f068f50f9f608ed0
Adds two new parameter settings, ApiBase::PARAM_ISMULTI_LIMIT1
and PARAM_ISMULTI_LIMIT2 for configuring the maximum number of values
that can be contained in a multivalue field (for unprivileged and
apihighlimits users, respectively). When present, these replace the
default 50/500.
Change-Id: Ic1b1bcc7ff556b7762c8d2375d910cc4fcb43087
* Move DatabaseTest and DatabaseSQLTest to libs,
and remove MediaWikiTestCase dependency.
* Refactor DatabaseTest to be a test of the Database abstract class,
not of whatever current DB backend is configured by LocalSettings.
- Remove most switches/conditionals and other tests for specific
database backends. Move those to individual test classes for
those backends instead.
- Some tests appear to have been integration tests for the PHP driver
and/or the db backend itself. Moved to a new DatabaseIntegrationTest.
- Now that only the abstract Database is invoked, the test runs a bit
faster (no real connections/queries).
* Add missing @covers tags, and remove or fix broken ones
(follows-up 26e52f0c49).
Change-Id: I9dc4a558e701d00e95789e7eb8e02926783b65ad
To fix T123930, it would be very handy to have the summary for each
module without any of the additional explanatory text.
Bug: T166411
Change-Id: I778bab2b87971875aed4c804341ad59c1c6e021f
Replaces \TestingAccessWrapper (defined in core) with
\Wikimedia\TestingAccessWrapper (defined in the composer package
wikimedia/testing-access-wrapper).
See https://gerrit.wikimedia.org/r/#/q/topic:librarize-testing-access-wrapper
for downstream patches.
The core version of the class is kept around for a while to avoid
circular dependency problems.
Bug: T163434
Change-Id: I52cc257e593da3d6c3b01a909e554a950225aec8
Validating this should be as simple as it can be: if the tests run,
this change should be fine. :-)
Change-Id: I8e4a3dfc83fdc9b8c8d7f5bbd067e088ebd2133d
This is a pure documentation change. It mostly removes empty lines from
comments (and entirely empty comments), as well as adds a few missing
documentation blocks and fixes a minor mistake. I hope it's ok to have
this in one patch. I can split it, please tell me.
Change-Id: I9668338602ac77b903ab6b02ff56bd52743c37c4
Previously, logic to validate extension.json files was in two places:
validateRegistrationFile.php maintenance script, and the
ExtensionJsonValidationTest.php structure test. This caused duplication
as validation became more complex (e.g. usage of spdx-licenses library).
A generic ExtensionJsonValidator class now handles most of the
validation work, while the maintenance script and test case just wrap
around it for their output formats.
Change-Id: I47062a4ae19c58ee1b1f2bb4877913259bf19c8b
Assert that they don't begin with 'api.php?'.
Change-Id: Idf5e8e08863a379a37a427a11936e5f9ce567396
Depends-On: I8a82eecefbb0ba327d8e8bc24ec535bcf40e6429
Depends-On: I476aad09655a2822381a2c61690b4b0ad423151e
This fixes the outstanding mis-spaced cast operators to bring them
into line with the coding standards on mediawiki.org (and with the
more common usage within this codebase).
Bug: T149545
Change-Id: Ib7bcf95bbee83d20c05f6d621ce7b4e1fb58a347
Our hardcoded enum list in the extension.json schema for license-name
values was incomplete and did not cover the full SPDX license identifier
specification, which includes things like "AND" for specifying multiple
licenses.
Composer already has solid code in a library to do this validation, so
let's use it! This updates both the validateRegistrationFile.php and
ExtensionJsonValidationTest.php to use the composer/spdx-licenses
library (a new development dependency) to ensure the license-name field
is a valid SPDX identifier.
Also fix a silly typo in the validateRegistrationFile script which
prevented it from running, and use ::class so it will be easier to
detect typos like that in the future.
Bug: T146862
Change-Id: Ibb8973ed7950ae81c90558f9630f73746b2aff2c
This adds a structure test that verifies all registered ContentHandlers
will return a valid content object (as determined by
Content::isValid()), when makeEmptyContent() is called. Additionally, if
the handler extends TextContentHandler, it will verify it is an instance
of TextContentHandler::getContentClass().
This is a structure test so it is run for content handlers created by
extensions as well.
Change-Id: Idd67d824f2f7cc1819b1d8b186be058e63c4513d
The release between 1.6.1 and 3.0.0 has a huge amount of code
maintenance changes, as well as internal optimization and some
"visible" changes (as well as the one mentioned in the linked
task).
However, it's a version jump over 2 major versions, which is,
by it's definition a major change ;). Nonetheless, the (for us)
important api has changed marginally: Instead of using the
JsonSchema\Uri\UriRetriever class to retrieve the schema, we now use
the $ref keyword to reference the json schema file (which also is
an internal optimization). In this way, we let the json-schema library
decide, how to resolve a ref (and the schema) instead of relying
on the UriRetriever api to be public and stable.
The versions also include various bug fixes (which, as far as I know,
doesn't apply to us).
I tested this change with various combinations of valid and invalid
extension.json schemas (version 2 as well as version 3). Given that
there were no major changes to the schema interpretation itself, and
the good test coverage of the library, there shouldn't be a high risk
because of this change.
The full list of changes can be found at:
https://github.com/justinrainbow/json-schema/compare/1.6.1...3.0.0
as well as the changelogs of the single versions:
https://github.com/justinrainbow/json-schema/releases
Bug: T141281
Depends-On: I5687286da9f7fa2bb2b84699fa43ab3c2547fe03
Change-Id: Ie37e2ebc48684783abf8d99d2f775ee6a5988da7
If a class is added manually to the autoload.php another run of
the maintenance script will probably add unnecessary noise to
another change. The added structure test checks, if the output of
the maintenance script equals to the contents of the commited
autoload.php.
Bug: T121921
Change-Id: I3a426b92892f4c00cab33a13f6a717751120367c
SHA-1 is not secure enough to be used as a cryptographic hash function, and its
implementation in JavaScript is too long and too slow for it to be a good
general-purpose hash function. And we currently throw away most of the work:
SHA-1 produces 160-bit hash values, of which we keep 48.
Although the JavaScript implementation is not exported, SHA-1 is a well-known
hash function, and I'm willing to bet that sooner or later someone will move to
make it accessible to other modules, at which point usage will start to spread.
For ResourceLoader, the qualities we're looking for in a hash function are:
* Already implemented in PHP
* Easy to implement in JavaScript
* Fast
* Collision-resistant
The requirement that hashes be cheap to compute in JavaScript narrows the field
to 32-bit hash functions, because in JavaScript bitwise operators treat their
operands as 32 bits, and arithmetic uses double-precision floats, which have a
total precision of 53 bits. It's possible to work around these limitations, but
it's a lot of extra work.
The best match I found is the 32-bit variant of FNV-1, which is available in
PHP as of version 5.4 (as 'fnv1a32'). The fnv132 JavaScript function is
around ten times faster and eight times shorter than sha1.
Change-Id: I1e4fb08d17948538d96f241b2464d594fdc14578
Adds a structure test to validate that all loaded extension.json and
skin.json files validate against the schema at
docs/extension.schema.json.
Bug: T128307
Change-Id: I2fd1caaa50c288821ab6847dc29d60e6554d9df5
Follows-up 8f5cd11d82.
The old getLocalFileReferences() method is no longer used anywhere.
Remove it and rename getAllLocalFileReferences back to it.
Change-Id: I864258aad128ba9b54464c7bc854543f2937f977
AutoLoaderTest didn't know about traits.
generateLocalAutoload found a missing Trait from the autoloader and
a class map ordering issue.
Change-Id: I34bf2698ad838b6a977c9bf39f6e416330ff0e5d
For some reason the unit testing infrastructure doesn't set one, and
that makes RequestContext warn.
Bug: T125491
Change-Id: I3e0ec0f567dd06231bca0d3d923e9d4e05ef5514
Reverting for now in the sake of productivity and restoration of
the passing unit test status of extensions' master branches.
Would recommend re-applying when the CI gate extensions are
passing and ideally some notification ahead of time to wikitech-l.
This reverts commit 0d3712dd60.
Change-Id: I9142e6161257459cd11db0ca4cdd57793cfee8fa
It's not perfect since module i18n can vary on configuration, but it
should catch many cases of forgotten i18n.
Change-Id: Ida7e5720fe304c5168fe752b1b5485fe4cb2cb45
Depends-On: I4a0a6c47afdd62e1c9d0b29f066d2a6d1791b52d
Depends-On: I378d112a36c0981ac8d5366e3e1805ead71a85c8
Depends-On: If9e1ae5f1e360385e70bd68ec9847230bd274d9d
Depends-On: If2694de72a62e46cfdc29401c4d2d3756897c998
* Remove ResourceLoaderFileModule::getLessCompiler(). There is no reason for a
module to need to get a compiler in a different manner than
ResourceLoader::getLessCompiler().
* Add ResourceLoaderModule::getLessVars(). This method provides a means for
subclasses to easily inject custom LESS variables. The default implementation
simply returns an empty array.
* Make the $context parameter for ResourceLoaderFileModule::readStyleFiles()
non-optional (via graceful deprecation). The only callers I found were either
already calling it with a ResourceLoader context, or had a perfectly usable
ResourceLoaderContext in local scope.
* Make ResourceLoaderFileModule::{readStyleFile,getLessCompiler} require a
context. These methods are protected, so I didn't bother with a deprecation.
* Call ksort() on the LESS variables array in the only place it matters -- when
hashing its serialized representation to construct a cache lookup key. This
relieves getLessVars() subclasses from having to remember to re-sort the
variables array if they modify it.
* These changes make it possible to substantially simplify
ResourceLoaderEditToolbarModule, because the only thing it needs to do now is
implement its own getLessVars() method.
* This also allows it to be versioned like any other ResourceLoaderFileModule,
rather than having to use enableModuleContentVersion().
Change-Id: Ic3eab71691e502bfe19bdf4eb6f82cc679a7782f
Change I5a3cdeb7d53485f161ccf8133e76850cdf5b4579 introduced tests
for existence of all local files referenced in CSS. It's currently
failing changes even when the referenced files have been commented
out. This change ensures that commented-out files are not included
in the testing list.
Change-Id: I2ad74c13a9cf36e96a7d7451bf229856bcd18422
The way this is implemented is really dirty... but it found us
a few pre-existing bugs already (T111518, T111519, T111771).
I think it might be worth it.
* CSSMin: Add new method getAllLocalFileReferences() which skips the
file_exists() check.
* ResourceLoaderModule: Make use of it to track missing files too.
* ResourcesTest: Verify that the missing files are missing.
Change-Id: I5a3cdeb7d53485f161ccf8133e76850cdf5b4579
