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",
|
|
|
|
|
"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"
|
|
|
|
|
},
|
|
|
|
|
"additionalItems": false
|
|
|
|
|
},
|
|
|
|
|
"version": {
|
|
|
|
|
"type": "string",
|
|
|
|
|
"description": "The version of this release of the extension."
|
|
|
|
|
},
|
|
|
|
|
"url": {
|
|
|
|
|
"type": "string",
|
|
|
|
|
"description": "URL to the homepage for the extension.",
|
|
|
|
|
"format": "uri"
|
|
|
|
|
},
|
|
|
|
|
"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",
|
|
|
|
|
"description": "Short identifier for the license under which the extension is released.",
|
|
|
|
|
"enum": [
|
|
|
|
|
"AFL-1.1",
|
|
|
|
|
"AFL-1.2",
|
|
|
|
|
"AFL-2.0",
|
|
|
|
|
"AFL-2.1",
|
|
|
|
|
"AFL-3.0",
|
|
|
|
|
"APL-1.0",
|
|
|
|
|
"Aladdin",
|
|
|
|
|
"ANTLR-PD",
|
|
|
|
|
"Apache-1.0",
|
|
|
|
|
"Apache-1.1",
|
|
|
|
|
"Apache-2.0",
|
|
|
|
|
"APSL-1.0",
|
|
|
|
|
"APSL-1.1",
|
|
|
|
|
"APSL-1.2",
|
|
|
|
|
"APSL-2.0",
|
|
|
|
|
"Artistic-1.0",
|
|
|
|
|
"Artistic-1.0-cl8",
|
|
|
|
|
"Artistic-1.0-Perl",
|
|
|
|
|
"Artistic-2.0",
|
|
|
|
|
"AAL",
|
|
|
|
|
"BitTorrent-1.0",
|
|
|
|
|
"BitTorrent-1.1",
|
|
|
|
|
"BSL-1.0",
|
|
|
|
|
"BSD-2-Clause",
|
|
|
|
|
"BSD-2-Clause-FreeBSD",
|
|
|
|
|
"BSD-2-Clause-NetBSD",
|
|
|
|
|
"BSD-3-Clause",
|
|
|
|
|
"BSD-3-Clause-Clear",
|
|
|
|
|
"BSD-4-Clause",
|
|
|
|
|
"BSD-4-Clause-UC",
|
|
|
|
|
"CECILL-1.0",
|
|
|
|
|
"CECILL-1.1",
|
|
|
|
|
"CECILL-2.0",
|
|
|
|
|
"CECILL-B",
|
|
|
|
|
"CECILL-C",
|
|
|
|
|
"ClArtistic",
|
|
|
|
|
"CNRI-Python",
|
|
|
|
|
"CNRI-Python-GPL-Compatible",
|
|
|
|
|
"CPOL-1.02",
|
|
|
|
|
"CDDL-1.0",
|
|
|
|
|
"CDDL-1.1",
|
|
|
|
|
"CPAL-1.0",
|
|
|
|
|
"CPL-1.0",
|
|
|
|
|
"CATOSL-1.1",
|
|
|
|
|
"Condor-1.1",
|
|
|
|
|
"CC-BY-1.0",
|
|
|
|
|
"CC-BY-2.0",
|
|
|
|
|
"CC-BY-2.5",
|
|
|
|
|
"CC-BY-3.0",
|
|
|
|
|
"CC-BY-ND-1.0",
|
|
|
|
|
"CC-BY-ND-2.0",
|
|
|
|
|
"CC-BY-ND-2.5",
|
|
|
|
|
"CC-BY-ND-3.0",
|
|
|
|
|
"CC-BY-NC-1.0",
|
|
|
|
|
"CC-BY-NC-2.0",
|
|
|
|
|
"CC-BY-NC-2.5",
|
|
|
|
|
"CC-BY-NC-3.0",
|
|
|
|
|
"CC-BY-NC-ND-1.0",
|
|
|
|
|
"CC-BY-NC-ND-2.0",
|
|
|
|
|
"CC-BY-NC-ND-2.5",
|
|
|
|
|
"CC-BY-NC-ND-3.0",
|
|
|
|
|
"CC-BY-NC-SA-1.0",
|
|
|
|
|
"CC-BY-NC-SA-2.0",
|
|
|
|
|
"CC-BY-NC-SA-2.5",
|
|
|
|
|
"CC-BY-NC-SA-3.0",
|
|
|
|
|
"CC-BY-SA-1.0",
|
|
|
|
|
"CC-BY-SA-2.0",
|
|
|
|
|
"CC-BY-SA-2.5",
|
|
|
|
|
"CC-BY-SA-3.0",
|
|
|
|
|
"CC0-1.0",
|
|
|
|
|
"CUA-OPL-1.0",
|
|
|
|
|
"D-FSL-1.0",
|
|
|
|
|
"WTFPL",
|
|
|
|
|
"EPL-1.0",
|
|
|
|
|
"eCos-2.0",
|
|
|
|
|
"ECL-1.0",
|
|
|
|
|
"ECL-2.0",
|
|
|
|
|
"EFL-1.0",
|
|
|
|
|
"EFL-2.0",
|
|
|
|
|
"Entessa",
|
|
|
|
|
"ErlPL-1.1",
|
|
|
|
|
"EUDatagrid",
|
|
|
|
|
"EUPL-1.0",
|
|
|
|
|
"EUPL-1.1",
|
|
|
|
|
"Fair",
|
|
|
|
|
"Frameworx-1.0",
|
|
|
|
|
"FTL",
|
|
|
|
|
"AGPL-1.0",
|
|
|
|
|
"AGPL-3.0",
|
|
|
|
|
"GFDL-1.1",
|
|
|
|
|
"GFDL-1.2",
|
|
|
|
|
"GFDL-1.3",
|
|
|
|
|
"GPL-1.0",
|
|
|
|
|
"GPL-1.0+",
|
|
|
|
|
"GPL-2.0",
|
|
|
|
|
"GPL-2.0+",
|
|
|
|
|
"GPL-2.0-with-autoconf-exception",
|
|
|
|
|
"GPL-2.0-with-bison-exception",
|
|
|
|
|
"GPL-2.0-with-classpath-exception",
|
|
|
|
|
"GPL-2.0-with-font-exception",
|
|
|
|
|
"GPL-2.0-with-GCC-exception",
|
|
|
|
|
"GPL-3.0",
|
|
|
|
|
"GPL-3.0+",
|
|
|
|
|
"GPL-3.0-with-autoconf-exception",
|
|
|
|
|
"GPL-3.0-with-GCC-exception",
|
|
|
|
|
"LGPL-2.1",
|
|
|
|
|
"LGPL-2.1+",
|
|
|
|
|
"LGPL-3.0",
|
|
|
|
|
"LGPL-3.0+",
|
|
|
|
|
"LGPL-2.0",
|
|
|
|
|
"LGPL-2.0+",
|
|
|
|
|
"gSOAP-1.3b",
|
|
|
|
|
"HPND",
|
|
|
|
|
"IBM-pibs",
|
|
|
|
|
"IPL-1.0",
|
|
|
|
|
"Imlib2",
|
|
|
|
|
"IJG",
|
|
|
|
|
"Intel",
|
|
|
|
|
"IPA",
|
|
|
|
|
"ISC",
|
|
|
|
|
"JSON",
|
|
|
|
|
"LPPL-1.3a",
|
|
|
|
|
"LPPL-1.0",
|
|
|
|
|
"LPPL-1.1",
|
|
|
|
|
"LPPL-1.2",
|
|
|
|
|
"LPPL-1.3c",
|
|
|
|
|
"Libpng",
|
|
|
|
|
"LPL-1.02",
|
|
|
|
|
"LPL-1.0",
|
|
|
|
|
"MS-PL",
|
|
|
|
|
"MS-RL",
|
|
|
|
|
"MirOS",
|
|
|
|
|
"MIT",
|
|
|
|
|
"Motosoto",
|
|
|
|
|
"MPL-1.0",
|
|
|
|
|
"MPL-1.1",
|
|
|
|
|
"MPL-2.0",
|
|
|
|
|
"MPL-2.0-no-copyleft-exception",
|
|
|
|
|
"Multics",
|
|
|
|
|
"NASA-1.3",
|
|
|
|
|
"Naumen",
|
|
|
|
|
"NBPL-1.0",
|
|
|
|
|
"NGPL",
|
|
|
|
|
"NOSL",
|
|
|
|
|
"NPL-1.0",
|
|
|
|
|
"NPL-1.1",
|
|
|
|
|
"Nokia",
|
|
|
|
|
"NPOSL-3.0",
|
|
|
|
|
"NTP",
|
|
|
|
|
"OCLC-2.0",
|
|
|
|
|
"ODbL-1.0",
|
|
|
|
|
"PDDL-1.0",
|
|
|
|
|
"OGTSL",
|
|
|
|
|
"OLDAP-2.2.2",
|
|
|
|
|
"OLDAP-1.1",
|
|
|
|
|
"OLDAP-1.2",
|
|
|
|
|
"OLDAP-1.3",
|
|
|
|
|
"OLDAP-1.4",
|
|
|
|
|
"OLDAP-2.0",
|
|
|
|
|
"OLDAP-2.0.1",
|
|
|
|
|
"OLDAP-2.1",
|
|
|
|
|
"OLDAP-2.2",
|
|
|
|
|
"OLDAP-2.2.1",
|
|
|
|
|
"OLDAP-2.3",
|
|
|
|
|
"OLDAP-2.4",
|
|
|
|
|
"OLDAP-2.5",
|
|
|
|
|
"OLDAP-2.6",
|
|
|
|
|
"OLDAP-2.7",
|
|
|
|
|
"OPL-1.0",
|
|
|
|
|
"OSL-1.0",
|
|
|
|
|
"OSL-2.0",
|
|
|
|
|
"OSL-2.1",
|
|
|
|
|
"OSL-3.0",
|
|
|
|
|
"OLDAP-2.8",
|
|
|
|
|
"OpenSSL",
|
|
|
|
|
"PHP-3.0",
|
|
|
|
|
"PHP-3.01",
|
|
|
|
|
"PostgreSQL",
|
|
|
|
|
"Python-2.0",
|
|
|
|
|
"QPL-1.0",
|
|
|
|
|
"RPSL-1.0",
|
|
|
|
|
"RPL-1.1",
|
|
|
|
|
"RPL-1.5",
|
|
|
|
|
"RHeCos-1.1",
|
|
|
|
|
"RSCPL",
|
|
|
|
|
"Ruby",
|
|
|
|
|
"SAX-PD",
|
|
|
|
|
"SGI-B-1.0",
|
|
|
|
|
"SGI-B-1.1",
|
|
|
|
|
"SGI-B-2.0",
|
|
|
|
|
"OFL-1.0",
|
|
|
|
|
"OFL-1.1",
|
|
|
|
|
"SimPL-2.0",
|
|
|
|
|
"Sleepycat",
|
|
|
|
|
"SMLNJ",
|
|
|
|
|
"SugarCRM-1.1.3",
|
|
|
|
|
"SISSL",
|
|
|
|
|
"SISSL-1.2",
|
|
|
|
|
"SPL-1.0",
|
|
|
|
|
"Watcom-1.0",
|
|
|
|
|
"NCSA",
|
|
|
|
|
"VSL-1.0",
|
|
|
|
|
"W3C",
|
|
|
|
|
"WXwindows",
|
|
|
|
|
"Xnet",
|
|
|
|
|
"X11",
|
|
|
|
|
"XFree86-1.1",
|
|
|
|
|
"YPL-1.0",
|
|
|
|
|
"YPL-1.1",
|
|
|
|
|
"Zimbra-1.3",
|
|
|
|
|
"Zlib",
|
|
|
|
|
"ZPL-1.1",
|
|
|
|
|
"ZPL-2.0",
|
|
|
|
|
"ZPL-2.1",
|
|
|
|
|
"Unlicense"
|
|
|
|
|
]
|
|
|
|
|
},
|
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",
|
|
|
|
|
"additionalProperties": false,
|
|
|
|
|
"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",
|
|
|
|
|
"description": "A single ResourceLoader module descriptor",
|
|
|
|
|
"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"
|
|
|
|
|
},
|
|
|
|
|
"scripts": {
|
2015-05-29 00:31:16 +00:00
|
|
|
"type": ["string", "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": "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": {
|
2015-05-29 23:06:10 +00:00
|
|
|
"type": ["string", "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": "Scripts to include in debug contexts",
|
|
|
|
|
"items": {
|
|
|
|
|
"type": "string"
|
|
|
|
|
}
|
|
|
|
|
},
|
|
|
|
|
"loaderScripts": {
|
2015-05-29 23:06:10 +00:00
|
|
|
"type": ["string", "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": "Scripts to include in the startup module",
|
|
|
|
|
"items": {
|
|
|
|
|
"type": "string"
|
|
|
|
|
}
|
|
|
|
|
},
|
|
|
|
|
"dependencies": {
|
2015-05-29 23:06:10 +00:00
|
|
|
"type": ["string", "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": "Modules which must be loaded before this module",
|
|
|
|
|
"items": {
|
|
|
|
|
"type": "string"
|
|
|
|
|
}
|
|
|
|
|
},
|
|
|
|
|
"styles": {
|
2015-05-29 00:31:16 +00:00
|
|
|
"type": ["string", "array", "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
|
|
|
"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": {
|
2015-05-29 23:06:10 +00:00
|
|
|
"type": ["string", "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": "Messages to always load",
|
|
|
|
|
"items": {
|
|
|
|
|
"type": "string"
|
|
|
|
|
}
|
|
|
|
|
},
|
|
|
|
|
"group": {
|
|
|
|
|
"type": "string",
|
|
|
|
|
"description": "Group which this module should be loaded together with"
|
|
|
|
|
},
|
|
|
|
|
"position": {
|
|
|
|
|
"type": "string",
|
|
|
|
|
"description": "Position on the page to load this module at",
|
|
|
|
|
"enum": [
|
|
|
|
|
"bottom",
|
|
|
|
|
"top"
|
|
|
|
|
]
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
},
|
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"
|
|
|
|
|
},
|
|
|
|
|
"ResourceLoaderLESSVars": {
|
|
|
|
|
"type": "object",
|
|
|
|
|
"description": "ResourceLoader LESS variables"
|
|
|
|
|
},
|
|
|
|
|
"ResourceLoaderLESSFunctions": {
|
|
|
|
|
"type": "object",
|
|
|
|
|
"description": "ResourceLoader LESS functions"
|
|
|
|
|
},
|
|
|
|
|
"ResourceLoaderLESSImportPaths": {
|
|
|
|
|
"type": "object",
|
|
|
|
|
"description": "ResourceLoader import paths"
|
|
|
|
|
},
|
2015-01-11 04:12:01 +00:00
|
|
|
"ConfigRegistry": {
|
|
|
|
|
"type": "object",
|
|
|
|
|
"description": "Registry of factory functions to create Config objects"
|
|
|
|
|
},
|
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": {
|
|
|
|
|
"type": "object",
|
|
|
|
|
"description": "Method to add extra namespaces",
|
|
|
|
|
"properties": {
|
|
|
|
|
"id": {
|
|
|
|
|
"type": "integer"
|
|
|
|
|
},
|
|
|
|
|
"constant": {
|
|
|
|
|
"type": "string"
|
|
|
|
|
},
|
|
|
|
|
"name": {
|
|
|
|
|
"type": "string"
|
|
|
|
|
},
|
|
|
|
|
"gender": {
|
|
|
|
|
"type": "object",
|
|
|
|
|
"properties": {
|
|
|
|
|
"male": {
|
|
|
|
|
"type": "string"
|
|
|
|
|
},
|
|
|
|
|
"female": {
|
|
|
|
|
"type": "string"
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
},
|
|
|
|
|
"subpages": {
|
|
|
|
|
"type": "boolean",
|
|
|
|
|
"default": false
|
|
|
|
|
},
|
|
|
|
|
"content": {
|
|
|
|
|
"type": "boolean",
|
|
|
|
|
"default": false
|
|
|
|
|
},
|
|
|
|
|
"defaultcontentmodel": {
|
|
|
|
|
"type": "string"
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
},
|
|
|
|
|
"TrackingCategories": {
|
|
|
|
|
"type": "array",
|
|
|
|
|
"description": "Tracking category message keys"
|
|
|
|
|
},
|
|
|
|
|
"DefaultUserOptions": {
|
|
|
|
|
"type": "object",
|
|
|
|
|
"description": "Default values of user options"
|
|
|
|
|
},
|
|
|
|
|
"HiddenPrefs": {
|
|
|
|
|
"type": "array",
|
|
|
|
|
"description": "Preferences users cannot set"
|
|
|
|
|
},
|
|
|
|
|
"GroupPermissions": {
|
|
|
|
|
"type": "object",
|
|
|
|
|
"description": "Default permissions to give to user groups"
|
|
|
|
|
},
|
|
|
|
|
"RevokePermissions": {
|
|
|
|
|
"type": "object",
|
|
|
|
|
"description": "Default permissions to revoke from user groups"
|
|
|
|
|
},
|
|
|
|
|
"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",
|
|
|
|
|
"description": "User rights added by the extension"
|
|
|
|
|
},
|
|
|
|
|
"ContentHandlers": {
|
|
|
|
|
"type": "object",
|
|
|
|
|
"description": "Mapping of model ID to class name"
|
|
|
|
|
},
|
|
|
|
|
"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"
|
|
|
|
|
],
|
|
|
|
|
"description": "Function to call after setup has finished"
|
|
|
|
|
},
|
|
|
|
|
"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",
|
|
|
|
|
"description": "SpecialPages implemented in this extension (mapping of page name to class name)"
|
|
|
|
|
},
|
|
|
|
|
"AutoloadClasses": {
|
|
|
|
|
"type": "object"
|
|
|
|
|
},
|
|
|
|
|
"Hooks": {
|
|
|
|
|
"type": "object",
|
|
|
|
|
"description": "Hooks this extension uses (mapping of hook name to callback)"
|
|
|
|
|
},
|
|
|
|
|
"JobClasses": {
|
|
|
|
|
"type": "object",
|
|
|
|
|
"description": "Job types this extension implements (mapping of job type to class name)"
|
|
|
|
|
},
|
|
|
|
|
"LogTypes": {
|
|
|
|
|
"type": "array",
|
|
|
|
|
"description": "List of new log types this extension uses"
|
|
|
|
|
},
|
|
|
|
|
"LogRestrictions": {
|
|
|
|
|
"type": "object"
|
|
|
|
|
},
|
|
|
|
|
"FilterLogTypes": {
|
|
|
|
|
"type": "array"
|
|
|
|
|
},
|
|
|
|
|
"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": {
|
|
|
|
|
"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
|
|
|
"callback": {
|
|
|
|
|
"type": [
|
|
|
|
|
"array",
|
|
|
|
|
"string"
|
|
|
|
|
],
|
|
|
|
|
"description": "A function to be called right after MediaWiki processes this file"
|
|
|
|
|
},
|
|
|
|
|
"config": {
|
|
|
|
|
"type": "object",
|
|
|
|
|
"description": "Configuration options for this extension"
|
2015-05-03 06:02:22 +00:00
|
|
|
},
|
|
|
|
|
"ParserTestFiles": {
|
|
|
|
|
"type": "array",
|
|
|
|
|
"description": "Parser test suite files to be run by parserTests.php when no specific filename is passed to it"
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|