Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
{
"$schema" : "http://json-schema.org/schema#" ,
"description" : "MediaWiki extension.json schema" ,
"type" : "object" ,
2016-12-02 06:02:28 +00:00
"additionalProperties" : false ,
2019-02-08 20:13:49 +00:00
"patternProperties" : {
"^@" : {
2021-04-29 01:47:47 +00:00
"type" : [
"string" ,
"array"
] ,
2019-02-08 20:13:49 +00:00
"description" : "Arbitrary notes, ignored by the parser."
}
} ,
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"properties" : {
2015-05-20 01:45:10 +00:00
"manifest_version" : {
"type" : "integer" ,
"description" : "Version of the extension.json schema the extension.json file is in." ,
"required" : true
} ,
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"name" : {
"type" : "string" ,
2015-03-03 00:37:38 +00:00
"description" : "The extension's canonical name." ,
"required" : true
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
} ,
2015-04-02 17:15:43 +00:00
"namemsg" : {
"type" : "string" ,
"description" : "i18n message key of the extension's name."
} ,
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"type" : {
"type" : "string" ,
"description" : "The extension's type, as an index to $wgExtensionCredits." ,
2015-05-29 23:07:03 +00:00
"default" : "other"
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
} ,
"author" : {
"type" : [
"string" ,
"array"
] ,
"description" : "Extension's authors." ,
"items" : {
"type" : "string"
2015-06-02 01:50:51 +00:00
}
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
} ,
"version" : {
"type" : "string" ,
"description" : "The version of this release of the extension."
} ,
"url" : {
"type" : "string" ,
"description" : "URL to the homepage for the extension." ,
2017-07-17 17:13:49 +00:00
"format" : "uri-reference"
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
} ,
"description" : {
"type" : "string" ,
"description" : "Raw description of the extension."
} ,
"descriptionmsg" : {
"type" : "string" ,
"description" : "Message key for a i18n message describing the extension."
} ,
"license-name" : {
"type" : "string" ,
2016-09-28 02:56:07 +00:00
"description" : "SPDX identifier for the license under which the extension is released."
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
} ,
2015-05-14 05:51:55 +00:00
"requires" : {
"type" : "object" ,
2020-04-22 14:50:30 +00:00
"description" : "Indicates what versions of PHP, MediaWiki core, extensions or skins are required. This syntax may be extended in the future, for example to check dependencies between other services." ,
2017-01-29 13:05:17 +00:00
"additionalProperties" : false ,
2015-05-14 05:51:55 +00:00
"properties" : {
"MediaWiki" : {
"type" : "string" ,
"description" : "Version constraint string against MediaWiki core."
registration: Allow specifying extension dependencies
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
2016-12-03 18:19:25 +00:00
} ,
2018-09-08 00:02:53 +00:00
"platform" : {
"type" : "object" ,
"description" : "Indicates version constraints against platform services." ,
"additionalProperties" : false ,
"properties" : {
"php" : {
"type" : "string" ,
"description" : "Version constraint string against PHP."
2018-10-13 22:24:31 +00:00
} ,
"ability-shell" : {
"type" : "boolean" ,
"default" : false ,
"description" : "Whether this extension requires shell access."
2018-09-08 00:02:53 +00:00
}
2018-09-24 21:55:16 +00:00
} ,
2019-01-22 02:09:13 +00:00
"patternProperties" : {
registration: Add development requirements to extension.json
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
2019-05-19 09:17:56 +00:00
"^ext-" : {
"type" : "string" ,
"description" : "Required PHP extension." ,
2022-07-26 22:31:50 +00:00
"enum" : [ "*" ]
registration: Add development requirements to extension.json
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
2019-05-19 09:17:56 +00:00
}
}
} ,
"extensions" : {
"type" : "object" ,
"description" : "Set of version constraint strings against specific extensions."
} ,
"skins" : {
"type" : "object" ,
"description" : "Set of version constraint strings against specific skins."
}
}
} ,
2020-04-22 14:55:08 +00:00
"suggests" : {
"type" : "object" ,
"description" : "Indicates what versions of PHP and MediaWiki extensions or skins are optional suggestions. This syntax may be extended in the future, for example to check dependencies between other services." ,
"additionalProperties" : false ,
"properties" : {
"platform" : {
"type" : "object" ,
"description" : "Indicates optional version constraints against platform services." ,
"additionalProperties" : false ,
"properties" : {
"php" : {
"type" : "string" ,
"description" : "Optional version constraint string against PHP."
} ,
"ability-shell" : {
"type" : "boolean" ,
"default" : false ,
"description" : "Whether this extension requires shell access."
}
} ,
"patternProperties" : {
"^ext-" : {
"type" : "string" ,
"description" : "Optional PHP extension." ,
2022-07-26 22:31:50 +00:00
"enum" : [ "*" ]
2020-04-22 14:55:08 +00:00
}
}
} ,
"extensions" : {
"type" : "object" ,
"description" : "Set of optional version constraint strings against specific extensions."
} ,
"skins" : {
"type" : "object" ,
"description" : "Set of optional version constraint strings against specific skins."
}
}
} ,
registration: Add development requirements to extension.json
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
2019-05-19 09:17:56 +00:00
"dev-requires" : {
"type" : "object" ,
"description" : "Indicates what dependencies are required for development purposes such as running tests. This syntax may be extended in the future." ,
"additionalProperties" : false ,
"properties" : {
"MediaWiki" : {
"type" : "string" ,
"description" : "Version constraint string against MediaWiki core."
} ,
"platform" : {
"type" : "object" ,
"description" : "Indicates version constraints against platform services." ,
"additionalProperties" : false ,
"properties" : {
"php" : {
"type" : "string" ,
"description" : "Version constraint string against PHP."
} ,
"ability-shell" : {
"type" : "boolean" ,
"default" : false ,
"description" : "Whether this extension requires shell access."
}
} ,
"patternProperties" : {
2018-09-24 21:55:16 +00:00
"^ext-" : {
"type" : "string" ,
"description" : "Required PHP extension." ,
2022-07-26 22:31:50 +00:00
"enum" : [ "*" ]
2018-09-24 21:55:16 +00:00
}
2018-09-08 00:02:53 +00:00
}
} ,
registration: Allow specifying extension dependencies
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
2016-12-03 18:19:25 +00:00
"extensions" : {
"type" : "object" ,
"description" : "Set of version constraint strings against specific extensions."
} ,
"skins" : {
"type" : "object" ,
"description" : "Set of version constraint strings against specific skins."
2015-05-14 05:51:55 +00:00
}
}
} ,
2015-02-06 09:46:05 +00:00
"ResourceFileModulePaths" : {
"type" : "object" ,
"description" : "Default paths to use for all ResourceLoader file modules" ,
"additionalProperties" : false ,
"properties" : {
"localBasePath" : {
"type" : "string" ,
"description" : "Base path to prepend to all local paths, relative to current directory"
} ,
"remoteExtPath" : {
"type" : "string" ,
"description" : "Base path to prepend to all remote paths, relative to $wgExtensionAssetsPath"
} ,
"remoteSkinPath" : {
"type" : "string" ,
"description" : "Base path to prepend to all remote paths, relative to $wgStylePath"
}
}
} ,
2015-05-25 10:05:05 +00:00
"ResourceModules" : {
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"type" : "object" ,
"description" : "ResourceLoader modules to register" ,
"patternProperties" : {
2015-05-29 23:06:10 +00:00
"^[a-zA-Z0-9-\\.]+$" : {
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"type" : "object" ,
2015-08-02 23:42:46 +00:00
"anyOf" : [
{
2022-05-16 22:13:26 +00:00
"description" : "A FileModule definition" ,
2015-08-02 23:42:46 +00:00
"additionalProperties" : false ,
"properties" : {
"localBasePath" : {
"type" : "string" ,
"description" : "Base path to prepend to all local paths in $options. Defaults to $IP"
} ,
"remoteBasePath" : {
"type" : "string" ,
"description" : "Base path to prepend to all remote paths in $options. Defaults to $wgScriptPath"
} ,
"remoteExtPath" : {
"type" : "string" ,
"description" : "Equivalent of remoteBasePath, but relative to $wgExtensionAssetsPath"
} ,
2022-10-12 22:39:20 +00:00
"remoteSkinPath" : {
"type" : "string" ,
"description" : "Equivalent of remoteBasePath, but relative to $wgStylePath"
} ,
2016-04-19 01:13:18 +00:00
"skipFunction" : {
"type" : "string" ,
2016-04-23 01:54:13 +00:00
"description" : "Path to a file containing a JavaScript \"skip function\", if desired."
2016-04-19 01:13:18 +00:00
} ,
2015-08-02 23:42:46 +00:00
"scripts" : {
2022-07-26 22:31:50 +00:00
"type" : [ "string" , "array" ] ,
2015-08-02 23:42:46 +00:00
"description" : "Scripts to always include (array of file paths)" ,
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"items" : {
"type" : "string"
}
2015-08-02 23:42:46 +00:00
} ,
"languageScripts" : {
"type" : "object" ,
"description" : "Scripts to include in specific language contexts (mapping of language code to file path(s))" ,
"patternProperties" : {
"^[a-zA-Z0-9-]{2,}$" : {
"type" : [
"string" ,
"array"
] ,
"items" : {
"type" : "string"
}
}
}
} ,
"skinScripts" : {
"type" : "object" ,
"description" : "Scripts to include in specific skin contexts (mapping of skin name to script(s)" ,
"patternProperties" : {
".+" : {
"type" : [
"string" ,
"array"
] ,
"items" : {
"type" : "string"
}
}
}
} ,
"debugScripts" : {
2022-07-26 22:31:50 +00:00
"type" : [ "string" , "array" ] ,
2015-08-02 23:42:46 +00:00
"description" : "Scripts to include in debug contexts" ,
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"items" : {
"type" : "string"
}
2015-08-02 23:42:46 +00:00
} ,
"dependencies" : {
2022-07-26 22:31:50 +00:00
"type" : [ "string" , "array" ] ,
2015-08-02 23:42:46 +00:00
"description" : "Modules which must be loaded before this module" ,
"items" : {
"type" : "string"
}
} ,
"styles" : {
2022-07-26 22:31:50 +00:00
"type" : [ "string" , "array" , "object" ] ,
2015-08-02 23:42:46 +00:00
"description" : "Styles to always load" ,
"items" : {
"type" : "string"
}
} ,
"skinStyles" : {
"type" : "object" ,
"description" : "Styles to include in specific skin contexts (mapping of skin name to style(s))" ,
"patternProperties" : {
".+" : {
"type" : [
"string" ,
"array"
] ,
"items" : {
"type" : "string"
}
}
}
} ,
"messages" : {
2022-07-26 22:31:50 +00:00
"type" : [ "string" , "array" ] ,
2015-08-02 23:42:46 +00:00
"description" : "Messages to always load" ,
"items" : {
"type" : "string"
}
} ,
"group" : {
"type" : "string" ,
2016-06-22 21:57:38 +00:00
"description" : "Group with which this module should be loaded"
2015-08-02 23:42:46 +00:00
} ,
2016-07-14 22:09:06 +00:00
"deprecated" : {
2022-07-26 22:31:50 +00:00
"type" : [ "object" , "string" , "boolean" ] ,
2018-01-09 00:05:05 +00:00
"description" : "Whether the module is deprecated and usage is discouraged. Either a boolean, or a string or an object with key message can be used to customise deprecation message."
2016-07-14 22:09:06 +00:00
} ,
2015-08-02 23:42:46 +00:00
"position" : {
"type" : "string" ,
2021-08-18 05:50:52 +00:00
"description" : "Position on the page to load this module at (unused since MediaWiki 1.29)" ,
2015-08-02 23:42:46 +00:00
"enum" : [
"bottom" ,
"top"
]
} ,
"templates" : {
2022-07-26 22:31:50 +00:00
"type" : [ "object" , "array" ] ,
2020-02-25 00:18:20 +00:00
"description" : "Templates to be loaded for client-side usage" ,
"items" : {
"type" : "string"
}
2015-08-02 23:42:46 +00:00
} ,
"targets" : {
2022-07-26 22:31:50 +00:00
"type" : [ "string" , "array" ] ,
2015-08-02 23:42:46 +00:00
"description" : "ResourceLoader target the module can run on" ,
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"items" : {
"type" : "string"
}
2016-10-18 19:04:40 +00:00
} ,
"noflip" : {
"type" : "boolean" ,
"description" : "Whether to skip CSSJanus LTR-to-RTL flipping for this module. Recommended for styles imported from libraries that already properly handle their RTL styles. Default is false, meaning CSSJanus will be applied on RTL-mode output."
2019-02-11 09:53:09 +00:00
} ,
"packageFiles" : {
2022-07-26 22:31:50 +00:00
"type" : [ "string" , "array" ] ,
2019-10-24 15:12:20 +00:00
"description" : "Package files that can be require()d" ,
"items" : {
2022-07-26 22:31:50 +00:00
"type" : [ "string" , "object" ]
2019-10-24 15:12:20 +00:00
}
2021-01-23 07:33:38 +00:00
} ,
"es6" : {
"type" : "boolean" ,
"description" : "Whether this module requires an ES6-capable browser. If set to true, loading this module in a non-ES6 browser will cause an error. Using ES6 syntax in modules is not yet supported, but will be in the near future. Default is false."
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
}
}
} ,
2016-06-22 21:57:38 +00:00
{
2022-05-16 22:13:26 +00:00
"description" : "A WikiModule definition" ,
2016-06-22 21:57:38 +00:00
"additionalProperties" : false ,
"properties" : {
"class" : {
2022-05-06 09:09:56 +00:00
"type" : "string"
2016-06-22 21:57:38 +00:00
} ,
"group" : {
"type" : "string" ,
"description" : "Group with which this module should be loaded"
} ,
"position" : {
"type" : "string" ,
2021-08-18 05:50:52 +00:00
"description" : "Position on the page to load this module at (unused since MediaWiki 1.29)" ,
2016-06-22 21:57:38 +00:00
"enum" : [
"bottom" ,
"top"
]
} ,
"targets" : {
2022-07-26 22:31:50 +00:00
"type" : [ "string" , "array" ] ,
2016-06-22 21:57:38 +00:00
"description" : "ResourceLoader target the module can run on" ,
"items" : {
"type" : "string"
}
} ,
"scripts" : {
"type" : "array" ,
"description" : "A list of on-wiki pages containing JavaScript that should be loaded" ,
"items" : {
"type" : "string"
}
} ,
"styles" : {
"type" : "array" ,
"description" : "A list of on-wiki pages containing CSS that should be loaded" ,
"items" : {
"type" : "string"
}
}
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
}
} ,
2015-08-02 23:42:46 +00:00
{
2022-05-16 22:13:26 +00:00
"description" : "An ImageModule definition" ,
2015-08-02 23:42:46 +00:00
"additionalProperties" : false ,
"properties" : {
"class" : {
2022-05-06 09:09:56 +00:00
"type" : "string"
2015-08-02 23:42:46 +00:00
} ,
2020-03-15 14:54:56 +00:00
"localBasePath" : {
"type" : "string" ,
"description" : "Base path to prepend to all local paths. Defaults to $IP"
} ,
2018-06-25 22:55:19 +00:00
"defaultColor" : {
"type" : "string"
} ,
2015-08-02 23:42:46 +00:00
"data" : {
"type" : "string"
} ,
"prefix" : {
"type" : "string"
} ,
"selector" : {
"type" : "string"
} ,
"selectorWithoutVariant" : {
"type" : "string"
} ,
"selectorWithVariant" : {
"type" : "string"
} ,
2018-07-09 23:26:15 +00:00
"useDataURI" : {
"type" : "boolean"
} ,
2015-08-02 23:42:46 +00:00
"variants" : {
"type" : "object"
} ,
"images" : {
"type" : "object"
} ,
"position" : {
2021-08-18 05:50:52 +00:00
"type" : "string" ,
"description" : "Position on the page to load this module at (unused since MediaWiki 1.29)" ,
2015-08-02 23:42:46 +00:00
"enum" : [
"top" ,
"bottom"
]
}
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
}
} ,
2015-08-02 23:42:46 +00:00
{
2022-05-06 09:09:56 +00:00
"description" : "An arbitrary ResourceLoader Module definition by class" ,
2015-08-02 23:42:46 +00:00
"properties" : {
"class" : {
"type" : "string" ,
2019-02-23 01:17:05 +00:00
"pattern" : "^(?!ResourceLoader(File|Image|Wiki)Module).*$"
2015-08-02 23:42:46 +00:00
}
} ,
2022-07-26 22:31:50 +00:00
"required" : [ "class" ]
2017-05-04 16:10:28 +00:00
} ,
{
2022-05-06 09:09:56 +00:00
"description" : "An arbitrary ResourceLoader Module definition with instantiator" ,
2017-05-04 16:10:28 +00:00
"properties" : {
"factory" : {
"type" : "string" ,
2022-05-06 09:09:56 +00:00
"description" : "A static instantiator function for creating the ResourceLoader Module object."
2017-05-04 16:10:28 +00:00
}
} ,
2022-07-26 22:31:50 +00:00
"required" : [ "factory" ]
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
}
2015-08-02 23:42:46 +00:00
]
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
}
}
} ,
2015-04-02 17:12:52 +00:00
"ResourceModuleSkinStyles" : {
"type" : "object" ,
"description" : "ResourceLoader modules for custom skin styles"
} ,
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"ResourceLoaderSources" : {
"type" : "object" ,
"description" : "ResourceLoader sources to register"
} ,
2018-05-20 18:32:57 +00:00
"SkinLessImportPaths" : {
"type" : "object" ,
"description" : "Path to the skin-specific LESS import directory, keyed by skin name. Can be used to define skin-specific LESS variables."
} ,
2019-01-18 20:21:35 +00:00
"QUnitTestModule" : {
"type" : "object" ,
2022-10-12 22:39:20 +00:00
"description" : "A ResourceLoader module definition registered only when wgEnableJavaScriptTest is true." ,
"anyOf" : [
{
"description" : "A FileModule definition" ,
"additionalProperties" : false ,
"properties" : {
"localBasePath" : {
"type" : "string" ,
"description" : "Base path to prepend to all local paths in $options. Defaults to $IP"
} ,
"remoteBasePath" : {
"type" : "string" ,
"description" : "Base path to prepend to all remote paths in $options. Defaults to $wgScriptPath"
} ,
"remoteExtPath" : {
"type" : "string" ,
"description" : "Equivalent of remoteBasePath, but relative to $wgExtensionAssetsPath"
} ,
"remoteSkinPath" : {
"type" : "string" ,
"description" : "Equivalent of remoteBasePath, but relative to $wgStylePath"
} ,
"skipFunction" : {
"type" : "string" ,
"description" : "Path to a file containing a JavaScript \"skip function\", if desired."
} ,
"scripts" : {
"type" : [ "string" , "array" ] ,
"description" : "Scripts to always include (array of file paths)" ,
"items" : {
"type" : "string"
}
} ,
"languageScripts" : {
"type" : "object" ,
"description" : "Scripts to include in specific language contexts (mapping of language code to file path(s))" ,
"patternProperties" : {
"^[a-zA-Z0-9-]{2,}$" : {
"type" : [
"string" ,
"array"
] ,
"items" : {
"type" : "string"
}
}
}
} ,
"skinScripts" : {
"type" : "object" ,
"description" : "Scripts to include in specific skin contexts (mapping of skin name to script(s)" ,
"patternProperties" : {
".+" : {
"type" : [
"string" ,
"array"
] ,
"items" : {
"type" : "string"
}
}
}
} ,
"debugScripts" : {
"type" : [ "string" , "array" ] ,
"description" : "Scripts to include in debug contexts" ,
"items" : {
"type" : "string"
}
} ,
"dependencies" : {
"type" : [ "string" , "array" ] ,
"description" : "Modules which must be loaded before this module" ,
"items" : {
"type" : "string"
}
} ,
"styles" : {
"type" : [ "string" , "array" , "object" ] ,
"description" : "Styles to always load" ,
"items" : {
"type" : "string"
}
} ,
"skinStyles" : {
"type" : "object" ,
"description" : "Styles to include in specific skin contexts (mapping of skin name to style(s))" ,
"patternProperties" : {
".+" : {
"type" : [
"string" ,
"array"
] ,
"items" : {
"type" : "string"
}
}
}
} ,
"messages" : {
"type" : [ "string" , "array" ] ,
"description" : "Messages to always load" ,
"items" : {
"type" : "string"
}
} ,
"group" : {
"type" : "string" ,
"description" : "Group with which this module should be loaded"
} ,
"deprecated" : {
"type" : [ "object" , "string" , "boolean" ] ,
"description" : "Whether the module is deprecated and usage is discouraged. Either a boolean, or a string or an object with key message can be used to customise deprecation message."
} ,
"position" : {
"type" : "string" ,
"description" : "Position on the page to load this module at (unused since MediaWiki 1.29)" ,
"enum" : [
"bottom" ,
"top"
]
} ,
"templates" : {
"type" : [ "object" , "array" ] ,
"description" : "Templates to be loaded for client-side usage" ,
"items" : {
"type" : "string"
}
} ,
"targets" : {
"type" : [ "string" , "array" ] ,
"description" : "ResourceLoader target the module can run on" ,
"items" : {
"type" : "string"
}
} ,
"noflip" : {
"type" : "boolean" ,
"description" : "Whether to skip CSSJanus LTR-to-RTL flipping for this module. Recommended for styles imported from libraries that already properly handle their RTL styles. Default is false, meaning CSSJanus will be applied on RTL-mode output."
} ,
"packageFiles" : {
"type" : [ "string" , "array" ] ,
"description" : "Package files that can be require()d" ,
"items" : {
"type" : [ "string" , "object" ]
}
} ,
"es6" : {
"type" : "boolean" ,
"description" : "Whether this module requires an ES6-capable browser. If set to true, loading this module in a non-ES6 browser will cause an error. Using ES6 syntax in modules is not yet supported, but will be in the near future. Default is false."
}
2019-10-03 22:19:12 +00:00
}
} ,
2022-10-12 22:39:20 +00:00
{
"description" : "An arbitrary ResourceLoader Module definition by class" ,
"properties" : {
"class" : {
"type" : "string" ,
"pattern" : "^(?!ResourceLoader(File|Image|Wiki)Module).*$"
}
} ,
"required" : [ "class" ]
2022-09-01 08:31:18 +00:00
} ,
2022-10-12 22:39:20 +00:00
{
"description" : "An arbitrary ResourceLoader Module definition with instantiator" ,
"properties" : {
"factory" : {
"type" : "string" ,
"description" : "A static instantiator function for creating the ResourceLoader Module object."
}
} ,
"required" : [ "factory" ]
2019-01-18 20:21:35 +00:00
}
2022-10-12 22:39:20 +00:00
]
2019-01-18 20:21:35 +00:00
} ,
2019-10-12 03:17:51 +00:00
"MessagePosterModule" : {
"type" : "object" ,
"description" : "Additional JavaScript files and modules that will register content models with mw.messagePoster.factory." ,
"additionalProperties" : false ,
"properties" : {
"localBasePath" : {
"type" : "string" ,
2022-07-26 18:47:35 +00:00
"description" : "Prefix for local paths to files in $options, relative to extension directory"
2019-10-12 03:17:51 +00:00
} ,
"scripts" : {
"type" : "array" ,
"description" : "Scripts to include as array of file paths" ,
"items" : {
"type" : "string"
}
} ,
"dependencies" : {
"type" : "array" ,
"description" : "Modules which must load before these files" ,
"items" : {
"type" : "string"
}
}
}
} ,
2015-01-11 04:12:01 +00:00
"ConfigRegistry" : {
"type" : "object" ,
"description" : "Registry of factory functions to create Config objects"
} ,
2016-05-11 21:41:42 +00:00
"SessionProviders" : {
"type" : "object" ,
"description" : "Session providers"
} ,
2015-11-22 20:17:00 +00:00
"AuthManagerAutoConfig" : {
"type" : "object" ,
"description" : "AuthManager auto-configuration" ,
"additionalProperties" : false ,
"properties" : {
"preauth" : {
"type" : "object" ,
"description" : "Pre-authentication providers"
} ,
"primaryauth" : {
"type" : "object" ,
"description" : "Primary authentication providers"
} ,
"secondaryauth" : {
"type" : "object" ,
"description" : "Secondary authentication providers"
}
}
} ,
2016-01-02 07:13:31 +00:00
"CentralIdLookupProviders" : {
"type" : "object" ,
"description" : "Central ID lookup providers"
} ,
2016-06-14 21:21:02 +00:00
"ChangeCredentialsBlacklist" : {
"type" : "object" ,
"description" : "AuthenticationRequest classes which can only be used internally for credentials change"
} ,
"RemoveCredentialsBlacklist" : {
"type" : "object" ,
"description" : "AuthenticationRequest classes which can only be used internally for credentials removal"
} ,
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"namespaces" : {
2015-08-01 06:01:59 +00:00
"type" : "array" ,
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"description" : "Method to add extra namespaces" ,
2015-08-01 06:01:59 +00:00
"items" : {
"type" : "object" ,
"properties" : {
"id" : {
"type" : "integer"
} ,
"constant" : {
"type" : "string"
} ,
"name" : {
"type" : "string"
} ,
"gender" : {
"type" : "object" ,
"properties" : {
"male" : {
"type" : "string"
} ,
"female" : {
"type" : "string"
}
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
}
2015-08-01 06:01:59 +00:00
} ,
"subpages" : {
"type" : "boolean" ,
"default" : false
} ,
"content" : {
"type" : "boolean" ,
"default" : false
} ,
"defaultcontentmodel" : {
"type" : "string"
2015-08-01 07:39:52 +00:00
} ,
"protection" : {
2022-07-26 22:31:50 +00:00
"type" : [ "string" , "array" ] ,
2015-08-01 07:39:52 +00:00
"description" : "Userright(s) required to edit in this namespace"
2015-08-01 08:37:10 +00:00
} ,
"capitallinkoverride" : {
"type" : "boolean" ,
"description" : "Set $wgCapitalLinks on a per-namespace basis"
2016-07-29 08:09:24 +00:00
} ,
"conditional" : {
"type" : "boolean" ,
"description" : "Whether the namespace is conditional upon configuration and should not be registered (requires separate registration via a hook)" ,
"default" : false
2021-03-16 13:28:51 +00:00
} ,
"movable" : {
"type" : "boolean" ,
"description" : "Whether it is possible to move pages in this namespace" ,
"default" : true
2021-08-20 05:09:47 +00:00
} ,
"includable" : {
"type" : "boolean" ,
"description" : "Whether it is possible to include/transclude pages in this namespace" ,
"default" : true
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
}
} ,
2022-07-26 22:31:50 +00:00
"required" : [ "id" , "constant" , "name" ]
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
}
} ,
"TrackingCategories" : {
"type" : "array" ,
2016-04-25 22:48:54 +00:00
"description" : "Tracking category message keys" ,
"items" : {
"type" : "string"
}
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
} ,
"DefaultUserOptions" : {
"type" : "object" ,
"description" : "Default values of user options"
} ,
"HiddenPrefs" : {
"type" : "array" ,
2016-04-25 22:48:54 +00:00
"description" : "Preferences users cannot set" ,
"items" : {
"type" : "string"
}
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
} ,
"GroupPermissions" : {
"type" : "object" ,
2016-04-25 22:48:54 +00:00
"description" : "Default permissions to give to user groups" ,
"patternProperties" : {
"^[a-z]+$" : {
"type" : "object" ,
"patternProperties" : {
"^[a-z]+$" : {
"type" : "boolean"
}
}
}
}
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
} ,
"RevokePermissions" : {
"type" : "object" ,
2016-04-25 22:48:54 +00:00
"description" : "Default permissions to revoke from user groups" ,
"patternProperties" : {
"^[a-z]+$" : {
"type" : "object" ,
"patternProperties" : {
"^[a-z]+$" : {
"type" : "boolean"
}
}
}
}
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
} ,
2016-06-10 20:10:27 +00:00
"GrantPermissions" : {
"type" : "object" ,
"description" : "Map of permissions granted to authorized consumers to their bundles, called 'grants'" ,
"patternProperties" : {
"^[a-z]+$" : {
"type" : "object" ,
"patternProperties" : {
"^[a-z]+$" : {
"type" : "boolean"
}
}
}
}
} ,
"GrantPermissionGroups" : {
"type" : "object" ,
"description" : "Map of grants to their UI grouping" ,
"patternProperties" : {
"^[a-z]+$" : {
"type" : "string"
}
}
} ,
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"ImplicitGroups" : {
"type" : "array" ,
"description" : "Implicit groups"
} ,
"GroupsAddToSelf" : {
"type" : "object" ,
"description" : "Groups a user can add to themselves"
} ,
"GroupsRemoveFromSelf" : {
"type" : "object" ,
"description" : "Groups a user can remove from themselves"
} ,
"AddGroups" : {
"type" : "object" ,
"description" : "Groups a user can add to users"
} ,
"RemoveGroups" : {
"type" : "object" ,
"description" : "Groups a user can remove from users"
} ,
"AvailableRights" : {
"type" : "array" ,
2016-04-25 22:48:54 +00:00
"description" : "User rights added by the extension" ,
"items" : {
"type" : "string"
}
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
} ,
"ContentHandlers" : {
"type" : "object" ,
2021-10-15 08:21:07 +00:00
"description" : "Mapping of model ID to class name or an ObjectFactory specification." ,
2016-04-25 22:48:54 +00:00
"patternProperties" : {
"^[A-Za-z]+$" : {
2021-10-15 08:21:07 +00:00
"oneOf" : [
{
"type" : "string" ,
"description" : "Class name of the ContentHandler."
} ,
{
"type" : "object" ,
"description" : "ObjectFactory specification of the ContentHandler."
}
]
2016-04-25 22:48:54 +00:00
}
}
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
} ,
"RateLimits" : {
"type" : "object" ,
"description" : "Rate limits"
} ,
"RecentChangesFlags" : {
"type" : "object" ,
"description" : "Flags (letter symbols) shown on RecentChanges pages"
} ,
2015-05-03 02:38:29 +00:00
"MediaHandlers" : {
"type" : "object" ,
"description" : "Plugins for media file type handling. Each entry in the array maps a MIME type to a PHP class name."
} ,
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"ExtensionFunctions" : {
"type" : [
"array" ,
"string"
] ,
2016-04-25 22:48:54 +00:00
"description" : "Function to call after setup has finished" ,
"items" : {
"type" : "string"
}
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
} ,
"ExtensionMessagesFiles" : {
"type" : "object" ,
"description" : "File paths containing PHP internationalization data"
} ,
"MessagesDirs" : {
"type" : "object" ,
"description" : "Directory paths containing JSON internationalization data"
} ,
"ExtensionEntryPointListFiles" : {
"type" : "object"
} ,
"SpecialPages" : {
"type" : "object" ,
2022-09-16 22:54:19 +00:00
"description" : "SpecialPages implemented in this extension (mapping of page name to class name or to ObjectFactory spec, or factory callback)"
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
} ,
2017-08-24 18:05:26 +00:00
"AutoloadNamespaces" : {
"type" : "object" ,
2018-05-20 19:13:05 +00:00
"description" : "Mapping of PSR-4 compliant namespace to directory for autoloading" ,
"patternProperties" : {
"^[A-Za-z0-9\\\\]+\\\\$" : {
"type" : "string"
}
} ,
"additionalProperties" : false
2017-08-24 18:05:26 +00:00
} ,
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"AutoloadClasses" : {
"type" : "object"
} ,
2019-12-10 12:13:13 +00:00
"TestAutoloadNamespaces" : {
"type" : "object" ,
"description" : "Mapping of PSR-4 compliant namespace to directory for autoloading to be used in tests" ,
"patternProperties" : {
"^[A-Za-z0-9\\\\]+\\\\$" : {
"type" : "string"
}
} ,
"additionalProperties" : false
} ,
"TestAutoloadClasses" : {
"type" : "object"
} ,
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"Hooks" : {
2020-05-18 04:18:14 +00:00
"type" : "object" ,
"description" : "Hooks this extension uses (mapping of hook name to callback)" ,
"additionalProperties" : {
"oneOf" : [
{
"type" : "string" ,
"description" : "A global function name, static function name, or the name of a property in HookHandlers"
} ,
{
"type" : "object" ,
"description" : "A handler specification" ,
"properties" : {
"handler" : {
"type" : "string" ,
"description" : "The name of a property in HookHandlers"
} ,
"deprecated" : {
"type" : "boolean" ,
"description" : "The deprecation acknowledgement flag for the handler. If this is true, calls will be filtered if the relevant hook is deprecated."
}
} ,
"required" : [
"handler"
]
} ,
{
"type" : "array" ,
"description" : "An ordered array of handlers" ,
"items" : {
"oneOf" : [
{
"type" : "string" ,
"description" : "A global function name, static function name, or the name of a property in HookHandlers"
} ,
{
"type" : "object" ,
"description" : "A handler specification" ,
"properties" : {
"handler" : {
"type" : "string" ,
"description" : "The name of a property in HookHandlers"
} ,
"deprecated" : {
"type" : "boolean" ,
"description" : "The deprecation acknowledgement flag for the handler. If this is true, calls will be filtered if the relevant hook is deprecated."
}
} ,
"required" : [
"handler"
]
}
]
}
}
]
}
} ,
"HookHandlers" : {
"type" : "object" ,
"description" : "ObjectFactory specifications for new-style hook handlers" ,
"additionalProperties" : {
"type" : "object" ,
"properties" : {
"factory" : {
2022-07-26 22:31:50 +00:00
"type" : [ "string" , "array" ] ,
2020-05-18 04:18:14 +00:00
"description" : "A factory function to be called to create the handler for this hook"
} ,
"class" : {
"type" : "string" ,
"description" : "The fully-qualified class name of the handler. This should be omitted if a factory is specified."
} ,
"args" : {
"type" : "array" ,
"description" : "The arguments passed to the handler constructor or factory"
} ,
"services" : {
"type" : "array" ,
"description" : "If supplied and non-empty, the named services are requested from the service container and prepended before 'args'."
2020-11-17 06:15:02 +00:00
} ,
"optional_services" : {
"type" : "array" ,
"description" : "If supplied and non-empty, the named services are requested from the service container and appended after 'services' if the services are available; null is passed if the services are not available."
2020-05-18 04:18:14 +00:00
}
}
}
} ,
"DeprecatedHooks" : {
"type" : "object" ,
"description" : "Hooks which are defined and deprecated by the extension" ,
"additionalProperties" : {
"type" : "object" ,
"properties" : {
"deprecatedVersion" : {
"type" : "string" ,
"description" : "The version in which the hook was deprecated"
} ,
"component" : {
"type" : "string" ,
2022-07-26 22:31:50 +00:00
"description" : "The component to which the deprecated version relates. If omitted, the extension name will be used."
2020-06-03 04:58:25 +00:00
} ,
"silent" : {
"type" : "boolean" ,
"description" : "If true, no warning is raised when the hook is called or when a handler is declared. However, call filtering is still activated."
2020-05-18 04:18:14 +00:00
}
} ,
"required" : [
"deprecatedVersion"
]
}
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
} ,
"JobClasses" : {
"type" : "object" ,
2017-05-04 16:00:28 +00:00
"description" : "Job types this extension implements (mapping of job type to class name or factory function)"
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
} ,
"LogTypes" : {
"type" : "array" ,
"description" : "List of new log types this extension uses"
} ,
"LogRestrictions" : {
"type" : "object"
} ,
"FilterLogTypes" : {
2015-06-26 00:29:33 +00:00
"type" : "object"
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
} ,
2016-04-19 13:12:18 +00:00
"ActionFilteredLogs" : {
"type" : "object" ,
"description" : "List of log types which can be filtered by log actions" ,
"patternProperties" : {
"^[a-z-]+$" : {
"type" : "object" ,
"patternProperties" : {
"^[a-z-]+$" : {
"type" : "array" ,
"items" : {
"type" : "string"
}
}
}
}
}
} ,
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"LogNames" : {
"type" : "object"
} ,
"LogHeaders" : {
"type" : "object"
} ,
"LogActions" : {
"type" : "object"
} ,
"LogActionsHandlers" : {
"type" : "object"
} ,
"Actions" : {
"type" : "object"
} ,
"APIModules" : {
"type" : "object"
} ,
"APIFormatModules" : {
"type" : "object"
} ,
"APIMetaModules" : {
"type" : "object"
} ,
"APIPropModules" : {
"type" : "object"
} ,
"APIListModules" : {
"type" : "object"
} ,
2015-03-04 20:34:35 +00:00
"ValidSkinNames" : {
2020-05-14 11:20:24 +00:00
"type" : "object" ,
2022-07-26 22:31:50 +00:00
"description" : "Mapping of skin canonical names to PHP class name using the Object Factory specification. Or historically, the human readable name of the skin."
2015-03-04 20:34:35 +00:00
} ,
2016-01-03 21:37:17 +00:00
"FeedClasses" : {
"type" : "object" ,
"description" : "Available feeds objects"
} ,
2015-05-24 16:56:44 +00:00
"SkinOOUIThemes" : {
2017-03-17 01:32:59 +00:00
"type" : "object" ,
2022-05-06 09:09:56 +00:00
"description" : "Map of skin names to OOUI themes to use. Same format as MediaWiki\\ResourceLoader\\OOUIModule::$builtinSkinThemeMap."
2015-05-24 16:56:44 +00:00
} ,
2017-03-17 02:14:05 +00:00
"OOUIThemePaths" : {
"type" : "object" ,
2022-05-06 09:09:56 +00:00
"description" : "Map of custom OOUI theme names to paths to load them from. Same format as MediaWiki\\ResourceLoader\\OOUIModule::$builtinThemePaths." ,
2017-03-17 02:14:05 +00:00
"patternProperties" : {
"^[A-Za-z]+$" : {
"type" : "object" ,
"additionalProperties" : false ,
"properties" : {
2021-04-19 09:30:16 +00:00
"localBasePath" : {
"type" : "string" ,
"description" : "Base path to prepend to all local paths, relative to current directory"
} ,
"remoteExtPath" : {
"type" : "string" ,
"description" : "Base path to prepend to all remote paths, relative to $wgExtensionAssetsPath"
} ,
"remoteSkinPath" : {
"type" : "string" ,
"description" : "Base path to prepend to all remote paths, relative to $wgStylePath"
} ,
2017-03-17 02:14:05 +00:00
"scripts" : {
"type" : "string" ,
"description" : "Path to script file."
} ,
"styles" : {
"type" : "string" ,
"description" : "Path to style files. '{module}' will be replaced with the module's name."
} ,
"images" : {
2022-12-29 16:58:27 +00:00
"type" : "string" ,
"description" : "Path to image definition files. '{module}' will be replaced with the module's name. If the files don't exist, default theme's images will be used instead."
2017-03-17 02:14:05 +00:00
}
}
}
}
} ,
2023-02-04 03:58:49 +00:00
"SkinCodexThemes" : {
"type" : "object" ,
"description" : "Name of the Codex theme to use for each skin, keyed by skin name. Skins not specified here default to the wikimedia-ui theme."
} ,
2016-10-31 17:12:56 +00:00
"PasswordPolicy" : {
"type" : "object" ,
"description" : "Password policies"
} ,
2016-11-17 22:36:09 +00:00
"FileExtensions" : {
2016-11-21 02:43:50 +00:00
"type" : "array" ,
"description" : "Preferred file extensions for uploading" ,
"items" : {
"type" : "string"
}
2016-11-17 22:36:09 +00:00
} ,
2018-07-31 22:19:40 +00:00
"RawHtmlMessages" : {
"type" : "array" ,
"description" : "Messages which are rendered as raw HTML" ,
"items" : {
"type" : "string"
}
} ,
2022-10-25 22:36:20 +00:00
"LateJSConfigVarNames" : {
"type" : "array" ,
"description" : "Names of JS config vars (as used in MakeGlobalVariablesScript hook or in ParserOutput::setJsConfigVar) that may be set from the end of the HTML body instead of the HTML head, to improve page load time. In JavaScript, these variables should be accessed via mw.hook('wikipage.content')." ,
"items" : {
"type" : "string"
}
} ,
2018-11-15 23:39:58 +00:00
"ReauthenticateTime" : {
"type" : "object" ,
"patternProperties" : {
".*" : {
"type" : "integer"
}
}
} ,
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"callback" : {
"type" : [
"array" ,
"string"
] ,
"description" : "A function to be called right after MediaWiki processes this file"
} ,
2016-06-22 22:33:35 +00:00
"config_prefix" : {
"type" : "string" ,
"default" : "wg" ,
"description" : "Prefix to put in front of configuration settings when exporting them to $GLOBALS"
} ,
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
"config" : {
"type" : "object" ,
2015-08-01 07:38:27 +00:00
"description" : "Configuration options for this extension" ,
"patternProperties" : {
"^[a-zA-Z_\u007f-\u00ff][a-zA-Z0-9_\u007f-\u00ff]*$" : {
2016-07-25 22:36:12 +00:00
"type" : "object" ,
2020-05-12 20:02:06 +00:00
"additionalProperties" : false ,
2015-08-01 07:38:27 +00:00
"properties" : {
2016-06-22 22:33:35 +00:00
"value" : {
"required" : true
} ,
"merge_strategy" : {
2015-08-01 07:38:27 +00:00
"type" : "string" ,
"enum" : [
"array_merge_recursive" ,
Added array_replace_recursive merge strategy
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
2016-10-18 05:23:56 +00:00
"array_replace_recursive" ,
2015-08-01 07:38:27 +00:00
"array_plus_2d" ,
"array_plus" ,
2021-05-04 04:18:37 +00:00
"array_merge" ,
"provide_default"
2015-08-01 07:38:27 +00:00
] ,
"default" : "array_merge"
2016-06-22 22:33:35 +00:00
} ,
2016-07-22 22:08:21 +00:00
"path" : {
"description" : "Whether this should be interpreted as a filesystem path, relative to extension directory root" ,
"type" : "boolean" ,
"default" : false
} ,
2016-06-22 22:33:35 +00:00
"description" : {
2022-07-26 22:31:50 +00:00
"type" : [ "string" , "array" ] ,
2016-06-22 22:33:35 +00:00
"description" : "A description of the config setting, mostly for documentation/developers"
2017-01-13 05:11:55 +00:00
} ,
2020-05-12 20:02:06 +00:00
"descriptionmsg" : {
2017-01-13 05:14:42 +00:00
"type" : "string" ,
"description" : "The message key which should be used as a description for this configuration option in a user interface. If empty, description will be used."
} ,
2017-01-13 05:11:55 +00:00
"public" : {
"type" : "boolean" ,
"default" : false ,
"description" : "Whether this configuration option and its value is allowed to be revealed in public or not."
2015-08-01 07:38:27 +00:00
}
}
}
}
2015-05-03 06:02:22 +00:00
} ,
2020-04-27 12:44:55 +00:00
"SearchMappings" : {
"type" : "object" ,
"description" : "Mapping of search canonical names (used in $wgSearchType and $wgSearchTypeAlternatives) using the Object Factory specification"
} ,
2016-08-26 06:00:28 +00:00
"ServiceWiringFiles" : {
"type" : "array" ,
"description" : "List of service wiring files to be loaded by the default instance of MediaWikiServices"
} ,
2019-05-09 01:36:18 +00:00
"RestRoutes" : {
"type" : "array" ,
"description" : "List of route specifications to be added to the REST API" ,
"items" : {
"type" : "object" ,
"properties" : {
"method" : {
"oneOf" : [
{
"type" : "string" ,
"description" : "The HTTP method name"
} ,
{
"type" : "array" ,
"items" : {
"type" : "string" ,
"description" : "An acceptable HTTP method name"
}
}
]
} ,
"path" : {
"type" : "string" ,
"description" : "The path template. This should start with an initial slash, designating the root of the REST API. Path parameters are enclosed in braces, for example /endpoint/{param}."
} ,
"factory" : {
2022-07-26 22:31:50 +00:00
"type" : [ "string" , "array" ] ,
2019-05-09 01:36:18 +00:00
"description" : "A factory function to be called to create the handler for this route"
} ,
"class" : {
"type" : "string" ,
"description" : "The fully-qualified class name of the handler. This should be omitted if a factory is specified."
} ,
"args" : {
"type" : "array" ,
"description" : "The arguments passed to the handler constructor or factory"
2020-05-18 04:18:14 +00:00
} ,
"services" : {
"type" : "array" ,
"description" : "If supplied and non-empty, the named services are requested from the service container and prepended before 'args'."
2019-05-09 01:36:18 +00:00
}
}
}
} ,
2020-05-20 21:59:38 +00:00
"ParsoidModules" : {
"type" : "array" ,
"description" : "List of extension modules to be registered with the Parsoid wikitext parser" ,
"items" : {
"oneOf" : [
{
"type" : "string" ,
"description" : "The fully-qualified name of a class implementing Wikimedia\\Parsoid\\Ext\\ExtensionModule"
} ,
{
"type" : "object" ,
2022-01-19 15:51:59 +00:00
"description" : "Object factory specification for a class implementing Wikimedia\\Parsoid\\Ext\\ExtensionModule" ,
2020-05-20 21:59:38 +00:00
"properties" : {
"factory" : {
2022-07-26 22:31:50 +00:00
"type" : [ "string" , "array" ] ,
2020-05-20 21:59:38 +00:00
"description" : "A factory function to be called to create an ExtensionModule. This should be omitted if a class is specified."
2022-01-19 15:51:59 +00:00
}
} ,
"required" : [ "factory" ]
} ,
{
"type" : "object" ,
"description" : "Object factory specification for a class implementing Wikimedia\\Parsoid\\Ext\\ExtensionModule" ,
"properties" : {
2020-05-20 21:59:38 +00:00
"class" : {
"type" : "string" ,
"description" : "The fully-qualified class name of a class implemeting Wikimedia\\Parsoid\\Ext\\ExtensionModule. This should be omitted if a factory is specified."
}
2021-12-16 13:47:20 +00:00
} ,
2022-01-19 15:51:59 +00:00
"required" : [ "class" ]
2020-05-20 21:59:38 +00:00
} ,
{
"type" : "object" ,
"description" : "A Parsoid extension module configuration array" ,
"properties" : {
2022-01-19 15:51:59 +00:00
"class" : {
"type" : "null" ,
"description" : "This property must not be present in a configuration array"
} ,
"factory" : {
"type" : "null" ,
"description" : "This property must not be present in a configuration array"
} ,
2020-05-20 21:59:38 +00:00
"domProcessors" : {
"type" : "array" ,
"items" : {
"description" : "Object factory specification of a class implementing Wikimedia\\Parsoid\\Ext\\DOMProcessor"
}
} ,
"styles" : {
"type" : "array" ,
"items" : {
"type" : "string" ,
"description" : "Additional ResourceLoader styles to include"
}
} ,
2022-01-19 15:51:59 +00:00
"annotations" : {
"type" : "array" ,
"items" : {
"type" : "string" ,
"description" : "The name of an annotation tag"
}
} ,
2020-05-20 21:59:38 +00:00
"tags" : {
"type" : "array" ,
"items" : {
"type" : "object" ,
"description" : "An extension tag" ,
"properties" : {
"name" : {
"type" : "string" ,
2021-12-16 13:47:20 +00:00
"description" : "The name of the extension tag"
2020-05-20 21:59:38 +00:00
} ,
"handler" : {
"description" : "An object factory specification of a class extending Wikimedia\\Parsoid\\Ext\\ExtensionTagHandler"
} ,
"options" : {
"type" : "object" ,
"description" : "Additional Parsoid processing configuration for this extension tag"
}
2021-12-16 13:47:20 +00:00
} ,
2022-07-26 22:31:50 +00:00
"required" : [ "name" ]
2020-05-20 21:59:38 +00:00
}
}
2022-01-19 15:51:59 +00:00
}
2020-05-20 21:59:38 +00:00
}
]
}
} ,
2022-02-28 03:05:58 +00:00
"TempUserSerialProviders" : {
2022-07-26 22:31:50 +00:00
"type" : "object" ,
2022-02-28 03:05:58 +00:00
"description" : "Map of temporary user serial provider type name to ObjectFactory spec" ,
"patternProperties" : {
".*" : {
"type" : "object" ,
"properties" : {
"factory" : {
2022-07-26 22:31:50 +00:00
"type" : [ "string" , "array" ] ,
2022-02-28 03:05:58 +00:00
"description" : "A factory function"
} ,
"class" : {
"type" : "string" ,
"description" : "The fully-qualified class name of the handler. This should be omitted if a factory is specified."
} ,
"args" : {
"type" : "array" ,
"description" : "The arguments passed to the constructor or factory"
} ,
"services" : {
"type" : "array" ,
"description" : "If supplied and non-empty, the named services are requested from the service container and prepended before 'args'."
}
}
}
}
} ,
"TempUserSerialMappings" : {
2022-07-26 22:31:50 +00:00
"type" : "object" ,
2022-02-28 03:05:58 +00:00
"description" : "Map of temporary user serial map type name to ObjectFactory spec" ,
"patternProperties" : {
".*" : {
"type" : "object" ,
"properties" : {
"factory" : {
2022-07-26 22:31:50 +00:00
"type" : [ "string" , "array" ] ,
2022-02-28 03:05:58 +00:00
"description" : "A factory function"
} ,
"class" : {
"type" : "string" ,
"description" : "The fully-qualified class name of the handler. This should be omitted if a factory is specified."
} ,
"args" : {
"type" : "array" ,
"description" : "The arguments passed to the constructor or factory"
} ,
"services" : {
"type" : "array" ,
"description" : "If supplied and non-empty, the named services are requested from the service container and prepended before 'args'."
}
}
}
}
} ,
2016-12-02 06:02:28 +00:00
"attributes" : {
2022-07-26 22:31:50 +00:00
"description" : "Registration information for other extensions" ,
2016-12-02 06:02:28 +00:00
"type" : "object" ,
"patternProperties" : {
".*" : {
"type" : "object" ,
"patternProperties" : {
".*" : {
2022-07-26 22:31:50 +00:00
"type" : [ "array" , "object" ]
2016-12-02 06:02:28 +00:00
}
}
}
}
} ,
2015-12-27 09:03:41 +00:00
"load_composer_autoloader" : {
"type" : "boolean" ,
"description" : "Load the composer autoloader for this extension, if one is present"
Implement extension registration from an extension.json file
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
2014-10-15 00:31:15 +00:00
}
}
}
