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
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
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
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
2016-12-14 19:18:09 +01:00
Renamed from tests/phpunit/includes/registration/CoreVersionCheckerTest.php (Browse further)
