Deprecate the second argument to Maintenance::error() in favor of a new
Maintenance::fatalError() method. This is intended to make it easier to
review flow control in maintenance scripts.
Change-Id: I75699008638f7e99b11210c7bb9e2e131fca7c9e
The used phpcs has a bug, so the version 0.9.0 could not be enforced at the moment.
Will be fixed in next version, see T167168
Changed:
- Remove duplicate newline at end of file
- Add space between function and ( for closures
- and -> &&, or -> ||
Change-Id: I4172fb08861729bccd55aecbd07e029e2638d311
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
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
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
Versioning the extension.json schema will allow us to make breaking changes
to the schema in a non-breaking manner.
Extensiosn and skins will set a 'manifest_version' value, stating which
version of the schema the file is written for. Processor::extractInfo() will
be passed the version number, and can switch behavior depending upon it.
For backwards-compatability, a version number of 1 is assumed if none is set.
The validateRegistrationFile.php script will emit a warning if this is the
case.
Bug: T99344
Change-Id: I2086a1465ceaeedd1ccc6804fda2c304ad16ffa0
Introduces wfLoadExtension()/wfLoadSkin() which should be used in
LocalSettings.php rather than require-ing a PHP entry point.
Extensions and skins would add "extension.json" or "skin.json" files
in their root, which contains all the information typically
present in PHP entry point files (classes to autoload, special pages,
API modules, etc.) A full schema can be found at
docs/extension.schema.json, and a script to validate these to the
schema is provided. An additional script is provided to convert
typical PHP entry point files into their JSON equivalents.
The basic flow of loading an extension goes like:
* Get the ExtensionRegistry singleton instance
* ExtensionRegistry takes a filename, reads the file or tries
to get the parsed JSON from APC if possible.
* The JSON is run through a Processor instance,
which registers things with the appropriate
global settings.
* The output of the processor is cached in APC if possible.
* The extension/skin is marked as loaded in the
ExtensionRegistry and a callback function is executed
if one was specified.
For ideal performance, a batch loading method is also provided:
* The absolute path name to the JSON file is queued
in the ExtensionRegistry instance.
* When loadFromQueue() is called, it constructs a hash
unique to the members of the current queue, and sees
if the queue has been cached in APC. If not, it processes
each file individually, and combines the result of each
Processor into one giant array, which is cached in APC.
* The giant array then sets various global settings,
defines constants, and calls callbacks.
To invalidate the cached processed info, by default the mtime
of each JSON file is checked. However that can be slow if you
have a large number of extensions, so you can set $wgExtensionInfoMTime
to the mtime of one file, and `touch` it whenever you update
your extensions.
Change-Id: I7074b65d07c5c7d4e3f1fb0755d74a0b07ed4596
