Add a merge strategy which sets the whole value only if the global
has not previously been set. This can be used to allow LocalSettings.php
to remove elements from an array created by extension.json.
Bug: T142663
Change-Id: Id250f9c349ee4eafbc759452ca6ea2a918baeb11
Modules that set "es6": true in their module definition will error when
a non-ES6 client tries to load them.
To detect ES6 support, this looks for native Promise support,
RegExp.prototype.flags, and non-BMP characters in variable names. All
browsers that lack full ES6 support fail at least one of those checks.
To flag modules as requiring ES6, this adds a ! to the end of their
version string. This takes up much less space than adding another
register() parameter (which would have to be at the end). It's hacky,
but we expect this feature to be relatively temporary, until we require
ES6 for running any JS at all (probably in about a year).
For distinguishing different types of errors thrown from
sortDependencies(), use e.name. We can't subclass Error properly because
that requires ES6.
Bug: T272104
Change-Id: I45670c910ff12eb422ae54c9fcf372e45c7b2bf1
Add the SkinLessImportPaths attribute for skin-specific LESS import
paths, which skins can use to override the mediawiki.skin.variables.less
file.
As a starting point, add the following 5 variables:
* device widths (3x)
To help phase out 'mediawiki.ui/variables'. These are
commonly used by MobileFrontend.
* @font-family-sans
Recommended by Volker. Used by multiple skins.
* @border-radius-base
Recommended by Volker as example of something that we currently
hardcode in MediaWiki core for Vector and OOUI/WikimediaUI
in 'mediawiki.widgets.datetime' but should instead be allowed
to vary by skin and OOUI theme.
Remove the hardcoded value for '@border-radius-base' in
various places in favour of importing from mediawiki.skin.
The default is a bare default of 0 (as border-radius is off
by default in the browser).
The value for Vector is restored there by I47da304667811.
The value for MonoBook is improved by I000f319ab31b.
Bug: T112747
Change-Id: Icf86c930a3b5524254bb549624737d3b9dccb032
Extension tags required value was the string value "true",
but really should be the boolean value true.
Bug: T257898
Change-Id: I6372fc55b864e898268c6df3f7cdead03b37d53f
Add a "silent" flag to DeprecatedHooks which causes relevant deprecation
warnings to be suppressed, but still allows call filtering to be used.
Add existing hooks that are documented as deprecated to the array.
Change-Id: Ieeb5e1840fd06d2b7979ef7827ba82bd2a35a2ba
See also I20f641a1ff032a6da3549b01dfaf8f4cf1eb5071, which uses this
attribute, and the earlier discussion in the (abandoned)
Ia251d631febf5be7fcad21cd8b73a68ec2785137.
Bug: T133320
Change-Id: I6c74938883376ec17f3790678b435585083a440f
* Updated the extension schema for the new hook system
* Fixed the lack of "services" from RestRoutes ObjectFactory specs,
since RestRoutes and HookHandlers is supposed to be the same.
Bug: T240307
Change-Id: I1a8657ff9fd14618c6709dbab62c3b4ee9f659a5
This allows for the schema to spot typos because there's now a whitelist of
properties. The main thing that might get caught by this is documentation
using "@something" keys, but all of that should be under "description"
now.
I sent patches to all extensions/skins in Gerrit so they'll pass validation
with the new schema: <https://gerrit.wikimedia.org/r/q/topic:%22fix-config-validation%22>.
Bug: T252589
Change-Id: I94d96b8a66b9209fa32726c2a2166308536f6c8a
This allows indirection between the values in $wgSearchType and
$wgSearchTypeAlternatives where the underlying class name
doesn't match the actual class name that subclasses
SearchEngine.
Bug: T250977
Change-Id: Ib9634128f07d428276e80a6f2f492b850eef17e8
Synchronize the definitions for ResourceModules and QUnitTestModule.
I previously had to fix a similar problem with 'packageFiles':
I6c3d186de1877f73d4a4e3fec7d6d632a5d5fa83. And there are many other
differences. I don't have the time right now to compare them all
and decide which ones are right.
Change-Id: I9153851fe162c012967fda00d3e1f81964a8dce9
This introduces two new keys to the extension schema, analogous to
the existing autoloader keys: TestAutoloadNamespaces and
TestAutoloadClasses.
The classes and namespaces defined by these keys are only loaded by
the registry when ExtensionRegistry::setLoadTestClassesAndNamespaces
is called. The phpunit wrapper does this in PHPUnitMaintClass::setup.
The unit test bootstrap file calls
ExtensionRegistry::exportTestAutoloadClassesAndNamespaces instead,
similar to how it loads the regular classes and namespaces.
Bug: T196090
Change-Id: I88cf69663362fd599c20649b1df641907a02678d
The PHP code handling 'packageFiles' looks like it only expects
numeric arrays, and not associative arrays. Therefore in JSON the
value for the 'packageFiles' key should be arrays and not objects.
(And a special case of a string, handled the same as single-element
array, is also accepted.)
Individual items in the array can be not only strings, but also
objects, describing data which is pulled from other sources than a
file.
* ResourceLoaderFileModule: Remove unused variable and tweak docs.
Change-Id: I6c3d186de1877f73d4a4e3fec7d6d632a5d5fa83
This allows extensions to add additional files or dependencies to
the 'mediawiki.messagePoster' module bundle.
Bug: T235315
Change-Id: I17c34cbb26e786328d3d99beb0c0fa65e15ea084
Now that the ObjectFactory library supports object creation with
services (T222409), the special page factory can use the object
factory to create special pages based off a spec, allowing the
creation of special pages that need services injected.
The object factory now also handles constructing from class name
and from callable.
This also deprecates providing the special page list with an
instance of SpecialPage, which hasn't been necessary since
r15031.
Bug: T222388
Change-Id: Iabb78ce5c98cfb3b586644be35d984871cb750cb
This change follows I39cc2a735d9625c87bf4ede6f5fb0ec441d47dcc.
docs/extension.schema.v1.json
docs/extension.schema.v2.json
includes/registration/ExtensionProcessor.php
* The new extension attribute 'OOUIThemePaths' can be used to define
custom OOUI themes. See I9187a63e509b601b8558ea82850fa828e5c8cc0a
for an example usage.
includes/resourceloader/ResourceLoaderOOUIModule.php
* Add support for 'OOUIThemePaths'.
* Defining 'images' is now optional. I figure custom themes are
unlikely to have or need them.
* Use ResourceLoaderFilePath objects to allow skin-/extension-defined
OOUI module files to use skin/extension's base paths.
This was previously used to support $wgResourceModuleSkinStyles,
but only for 'skinStyles' - now ResourceLoaderFileModule needs
to also handle it for 'skinScripts', and ResourceLoaderImageModule
for 'images').
includes/resourceloader/ResourceLoaderFilePath.php
* Add getters for local/remote base paths, for when we need to
construct a new ResourceLoaderFilePath based on existing one.
includes/resourceloader/ResourceLoaderFileModule.php
includes/resourceloader/ResourceLoaderImageModule.php
includes/resourceloader/ResourceLoaderOOUIImageModule.php
* Add or improve handling of ResourceLoaderFilePaths:
* Replace `(array)` casts with explicit array wrapping, to avoid
casting objects into associative arrays.
* Use getLocalPath() instead of string concatenation.
tests/phpunit/includes/resourceloader/ResourceLoaderFileModuleTest.php
tests/phpunit/includes/resourceloader/ResourceLoaderImageModuleTest.php
* Some basic checks for the above.
Bug: T100896
Change-Id: I74362f0fc215b26f1f104ce7bdbbac1e106736ad
Add some of the basic REST API class hierarchies:
* EntryPoint
* Router
* Request
* Response
* Handler
The actual entry point file rest.php has been moved to a separate
commit, so this is just an unused library and service.
Bug: T221177
Change-Id: Ifca6bcb8a304e8e8b7f52b79c607bdcebf805cd1
Extensions can specify development dependencies in extension.json under
the "dev-requires" key. It's identical to the "requires" field.
Any requirement that is needed to pass tests, including but not limited
to, PHPUnit, QUnit, structure, phan, should be documented in this new
field. The main intention is that CI will ensure that all of these
dependencies are satisfied before running tests.
At standard runtime, the development requirements will be ignored by
MediaWiki, since it only checks for real requirements. Scripts can
manually check development requirements by calling
ExtensionRegistry::setCheckDevRequires( true ) before trying to load
things.
If both "requires" and "dev-requires" are present, MediaWiki will merge
the two together, so the environment will need to satisfy both before
proceeding.
Bug: T193824
Change-Id: I9b2936666ee3c96f5c976c7a17f11c437c2c7f48
This patch adds the possibility for extensions and skins to require
certain environment abiltites that are not necessarily PHP extensions.
For now, the only ability introduced is the ability to shell out, but
the processing and testing is written in a more general way to allow
users to add more abilties later on by just changing getAbilities().
In theory, this allows using VersionChecker to check for random
abilities if they are specified in the constructor, as it is comletely
environment agnostic and not really bound to just be used for checking
extension compatibility.
Furthermore, it is possible to specify custom error messages for each of
these abilities in the constructor. Other parts of MediaWiki may use
these features to check for requirements while working with totally
different abilities.
Bug: T212472
Change-Id: Iff8512530b08ef509e7ac0b6ed8fe9578ef3e2a1
There is a full schema for ResourceModules when the
class: ResourceLoaderWikiModule is used. Except it doesn't actually work,
since it it fails validating against that schema, it will continue to check
the other anyOf schemas, find the arbitrary class one, and pass that one.
Blacklisting ResourceLoaderWikiModule from the arbitrary class schema means
that it has to pass the specified schema for it, or fail validation.
I verified that all extensions and skins in Gerrit pass validation with this
patch.
Change-Id: Icb862088c0ca1f89ed5a57a4286dd9049d213021
We want this regex to match on everything that is not the literal string
'ResourceFileModule' or 'ResourceImageModule' (actually
'ResourceLoaderWikiModule' should be in this too, but I'll fix that in a
follow-up). But the current regex would not match if one of those was in a
substring.
The new regex should match everything that is *not* those two strings.
Bug: T216861
Change-Id: I7d888adfdc67b2075028e49432710308aa0125af
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
The use of global variables was deprecated in favour of
ResourceLoaderModule::getLessVars() on a per-module basis.
Also moved testLessFileCompilation case to the appropiate file as it
covers ResourceLoaderFileModule.php, not ResourceLoader.php.
Bug: T140804
Depends-On: Ib1b2808df2384473bfac47f53a5d25d7c9bbca2b
Depends-On: I96047f69d01c4736306df2719267e6347daf556f
Change-Id: If708087c85c80355c7e78f1768529b5f2e16ed07
Without these rules, validation will fail in any skin or
extension that tries to use it.
Follows-up 36252b7.
Bug: T198930
Change-Id: Iee77655d4868a7d921be8cc23776a7859d9acf0c
The PSR-4 autoloader requires "AutoloadNamespaces" keys to have a
trailing \ (\\ in JSON), so add a validation check for that.
Unfortunately the validation error isn't great, since it checks to see
if the property matches patternProperties, and when it doesn't, it
claims the property isn't defined since additionalProperties is false.
But it's still better than not failing when they are missing.
Bug: T189136
Change-Id: If01bd06cdd767fb704a8ff85cdf1c143e53fa4ca
So that more than just PHP code and MediaWiki core can use it, but
also JSON-based static extension registrations. :-)
Change-Id: If22fccbb43c5b05db2a666d61ae8864ee9815e7d
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
