aboutsummaryrefslogtreecommitdiffstats
path: root/maintenance/validateRegistrationFile.php
Commit message (Collapse)AuthorAgeFilesLines
* add `use MediaWiki\Maintenance\Maintenance` to some maintenance classesNovem Linguae2024-12-051-0/+1
| | | | | | | | | this patch changes P–Z. still need to do subfolders in one file, I also deleted an errant line break that was disconnecting the class docblock from the class. Change-Id: I3b60c2a5817f12c47490e78e36cc18bfeeb98af9
* Exclude boilerplate maintenance code from code coverage reportsDreamy Jazz2024-08-271-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | Why: * Maintenance scripts in core have bolierplate code that is added before and after the class to allow directly running the maintenance script. * Running the maintenance script directly has been deprecated since 1.40, so this boilerplate code is only to support a now deprecated method of running maintenance scripts. * This code cannot also be marked as covered, due to PHPUnit not recognising code coverage for files. * Therefore, it is best to ignore this boilerplate code in code coverage reports as it cannot be marked as covered and also is for deprecated code. What: * Wrap the boilerplate code (requiring Maintenance.php and then later defining the maintenance script class and running if the maintenance script was called directly) with @codeCoverageIgnore comments. * Some files use a different boilerplate code, however, these should also be marked as ignored for coverage for the same reason that coverage is not properly reported for files. Bug: T371167 Change-Id: I32f5c6362dfb354149a48ce9c28da9a7fc494f7c
* Add MediaWiki\Registration namespace to registration classesEbrahim Byagowi2024-08-101-0/+3
| | | | | Bug: T353458 Change-Id: Ifa3b6a6e0353bb4ce21a3f4456f1fc696c8d377c
* Remove "Squiz.WhiteSpace.FunctionSpacing" from phpcs exclusionsReedy2019-05-111-0/+1
| | | | Change-Id: I78b3315f26ab91b6b443f5b028a635552f82f5a3
* validateRegistrationFile: Accept glob patternsKunal Mehta2019-03-021-7/+13
| | | | | | | | I've had this locally for a while now - it makes it easier to validate all extension.json files that you might have checked out. The only catch is that you have to escape the glob pattern from your shell. Change-Id: Ic220034574129fab9e850f91c05dbd5e241f556c
* Use ::class to resolve class names in maintenance scriptsUmherirrender2018-01-231-1/+1
| | | | | | | This helps to find renamed or misspelled classes earlier. Phan will check the class names Change-Id: I1d4567f47f93eb1436cb98558388e48d35258666
* Maintenance: add fatalError() methodBryan Davis2017-11-211-2/+2
| | | | | | | | 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
* build: Prepare for mediawiki/mediawiki-codesniffer to 0.9.0Umherirrender2017-06-261-1/+1
| | | | | | | | | | | | 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
* registration: Refactor validation logic to avoid duplicationKunal Mehta2016-11-301-60/+9
| | | | | | | | | | | | | 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
* Remove spaces after cast operatorsSam Wilson2016-10-311-1/+1
| | | | | | | | | 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
* registration: Improve license-name validationKunal Mehta2016-09-281-3/+25
| | | | | | | | | | | | | | | | | | | | 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
* Upgrade justinrainbow/json-schema to ~3.0Florian Schmidt2016-08-231-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix whitespace issues around parenthesesVivek Ghaisas2015-06-161-2/+2
| | | | | | | Fix issues found by MediaWiki.WhiteSpace.SpaceyParenthesis sniff. Bug: T102617 Change-Id: Iec7f71e64081659fba373ec20d9d2006306a98f4
* registration: Version the extension.json schemaKunal Mehta2015-05-281-3/+24
| | | | | | | | | | | | | | | | 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
* Implement extension registration from an extension.json fileKunal Mehta2015-01-081-0/+37
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