This change adds the possibility to specify ext-* keys under the 'platform'
key introduced in I6744cc0be2 to require given PHP extensions. Note that
it's impossible to add constraints different from '*', as there is no universal
way to retrieve PHP extension versions.
Bug: T197535
Change-Id: I510de1e6d80f5c1d92dc1d1665aaa6c25bf28bf7
While MediaWiki Core already sets requirements for PHP versions, it should be
possible for extensions to tighten these requirements. This mirrors the PHP
parameter of extension infoboxes as well.
This change introduces a new 'platform' key (in addition to 'MediaWiki', 'skins'
and 'extensions', where non-MediaWiki software requirements will be listed
in the future, starting with a PHP version constraint. Further keys are
supposed to be added to allow setting constraints against php extensions
and other abilities of the platform.
Bug: T197535
Change-Id: I6744cc0be2363b603331af9dc860eb8603a1a89a
As it's quite common that extensions and skins interact with each other, it's
useful to have a simple way to check if an extension version satisfies a
given constraint, as extensions change over time.
Bug: T202955
Change-Id: I19f9713caf89d647072a2bd7d598e739be383f4a
The JSON specification permits duplicate keys, but doing so is almost
always nearly a mistake.
We can use the JSON lint library (added as
dev-requirement to composer), which is now also used to decode the
JSON (as it's the same step as validating the JSON).
Bug: T153507
Change-Id: Ia713a1906169333c1aa2aebdc0ed060d26428d72
Instead of using "skin" to check for skin dependencies, extension registration
now uses the correct key "skins" (from the schema).
Bug: T197478
Change-Id: I382fc79229e1406786f444192e6e3e3bde44d224
readFromQueue() injects the content of AutoloadClasses to
$wgAutoloadClasses however it missed doing the same for
AutoloadNamespaces.
When using the installer with an extension having AutoloadNamespaces
set, its classes would not be found.
Make ExtensionRegistry append to AutoLoader::$psr4Namespaces, and add
a test to cover the new behavior.
Bug: T195783
Change-Id: Id61155867a4ca7d9bc4a347f8671da74b0fa490b
If the "url" field in extension.json is pointing to mediawiki.org,
perform some extra validation steps:
* Require HTTPS
* Require the `www.mediawiki.org` canonical domain
Change-Id: I3371443d3f6c76f53437adf90a700969bba7d0e7
As there will likely be extensions bundled with the 1.31 release that
depend upon other extensions, we should have the installer prevent users
from enabling extensions that depend on other, not-enabled extensions.
We can build a dependency map from extension.json's "requires"
component. On the client-side, we'll first disable all checkboxes that
require other extensions, and evaluate each checkbox click, updating the
disabled checkboxes as possible.
This required some refactoring of how ExtensionRegistry reports issues
with dependency resolution so we could get a list of what was missing.
While we're at it, sort the extensions under headings by type.
This does not support skins that have dependencies yet (T186092).
Bug: T31134
Bug: T55985
Change-Id: I5f0e3b1b540b5ef6f9b8e3fc2bbaad1c65b4b680
The code for ParserTestFiles and ServiceWiringFiles was identical, so
unify it into one function. For most extensions, this should save two
unnecessary function calls as a bonus.
Change-Id: If5ed189f97b7d3b9cd7b550f3ad2e90abe30005d
$foo = null; isset( $foo ); will yield false.
Sometimes we want to explicitly set a config to null, but ExtensionRegistry
is then overriding this variable with the default value.
This is no consistent with the old workflow:
require_once the extension and then override the setting with null.
Bug: T128661
Change-Id: I0654c9369a596e84591fcaa9643703e6b4ccf57e
These tests apply to things that are not relevant to PHP code coverage,
such as testing presence of messages, JSON files, or the PHPUnit tests
themselves.
Using @coversNothing indicates that there is no code here to be covered,
and prevents warnings when using --strict-coverage mode (T152923).
Change-Id: Id89ee2c15a3ce3f10e34b13fb677cd1af75af9e6
ExtensionProcessor would previously just blindly overwrite duplicate
config settings, which ends up depending upon load order.
It's relatively hard to debug since it is silently overwritten. This now
throws exceptions in case of duplicate config settings.
This will also have some side-effects of catching people putting things
like "ResourceModules" in their "config" section when it should be a
top-level item.
Bug: T152929
Depends-On: I4c5eaf87657f5dc07787480a2f1a56a1db8c714f
Change-Id: Ieeb26011e42c741041d2c3252238ca0823b99eb4
ExtensionProcessor would previously just blindly overwrite duplicate
config settings, which ends up depending upon load order.
It's relatively hard to debug since it is silently overwritten. This now
throws exceptions in case of duplicate config settings.
This will also have some side-effects of catching people putting things
like "ResourceModules" in their "config" section when it should be a
top-level item.
Bug: T152929
Change-Id: Iaef32efab397e82ff70ddca8ac79c545c5b7d2bb
This moves attributes out of the top level, and namespaces them under
each extension. If the extension that it belongs to is not installed,
the attribute is not exported and dropped.
The full name of the attribute is the name of the extension plus the
name of the attribute key. This enforces the recommendation that the
attribute name start with the extension's name.
Add test coverage for attributes under manifest_version 1 and 2.
Bug: T133627
Depends-On: I5a148763f68989c8da313a4fb1d0213658ee4495
Depends-On: I5a148763f68989c8da313a4fb1d0213658ee4459
Change-Id: I8613a027c56e2c9d2c6a83ca14749eb1c8fc23be
This allows extension namespaces to be assigned a custom ID, e.g. in case
the namespace pre-defined by the extension is already taken on the local
wiki.
This is done by defining the respective namespace constant in
LocalSettings.php.
Bug: T160462
Change-Id: If648d6e218847e6632d643ea724cd3da3945db70
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
Instead of having the current version of the schema live at
extension.schema.json, always include a version number in it. This
simplifies both the code, and makes merging, cherry-picks, rebasing,
etc. easier when the current schema version changes.
Change-Id: I1b5ef4ced1eb34b8bdda7ba9b3f086b1997b704c
There are some extensoins that depend upon another extension or skin,
usually in different ways:
* A constant that is added in the dependency extension, and the
existence of is checked for. This is problematic because it requires a
specific load order.
* Checking whether a specific class exists. This is problematic because
it is extremely fragile, and breaks whenever the class is renamed.
* Checking ExtensionRegistry::isLoaded(). This is mostly there, but it
only checks at runtime, and doesn't provide any machine readable data.
Furthermore, developers implement each one differently, with very little
standardization.
With this, extensions may now specify what other extensions they depend
on. This is for explicit *hard* dependencies that must be installed.
For example:
"requires": {
"MediaWiki": ">= 1.25.0",
"extensions": {
"FakeExtension": "*"
},
"skins": {
"FakeSkin": "*"
}
}
This would add a minimum requirement on MediaWiki 1.25.0+ (already
implemented), as well as the requirement that the FakeExtension extension
needs to be installed, as well as the FakeSkin skin. A wildcard (*) is
used instead of an explicit version requirement as many extensions do
not actually version themselves, and there is no consistent versioning
scheme yet.
Bug: T117277
Change-Id: If1cccee1a16a867a71bb0285691c400443d8a30a
This allows us to put other requirements more easily into extension
registration, such as skins and/or extensions.
Bug: T117277
Change-Id: I3ec1b28b6af380621585cd61b38e5ebb8be9f9c7
When two keys have conflicting values, the value from extension.json wins
when using this merge strategy.
Change-Id: I0222682f3b3fb08f80afc7dda677da7bbfe8e5d1
For extension registry, add array_replace_recursive merge strategy,
as some extensions/configuration may prefer that to array_merge_recursive.
In some cases, configuration is merged from multiple extensions,
such as JsonConfig's $wgJsonConfigs configuration: ZeroBanner defines
"JsonZeroConfig": {
"namespace": 480,
"nsName": "Zero",
"isLocal": false,
"cacheKey": "1"
}
and mobile.php overrides it with
$wgJsonConfigs['JsonZeroConfig']['isLocal'] = false;
$wgJsonConfigs['JsonZeroConfig']['remote'] = [
'url' => 'https://zero.wikimedia.org/w/api.php',
'username' => $wmgZeroPortalApiUserName,
'password' => $wmgZeroPortalApiPassword,
];
Having identical value 'isLocal' would be converted into an array
if array_merge_recursive is used, but the replace strategy fixes it.
Change-Id: Ica6ddd0ae76f23e60de9b6235c6e2a3f2754a95d
Add support for configuration settings that are relative paths to the
extension directory. The most common use-case for this is where the
extension ships a generic default file, but sysadmins or packagers may
want to override it. Setting `"path": true` on the config definition
will make the value be interpreted as a relative path.
And add tests!
Bug: T100956
Change-Id: Ia87ced25b35be7a314ee2937e0ccc63f9acc5bb5
Verify that all the global settings listed in
ExtensionProcessor::$globalSettings are documented in the extension.json
schema.
Change-Id: If0ed09ed19b92934e869bbd40d8716a83e4b0a30
Instead of forcing an object even for single-hook-listeners, allow
string values, too (one hook listener for one hook, only). Also:
use it as default for the conversion script, if only one listener
is added to a hook (which is usually the case). This leads into a
much cleaner output of the Hooks section of extension.json.
Bug: T133628
Change-Id: Ie9e54f0931c41706eb8d82d00256698992ec41cc
PHP_CodeCoverage_Exception:
> Trying to @cover not existing method "SwiftFileBackend::sanitzeHdrs".
> Trying to @cover not existing method "LineFormatter::normalizeException".
> Trying to @cover not existing method "MonologSpi::mergeConfig".
> Trying to @cover not existing method "ProcessCacheLRU::het".
> Trying to @cover not existing method "BitmapHandler::swapICCProfile".
> Trying to @cover not existing class or interface "checkParseSafety".
> Trying to @cover not existing method "Article::__call". (was removed).
> Trying to @cover not existing method "ExtensionProcessor::extracttExtensionMessagesFiles".
> Trying to @cover not existing method "FileContentsHasher::getFileContentHash".
Makes code coverage run fail at the moment. These used to be warnings
in PHPUnit 3.x, but are now hard exceptions in PHPUnit 4.x when requesting
a coverage report.
Change-Id: If7f45ca57fd7d480d35b1414a889398837c0c472
Noticed it in APC usage for ResourceLoader that various keys from
FileContentsHasher contain double slashes. All from extensions that
use the `"localBasePath": ""` trick in extension.json (e.g. Citoid).
Change-Id: I5bac1e2e05e063aa7ff251ce7ffaa965a3451db9
Normally the registry load queue should filter out duplicates, but if
people do weird things with symlinks, throw a useful error message if
the double-loading makes it all the way to the processor.
Bug: T121493
Change-Id: I47f5cd754e5f3c91e6b83a6d0ab542404347a421
Extensions that have composer dependencies can set
"load_composer_autoloader": true
to load "$dir/vendor/autoload.php" if it exists.
While it is recommended to use composer-merge-plugin to manage
composer dependencies for extensions, using a local autoloader
can be easier for development and is used by ExtensionDistributor.
Bug: T119766
Change-Id: Ib031bef17c8a7d708a5c7878e74967d19217bbc8
This adds a "requires" property to extension.json, which extensions and
skins can use to indicate which versions of MediaWiki core they support.
The hacky wfUseMW() is now deprecated in favor of this.
Rather than writing our own version constraint and parser library, we
can re-use composer's, which was recently split out into a separate
library named "composer/semver" for this patch.
Any syntax accepted by composer[1] is available for usage here. Test
cases have been provided to demonstrate how versions are parsed. For now
it is recommended that people stick to expressing compatability with
stable versions (e.g. ">= 1.26").
This patch does not support requiring specific MediaWiki core WMF
branches, since those do not follow the standard semver format that
composer parses. If we are unable to parse $wgVersion, all checking will
be skipped and reported as compatible.
[1] https://getcomposer.org/doc/01-basic-usage.md#package-versions
Bug: T99084
Change-Id: I7785827216e16c596356d0ae42d6b30f3f179f10
