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
|
|
|
<?php
|
|
|
|
|
|
|
|
|
|
class ExtensionProcessor implements Processor {
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Keys that should be set to $GLOBALS
|
|
|
|
|
*
|
|
|
|
|
* @var array
|
|
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected static $globalSettings = [
|
2016-11-04 16:32:19 +00:00
|
|
|
'ActionFilteredLogs',
|
|
|
|
|
'Actions',
|
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
|
|
|
'AddGroups',
|
2016-11-04 16:32:19 +00:00
|
|
|
'APIFormatModules',
|
|
|
|
|
'APIListModules',
|
|
|
|
|
'APIMetaModules',
|
|
|
|
|
'APIModules',
|
|
|
|
|
'APIPropModules',
|
2015-11-22 20:17:00 +00:00
|
|
|
'AuthManagerAutoConfig',
|
2016-11-04 16:32:19 +00:00
|
|
|
'AvailableRights',
|
2016-01-02 07:13:31 +00:00
|
|
|
'CentralIdLookupProviders',
|
2016-06-14 21:21:02 +00:00
|
|
|
'ChangeCredentialsBlacklist',
|
2016-11-04 16:32:19 +00:00
|
|
|
'ConfigRegistry',
|
|
|
|
|
'ContentHandlers',
|
|
|
|
|
'DefaultUserOptions',
|
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
|
|
|
'ExtensionEntryPointListFiles',
|
2016-11-04 16:32:19 +00:00
|
|
|
'ExtensionFunctions',
|
|
|
|
|
'FeedClasses',
|
2016-11-17 22:36:09 +00:00
|
|
|
'FileExtensions',
|
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
|
|
|
'FilterLogTypes',
|
2016-11-04 16:32:19 +00:00
|
|
|
'GrantPermissionGroups',
|
|
|
|
|
'GrantPermissions',
|
|
|
|
|
'GroupPermissions',
|
|
|
|
|
'GroupsAddToSelf',
|
|
|
|
|
'GroupsRemoveFromSelf',
|
|
|
|
|
'HiddenPrefs',
|
|
|
|
|
'ImplicitGroups',
|
|
|
|
|
'JobClasses',
|
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
|
|
|
'LogActions',
|
|
|
|
|
'LogActionsHandlers',
|
2016-11-04 16:32:19 +00:00
|
|
|
'LogHeaders',
|
|
|
|
|
'LogNames',
|
|
|
|
|
'LogRestrictions',
|
|
|
|
|
'LogTypes',
|
|
|
|
|
'MediaHandlers',
|
2016-10-31 17:12:56 +00:00
|
|
|
'PasswordPolicy',
|
2016-11-04 16:32:19 +00:00
|
|
|
'RateLimits',
|
2018-07-31 22:19:40 +00:00
|
|
|
'RawHtmlMessages',
|
2018-11-15 23:39:58 +00:00
|
|
|
'ReauthenticateTime',
|
2016-11-04 16:32:19 +00:00
|
|
|
'RecentChangesFlags',
|
|
|
|
|
'RemoveCredentialsBlacklist',
|
|
|
|
|
'RemoveGroups',
|
|
|
|
|
'ResourceLoaderSources',
|
|
|
|
|
'RevokePermissions',
|
|
|
|
|
'SessionProviders',
|
2021-08-13 19:39:48 +00:00
|
|
|
'SpecialPages'
|
2016-02-17 09:09:32 +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
|
|
|
|
2016-12-02 06:02:28 +00:00
|
|
|
/**
|
|
|
|
|
* Top-level attributes that come from MW core
|
|
|
|
|
*
|
|
|
|
|
* @var string[]
|
|
|
|
|
*/
|
2020-04-07 22:09:05 +00:00
|
|
|
protected const CORE_ATTRIBS = [
|
2020-05-20 21:59:38 +00:00
|
|
|
'ParsoidModules',
|
2020-04-30 17:47:36 +00:00
|
|
|
'RestRoutes',
|
2016-12-02 06:02:28 +00:00
|
|
|
'SkinOOUIThemes',
|
2020-04-30 18:29:56 +00:00
|
|
|
'SearchMappings',
|
2016-12-02 06:02:28 +00:00
|
|
|
'TrackingCategories',
|
|
|
|
|
];
|
|
|
|
|
|
2015-08-01 07:38:27 +00:00
|
|
|
/**
|
|
|
|
|
* Mapping of global settings to their specific merge strategies.
|
|
|
|
|
*
|
|
|
|
|
* @see ExtensionRegistry::exportExtractedData
|
|
|
|
|
* @see getExtractedInfo
|
|
|
|
|
* @var array
|
|
|
|
|
*/
|
2020-04-07 22:09:05 +00:00
|
|
|
protected const MERGE_STRATEGIES = [
|
2016-11-04 16:32:19 +00:00
|
|
|
'wgAuthManagerAutoConfig' => 'array_plus_2d',
|
|
|
|
|
'wgCapitalLinkOverrides' => 'array_plus',
|
2015-08-01 07:38:27 +00:00
|
|
|
'wgExtraGenderNamespaces' => 'array_plus',
|
2016-11-04 16:32:19 +00:00
|
|
|
'wgGrantPermissions' => 'array_plus_2d',
|
|
|
|
|
'wgGroupPermissions' => 'array_plus_2d',
|
|
|
|
|
'wgHooks' => 'array_merge_recursive',
|
2015-08-01 07:38:27 +00:00
|
|
|
'wgNamespaceContentModels' => 'array_plus',
|
2015-08-01 07:39:52 +00:00
|
|
|
'wgNamespaceProtection' => 'array_plus',
|
2016-11-04 16:32:19 +00:00
|
|
|
'wgNamespacesWithSubpages' => 'array_plus',
|
2016-10-31 17:12:56 +00:00
|
|
|
'wgPasswordPolicy' => 'array_merge_recursive',
|
2016-01-07 18:52:01 +00:00
|
|
|
'wgRateLimits' => 'array_plus_2d',
|
2016-11-04 16:32:19 +00:00
|
|
|
'wgRevokePermissions' => 'array_plus_2d',
|
2016-02-17 09:09:32 +00:00
|
|
|
];
|
2015-08-01 07:38:27 +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
|
|
|
/**
|
|
|
|
|
* Keys that are part of the extension credits
|
|
|
|
|
*
|
|
|
|
|
* @var array
|
|
|
|
|
*/
|
2020-04-07 22:09:05 +00:00
|
|
|
protected const CREDIT_ATTRIBS = [
|
2020-05-25 18:47:06 +00:00
|
|
|
'type',
|
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',
|
|
|
|
|
'description',
|
|
|
|
|
'descriptionmsg',
|
|
|
|
|
'license-name',
|
2020-04-30 17:47:36 +00:00
|
|
|
'name',
|
|
|
|
|
'namemsg',
|
|
|
|
|
'url',
|
|
|
|
|
'version',
|
2016-02-17 09:09:32 +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-05-18 06:22:46 +00:00
|
|
|
/**
|
2019-01-18 20:21:35 +00:00
|
|
|
* Things that are not 'attributes', and are not in
|
2020-04-07 22:09:05 +00:00
|
|
|
* $globalSettings or CREDIT_ATTRIBS.
|
2015-05-18 06:22:46 +00:00
|
|
|
*
|
|
|
|
|
* @var array
|
|
|
|
|
*/
|
2020-04-07 22:09:05 +00:00
|
|
|
protected const NOT_ATTRIBS = [
|
2015-05-18 06:22:46 +00:00
|
|
|
'callback',
|
2020-04-30 17:47:36 +00:00
|
|
|
'config',
|
|
|
|
|
'config_prefix',
|
|
|
|
|
'load_composer_autoloader',
|
|
|
|
|
'manifest_version',
|
|
|
|
|
'namespaces',
|
2019-12-12 19:21:32 +00:00
|
|
|
'requires',
|
2020-04-30 17:47:36 +00:00
|
|
|
'AutoloadClasses',
|
|
|
|
|
'ExtensionMessagesFiles',
|
2015-05-18 06:22:46 +00:00
|
|
|
'Hooks',
|
2019-10-12 03:17:51 +00:00
|
|
|
'MessagePosterModule',
|
2015-05-18 06:22:46 +00:00
|
|
|
'MessagesDirs',
|
2020-04-30 17:47:36 +00:00
|
|
|
'OOUIThemePaths',
|
|
|
|
|
'ParserTestFiles',
|
|
|
|
|
'QUnitTestModule',
|
|
|
|
|
'ResourceFileModulePaths',
|
|
|
|
|
'ResourceModuleSkinStyles',
|
|
|
|
|
'ResourceModules',
|
2016-08-26 06:00:28 +00:00
|
|
|
'ServiceWiringFiles',
|
2016-02-17 09:09:32 +00:00
|
|
|
];
|
2015-05-18 06:22: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
|
|
|
/**
|
|
|
|
|
* Stuff that is going to be set to $GLOBALS
|
|
|
|
|
*
|
|
|
|
|
* Some keys are pre-set to arrays so we can += to them
|
|
|
|
|
*
|
|
|
|
|
* @var array
|
|
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $globals = [
|
|
|
|
|
'wgExtensionMessagesFiles' => [],
|
|
|
|
|
'wgMessagesDirs' => [],
|
|
|
|
|
];
|
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
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Things that should be define()'d
|
|
|
|
|
*
|
|
|
|
|
* @var array
|
|
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $defines = [];
|
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
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Things to be called once registration of these extensions are done
|
2016-12-01 07:19:37 +00:00
|
|
|
* keyed by the name of the extension that it belongs to
|
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
|
|
|
*
|
|
|
|
|
* @var callable[]
|
|
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $callbacks = [];
|
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
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @var array
|
|
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $credits = [];
|
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
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Any thing else in the $info that hasn't
|
|
|
|
|
* already been processed
|
|
|
|
|
*
|
|
|
|
|
* @var array
|
|
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $attributes = [];
|
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-12-02 06:02:28 +00:00
|
|
|
/**
|
|
|
|
|
* Extension attributes, keyed by name =>
|
|
|
|
|
* settings.
|
|
|
|
|
*
|
|
|
|
|
* @var array
|
|
|
|
|
*/
|
|
|
|
|
protected $extAttributes = [];
|
|
|
|
|
|
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
|
|
|
/**
|
|
|
|
|
* @param string $path
|
|
|
|
|
* @param array $info
|
2015-05-20 01:45:10 +00:00
|
|
|
* @param int $version manifest_version for info
|
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-20 01:45:10 +00:00
|
|
|
public function extractInfo( $path, array $info, $version ) {
|
2016-07-22 22:08:21 +00:00
|
|
|
$dir = dirname( $path );
|
2020-02-10 14:47:46 +00:00
|
|
|
$this->extractHooks( $info, $path );
|
2015-02-06 23:02:26 +00:00
|
|
|
$this->extractExtensionMessagesFiles( $dir, $info );
|
|
|
|
|
$this->extractMessagesDirs( $dir, $info );
|
2021-08-13 19:39:48 +00:00
|
|
|
$this->extractSkins( $dir, $info );
|
2018-05-20 18:32:57 +00:00
|
|
|
$this->extractSkinImportPaths( $dir, $info );
|
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
|
|
|
$this->extractNamespaces( $info );
|
|
|
|
|
$this->extractResourceLoaderModules( $dir, $info );
|
2018-02-10 06:21:19 +00:00
|
|
|
if ( isset( $info['ServiceWiringFiles'] ) ) {
|
|
|
|
|
$this->extractPathBasedGlobal(
|
|
|
|
|
'wgServiceWiringFiles',
|
|
|
|
|
$dir,
|
|
|
|
|
$info['ServiceWiringFiles']
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
if ( isset( $info['ParserTestFiles'] ) ) {
|
|
|
|
|
$this->extractPathBasedGlobal(
|
|
|
|
|
'wgParserTestFiles',
|
|
|
|
|
$dir,
|
|
|
|
|
$info['ParserTestFiles']
|
|
|
|
|
);
|
|
|
|
|
}
|
2016-12-01 07:19:37 +00:00
|
|
|
$name = $this->extractCredits( $path, $info );
|
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
|
|
|
if ( isset( $info['callback'] ) ) {
|
2016-12-01 07:19:37 +00:00
|
|
|
$this->callbacks[$name] = $info['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
|
|
|
}
|
|
|
|
|
|
2018-05-15 17:26:43 +00:00
|
|
|
// config should be after all core globals are extracted,
|
|
|
|
|
// so duplicate setting detection will work fully
|
2021-09-04 19:04:03 +00:00
|
|
|
if ( $version >= 2 ) {
|
2018-05-15 17:26:43 +00:00
|
|
|
$this->extractConfig2( $info, $dir );
|
|
|
|
|
} else {
|
|
|
|
|
// $version === 1
|
|
|
|
|
$this->extractConfig1( $info );
|
|
|
|
|
}
|
|
|
|
|
|
2020-06-01 20:22:48 +00:00
|
|
|
// Record the extension name in the ParsoidModules property
|
|
|
|
|
if ( isset( $info['ParsoidModules'] ) ) {
|
|
|
|
|
foreach ( $info['ParsoidModules'] as &$module ) {
|
|
|
|
|
$module['name'] = $name;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-04 19:04:03 +00:00
|
|
|
if ( $version >= 2 ) {
|
2016-12-02 06:02:28 +00:00
|
|
|
$this->extractAttributes( $path, $info );
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
foreach ( $info as $key => $val ) {
|
2016-12-02 06:02:28 +00:00
|
|
|
// If it's a global setting,
|
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
|
|
|
if ( in_array( $key, self::$globalSettings ) ) {
|
2020-04-30 18:23:45 +00:00
|
|
|
$this->storeToArrayRecursive( $path, "wg$key", $val, $this->globals );
|
2016-12-02 06:02:28 +00:00
|
|
|
continue;
|
|
|
|
|
}
|
2015-01-13 19:46:53 +00:00
|
|
|
// Ignore anything that starts with a @
|
2016-12-02 06:02:28 +00:00
|
|
|
if ( $key[0] === '@' ) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
|
|
|
|
|
2021-09-04 19:04:03 +00:00
|
|
|
if ( $version >= 2 ) {
|
2021-04-18 15:49:35 +00:00
|
|
|
// Only allowed attributes are set
|
2020-04-07 22:09:05 +00:00
|
|
|
if ( in_array( $key, self::CORE_ATTRIBS ) ) {
|
2020-04-30 18:28:44 +00:00
|
|
|
$this->storeToArray( $path, $key, $val, $this->attributes );
|
2016-12-02 06:02:28 +00:00
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
// version === 1
|
2020-04-07 22:09:05 +00:00
|
|
|
if ( !in_array( $key, self::NOT_ATTRIBS )
|
|
|
|
|
&& !in_array( $key, self::CREDIT_ATTRIBS )
|
2016-12-02 06:02:28 +00:00
|
|
|
) {
|
2021-04-18 15:49:35 +00:00
|
|
|
// If it's not disallowed, it's an attribute
|
2020-04-30 18:23:45 +00:00
|
|
|
$this->storeToArrayRecursive( $path, $key, $val, $this->attributes );
|
2016-12-02 06:02:28 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* @param string $path
|
|
|
|
|
* @param array $info
|
|
|
|
|
*/
|
|
|
|
|
protected function extractAttributes( $path, array $info ) {
|
|
|
|
|
if ( isset( $info['attributes'] ) ) {
|
|
|
|
|
foreach ( $info['attributes'] as $extName => $value ) {
|
2020-04-30 18:23:45 +00:00
|
|
|
$this->storeToArrayRecursive( $path, $extName, $value, $this->extAttributes );
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function getExtractedInfo() {
|
2015-08-01 07:38:27 +00:00
|
|
|
// Make sure the merge strategies are set
|
|
|
|
|
foreach ( $this->globals as $key => $val ) {
|
2020-04-07 22:09:05 +00:00
|
|
|
if ( isset( self::MERGE_STRATEGIES[$key] ) ) {
|
|
|
|
|
$this->globals[$key][ExtensionRegistry::MERGE_STRATEGY] = self::MERGE_STRATEGIES[$key];
|
2015-08-01 07:38:27 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-12-02 06:02:28 +00:00
|
|
|
// Merge $this->extAttributes into $this->attributes depending on what is loaded
|
|
|
|
|
foreach ( $this->extAttributes as $extName => $value ) {
|
|
|
|
|
// Only set the attribute if $extName is loaded (and hence present in credits)
|
|
|
|
|
if ( isset( $this->credits[$extName] ) ) {
|
|
|
|
|
foreach ( $value as $attrName => $attrValue ) {
|
2020-04-30 18:23:45 +00:00
|
|
|
$this->storeToArrayRecursive(
|
2016-12-02 06:02:28 +00:00
|
|
|
'', // Don't provide a path since it's impossible to generate an error here
|
|
|
|
|
$extName . $attrName,
|
|
|
|
|
$attrValue,
|
|
|
|
|
$this->attributes
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
unset( $this->extAttributes[$extName] );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-02-17 09:09:32 +00:00
|
|
|
return [
|
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
|
|
|
'globals' => $this->globals,
|
|
|
|
|
'defines' => $this->defines,
|
|
|
|
|
'callbacks' => $this->callbacks,
|
|
|
|
|
'credits' => $this->credits,
|
|
|
|
|
'attributes' => $this->attributes,
|
2016-02-17 09:09:32 +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
|
|
|
}
|
|
|
|
|
|
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
|
|
|
public function getRequirements( array $info, $includeDev ) {
|
|
|
|
|
// Quick shortcuts
|
|
|
|
|
if ( !$includeDev || !isset( $info['dev-requires'] ) ) {
|
|
|
|
|
return $info['requires'] ?? [];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
if ( !isset( $info['requires'] ) ) {
|
|
|
|
|
return $info['dev-requires'] ?? [];
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
// OK, we actually have to merge everything
|
|
|
|
|
$merged = [];
|
|
|
|
|
|
|
|
|
|
// Helper that combines version requirements by
|
|
|
|
|
// picking the non-null if one is, or combines
|
|
|
|
|
// the two. Note that it is not possible for
|
|
|
|
|
// both inputs to be null.
|
2021-02-10 22:31:02 +00:00
|
|
|
$pick = static function ( $a, $b ) {
|
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
|
|
|
if ( $a === null ) {
|
|
|
|
|
return $b;
|
|
|
|
|
} elseif ( $b === null ) {
|
|
|
|
|
return $a;
|
|
|
|
|
} else {
|
|
|
|
|
return "$a $b";
|
|
|
|
|
}
|
|
|
|
|
};
|
|
|
|
|
|
|
|
|
|
$req = $info['requires'];
|
|
|
|
|
$dev = $info['dev-requires'];
|
|
|
|
|
if ( isset( $req['MediaWiki'] ) || isset( $dev['MediaWiki'] ) ) {
|
|
|
|
|
$merged['MediaWiki'] = $pick(
|
|
|
|
|
$req['MediaWiki'] ?? null,
|
|
|
|
|
$dev['MediaWiki'] ?? null
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$platform = array_merge(
|
|
|
|
|
array_keys( $req['platform'] ?? [] ),
|
|
|
|
|
array_keys( $dev['platform'] ?? [] )
|
|
|
|
|
);
|
|
|
|
|
if ( $platform ) {
|
|
|
|
|
foreach ( $platform as $pkey ) {
|
|
|
|
|
if ( $pkey === 'php' ) {
|
|
|
|
|
$value = $pick(
|
|
|
|
|
$req['platform']['php'] ?? null,
|
|
|
|
|
$dev['platform']['php'] ?? null
|
|
|
|
|
);
|
|
|
|
|
} else {
|
|
|
|
|
// Prefer dev value, but these should be constant
|
|
|
|
|
// anyways (ext-* and ability-*)
|
|
|
|
|
$value = $dev['platform'][$pkey] ?? $req['platform'][$pkey];
|
|
|
|
|
}
|
|
|
|
|
$merged['platform'][$pkey] = $value;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
foreach ( [ 'extensions', 'skins' ] as $thing ) {
|
|
|
|
|
$things = array_merge(
|
|
|
|
|
array_keys( $req[$thing] ?? [] ),
|
|
|
|
|
array_keys( $dev[$thing] ?? [] )
|
|
|
|
|
);
|
|
|
|
|
foreach ( $things as $name ) {
|
|
|
|
|
$merged[$thing][$name] = $pick(
|
|
|
|
|
$req[$thing][$name] ?? null,
|
|
|
|
|
$dev[$thing][$name] ?? null
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return $merged;
|
2015-05-14 05:51:55 +00:00
|
|
|
}
|
|
|
|
|
|
2020-02-10 14:47:46 +00:00
|
|
|
/**
|
|
|
|
|
* When handler value is an array, set $wgHooks or Hooks attribute
|
|
|
|
|
* Could be legacy hook e.g. 'GlobalFunctionName' or non-legacy hook
|
|
|
|
|
* referencing a handler definition from 'HookHandler' attribute
|
|
|
|
|
*
|
|
|
|
|
* @param array $callback Handler
|
|
|
|
|
* @param array $hookHandlersAttr handler definitions from 'HookHandler' attribute
|
|
|
|
|
* @param string $name
|
|
|
|
|
* @param string $path extension.json file path
|
|
|
|
|
* @throws UnexpectedValueException
|
|
|
|
|
*/
|
|
|
|
|
private function setArrayHookHandler(
|
|
|
|
|
array $callback,
|
|
|
|
|
array $hookHandlersAttr,
|
|
|
|
|
string $name,
|
|
|
|
|
string $path
|
|
|
|
|
) {
|
|
|
|
|
if ( isset( $callback['handler'] ) ) {
|
|
|
|
|
$handlerName = $callback['handler'];
|
|
|
|
|
$handlerDefinition = $hookHandlersAttr[$handlerName] ?? false;
|
|
|
|
|
if ( !$handlerDefinition ) {
|
|
|
|
|
throw new UnexpectedValueException(
|
|
|
|
|
"Missing handler definition for $name in HookHandlers attribute in $path"
|
|
|
|
|
);
|
|
|
|
|
}
|
|
|
|
|
$callback['handler'] = $handlerDefinition;
|
2020-04-16 06:20:16 +00:00
|
|
|
$callback['extensionPath'] = $path;
|
2020-02-10 14:47:46 +00:00
|
|
|
$this->attributes['Hooks'][$name][] = $callback;
|
|
|
|
|
} else {
|
|
|
|
|
foreach ( $callback as $callable ) {
|
|
|
|
|
if ( is_array( $callable ) ) {
|
|
|
|
|
if ( isset( $callable['handler'] ) ) { // Non-legacy style handler
|
|
|
|
|
$this->setArrayHookHandler( $callable, $hookHandlersAttr, $name, $path );
|
|
|
|
|
} else { // Legacy style handler array
|
|
|
|
|
$this->globals['wgHooks'][$name][] = $callable;
|
2016-04-29 21:21:40 +00:00
|
|
|
}
|
2020-02-10 14:47:46 +00:00
|
|
|
} elseif ( is_string( $callable ) ) {
|
2020-04-16 06:20:16 +00:00
|
|
|
$this->setStringHookHandler( $callable, $hookHandlersAttr, $name, $path );
|
2015-05-13 19:30:21 +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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-10 14:47:46 +00:00
|
|
|
/**
|
|
|
|
|
* When handler value is a string, set $wgHooks or Hooks attribute.
|
|
|
|
|
* Could be legacy hook e.g. 'GlobalFunctionName' or non-legacy hook
|
|
|
|
|
* referencing a handler definition from 'HookHandler' attribute
|
|
|
|
|
*
|
|
|
|
|
* @param string $callback Handler
|
|
|
|
|
* @param array $hookHandlersAttr handler definitions from 'HookHandler' attribute
|
|
|
|
|
* @param string $name
|
2020-04-16 06:20:16 +00:00
|
|
|
* @param string $path
|
2020-02-10 14:47:46 +00:00
|
|
|
*/
|
|
|
|
|
private function setStringHookHandler(
|
|
|
|
|
string $callback,
|
|
|
|
|
array $hookHandlersAttr,
|
2020-04-16 06:20:16 +00:00
|
|
|
string $name,
|
|
|
|
|
string $path
|
2020-02-10 14:47:46 +00:00
|
|
|
) {
|
|
|
|
|
if ( isset( $hookHandlersAttr[$callback] ) ) {
|
2020-04-16 06:20:16 +00:00
|
|
|
$handler = [
|
|
|
|
|
'handler' => $hookHandlersAttr[$callback],
|
|
|
|
|
'extensionPath' => $path
|
|
|
|
|
];
|
2020-02-10 14:47:46 +00:00
|
|
|
$this->attributes['Hooks'][$name][] = $handler;
|
|
|
|
|
} else { // legacy style handler
|
|
|
|
|
$this->globals['wgHooks'][$name][] = $callback;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
|
|
|
|
* Extract hook information from Hooks and HookHandler attributes.
|
|
|
|
|
* Store hook in $wgHooks if a legacy style handler or the 'Hooks' attribute if
|
|
|
|
|
* a non-legacy handler
|
|
|
|
|
*
|
|
|
|
|
* @param array $info attributes and associated values from extension.json
|
|
|
|
|
* @param string $path path to extension.json
|
|
|
|
|
*/
|
|
|
|
|
protected function extractHooks( array $info, string $path ) {
|
2020-04-16 06:20:16 +00:00
|
|
|
$extName = $info['name'];
|
|
|
|
|
if ( isset( $info['Hooks'] ) ) {
|
|
|
|
|
$hookHandlersAttr = [];
|
|
|
|
|
foreach ( $info['HookHandlers'] ?? [] as $name => $def ) {
|
|
|
|
|
$hookHandlersAttr[$name] = [ 'name' => "$extName-$name" ] + $def;
|
|
|
|
|
}
|
|
|
|
|
foreach ( $info['Hooks'] as $name => $callback ) {
|
|
|
|
|
if ( is_string( $callback ) ) {
|
|
|
|
|
$this->setStringHookHandler( $callback, $hookHandlersAttr, $name, $path );
|
|
|
|
|
} elseif ( is_array( $callback ) ) {
|
|
|
|
|
$this->setArrayHookHandler( $callback, $hookHandlersAttr, $name, $path );
|
|
|
|
|
}
|
|
|
|
|
}
|
2020-02-10 14:47:46 +00:00
|
|
|
}
|
2020-04-16 06:20:16 +00:00
|
|
|
if ( isset( $info['DeprecatedHooks'] ) ) {
|
|
|
|
|
$deprecatedHooks = [];
|
2020-05-01 18:24:32 +00:00
|
|
|
foreach ( $info['DeprecatedHooks'] as $name => $deprecatedHookInfo ) {
|
|
|
|
|
$deprecatedHookInfo += [ 'component' => $extName ];
|
|
|
|
|
$deprecatedHooks[$name] = $deprecatedHookInfo;
|
2020-04-16 06:20:16 +00:00
|
|
|
}
|
|
|
|
|
if ( isset( $this->attributes['DeprecatedHooks'] ) ) {
|
|
|
|
|
$this->attributes['DeprecatedHooks'] += $deprecatedHooks;
|
|
|
|
|
} else {
|
|
|
|
|
$this->attributes['DeprecatedHooks'] = $deprecatedHooks;
|
2020-02-10 14:47: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
|
|
|
/**
|
|
|
|
|
* Register namespaces with the appropriate global settings
|
|
|
|
|
*
|
|
|
|
|
* @param array $info
|
|
|
|
|
*/
|
|
|
|
|
protected function extractNamespaces( array $info ) {
|
|
|
|
|
if ( isset( $info['namespaces'] ) ) {
|
|
|
|
|
foreach ( $info['namespaces'] as $ns ) {
|
2017-05-10 16:00:38 +00:00
|
|
|
if ( defined( $ns['constant'] ) ) {
|
|
|
|
|
// If the namespace constant is already defined, use it.
|
|
|
|
|
// This allows namespace IDs to be overwritten locally.
|
|
|
|
|
$id = constant( $ns['constant'] );
|
|
|
|
|
} else {
|
|
|
|
|
$id = $ns['id'];
|
|
|
|
|
}
|
2020-03-16 15:55:45 +00:00
|
|
|
$this->defines[ $ns['constant'] ] = $id;
|
2017-05-10 16:00:38 +00:00
|
|
|
|
2016-07-29 08:09:24 +00:00
|
|
|
if ( !( isset( $ns['conditional'] ) && $ns['conditional'] ) ) {
|
|
|
|
|
// If it is not conditional, register it
|
|
|
|
|
$this->attributes['ExtensionNamespaces'][$id] = $ns['name'];
|
|
|
|
|
}
|
2021-03-16 13:28:51 +00:00
|
|
|
if ( isset( $ns['movable'] ) && !$ns['movable'] ) {
|
|
|
|
|
$this->attributes['ImmovableNamespaces'][] = $id;
|
|
|
|
|
}
|
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
|
|
|
if ( isset( $ns['gender'] ) ) {
|
|
|
|
|
$this->globals['wgExtraGenderNamespaces'][$id] = $ns['gender'];
|
|
|
|
|
}
|
|
|
|
|
if ( isset( $ns['subpages'] ) && $ns['subpages'] ) {
|
|
|
|
|
$this->globals['wgNamespacesWithSubpages'][$id] = true;
|
|
|
|
|
}
|
|
|
|
|
if ( isset( $ns['content'] ) && $ns['content'] ) {
|
|
|
|
|
$this->globals['wgContentNamespaces'][] = $id;
|
|
|
|
|
}
|
|
|
|
|
if ( isset( $ns['defaultcontentmodel'] ) ) {
|
|
|
|
|
$this->globals['wgNamespaceContentModels'][$id] = $ns['defaultcontentmodel'];
|
|
|
|
|
}
|
2015-08-01 07:39:52 +00:00
|
|
|
if ( isset( $ns['protection'] ) ) {
|
|
|
|
|
$this->globals['wgNamespaceProtection'][$id] = $ns['protection'];
|
|
|
|
|
}
|
2015-08-01 08:37:10 +00:00
|
|
|
if ( isset( $ns['capitallinkoverride'] ) ) {
|
|
|
|
|
$this->globals['wgCapitalLinkOverrides'][$id] = $ns['capitallinkoverride'];
|
|
|
|
|
}
|
2021-03-16 13:28: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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
protected function extractResourceLoaderModules( $dir, array $info ) {
|
2017-10-06 22:17:58 +00:00
|
|
|
$defaultPaths = $info['ResourceFileModulePaths'] ?? false;
|
2015-02-06 09:46:05 +00:00
|
|
|
if ( isset( $defaultPaths['localBasePath'] ) ) {
|
2016-02-16 20:39:34 +00:00
|
|
|
if ( $defaultPaths['localBasePath'] === '' ) {
|
|
|
|
|
// Avoid double slashes (e.g. /extensions/Example//path)
|
|
|
|
|
$defaultPaths['localBasePath'] = $dir;
|
|
|
|
|
} else {
|
|
|
|
|
$defaultPaths['localBasePath'] = "$dir/{$defaultPaths['localBasePath']}";
|
|
|
|
|
}
|
2015-02-06 09:46:05 +00:00
|
|
|
}
|
|
|
|
|
|
2017-03-17 02:14:05 +00:00
|
|
|
foreach ( [ 'ResourceModules', 'ResourceModuleSkinStyles', 'OOUIThemePaths' ] as $setting ) {
|
2015-04-02 17:12:52 +00:00
|
|
|
if ( isset( $info[$setting] ) ) {
|
|
|
|
|
foreach ( $info[$setting] as $name => $data ) {
|
|
|
|
|
if ( isset( $data['localBasePath'] ) ) {
|
2016-02-16 20:39:34 +00:00
|
|
|
if ( $data['localBasePath'] === '' ) {
|
|
|
|
|
// Avoid double slashes (e.g. /extensions/Example//path)
|
|
|
|
|
$data['localBasePath'] = $dir;
|
|
|
|
|
} else {
|
|
|
|
|
$data['localBasePath'] = "$dir/{$data['localBasePath']}";
|
|
|
|
|
}
|
2015-04-02 17:12:52 +00:00
|
|
|
}
|
|
|
|
|
if ( $defaultPaths ) {
|
|
|
|
|
$data += $defaultPaths;
|
|
|
|
|
}
|
2020-03-09 20:12:45 +00:00
|
|
|
$this->attributes[$setting][$name] = $data;
|
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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2019-01-18 20:21:35 +00:00
|
|
|
|
|
|
|
|
if ( isset( $info['QUnitTestModule'] ) ) {
|
|
|
|
|
$data = $info['QUnitTestModule'];
|
|
|
|
|
if ( isset( $data['localBasePath'] ) ) {
|
|
|
|
|
if ( $data['localBasePath'] === '' ) {
|
|
|
|
|
// Avoid double slashes (e.g. /extensions/Example//path)
|
|
|
|
|
$data['localBasePath'] = $dir;
|
|
|
|
|
} else {
|
|
|
|
|
$data['localBasePath'] = "$dir/{$data['localBasePath']}";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
$this->attributes['QUnitTestModules']["test.{$info['name']}"] = $data;
|
|
|
|
|
}
|
2019-10-12 03:17:51 +00:00
|
|
|
|
|
|
|
|
if ( isset( $info['MessagePosterModule'] ) ) {
|
|
|
|
|
$data = $info['MessagePosterModule'];
|
|
|
|
|
$basePath = $data['localBasePath'] ?? '';
|
|
|
|
|
$baseDir = $basePath === '' ? $dir : "$dir/$basePath";
|
|
|
|
|
foreach ( $data['scripts'] ?? [] as $scripts ) {
|
2020-10-28 02:18:32 +00:00
|
|
|
$this->attributes['MessagePosterModule']['scripts'][] =
|
|
|
|
|
new ResourceLoaderFilePath( $scripts, $baseDir );
|
2019-10-12 03:17:51 +00:00
|
|
|
}
|
|
|
|
|
foreach ( $data['dependencies'] ?? [] as $dependency ) {
|
|
|
|
|
$this->attributes['MessagePosterModule']['dependencies'][] = $dependency;
|
|
|
|
|
}
|
|
|
|
|
}
|
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-02-06 23:02:26 +00:00
|
|
|
protected function extractExtensionMessagesFiles( $dir, array $info ) {
|
|
|
|
|
if ( isset( $info['ExtensionMessagesFiles'] ) ) {
|
2017-12-13 09:41:03 +00:00
|
|
|
foreach ( $info['ExtensionMessagesFiles'] as &$file ) {
|
|
|
|
|
$file = "$dir/$file";
|
|
|
|
|
}
|
|
|
|
|
$this->globals["wgExtensionMessagesFiles"] += $info['ExtensionMessagesFiles'];
|
2015-02-06 23:02: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
|
|
|
/**
|
|
|
|
|
* Set message-related settings, which need to be expanded to use
|
|
|
|
|
* absolute paths
|
|
|
|
|
*
|
|
|
|
|
* @param string $dir
|
|
|
|
|
* @param array $info
|
|
|
|
|
*/
|
2015-02-06 23:02:26 +00:00
|
|
|
protected function extractMessagesDirs( $dir, array $info ) {
|
|
|
|
|
if ( isset( $info['MessagesDirs'] ) ) {
|
|
|
|
|
foreach ( $info['MessagesDirs'] as $name => $files ) {
|
|
|
|
|
foreach ( (array)$files as $file ) {
|
|
|
|
|
$this->globals["wgMessagesDirs"][$name][] = "$dir/$file";
|
2015-01-30 20:56:02 +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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2021-08-13 19:39:48 +00:00
|
|
|
/**
|
|
|
|
|
* Extract skins and handle path correction for templateDirectory.
|
|
|
|
|
*
|
|
|
|
|
* @param string $dir
|
|
|
|
|
* @param array $info
|
|
|
|
|
*/
|
|
|
|
|
protected function extractSkins( $dir, array $info ) {
|
|
|
|
|
if ( isset( $info['ValidSkinNames'] ) ) {
|
|
|
|
|
foreach ( $info['ValidSkinNames'] as $skinKey => $data ) {
|
|
|
|
|
if ( isset( $data['args'][0]['templateDirectory'] ) ) {
|
|
|
|
|
$templateDirectory = $data['args'][0]['templateDirectory'];
|
|
|
|
|
$correctedPath = $dir . '/' . $templateDirectory;
|
|
|
|
|
// Historically the template directory was relative to core
|
|
|
|
|
// but it really should've been relative to the skin directory.
|
|
|
|
|
// If the path exists relative to the skin directory, assume that
|
|
|
|
|
// is what was intended. Otherwise fall back on the previous behavior
|
|
|
|
|
// of having it relative to core.
|
|
|
|
|
if ( is_dir( $correctedPath ) ) {
|
|
|
|
|
$data['args'][0]['templateDirectory'] = $correctedPath;
|
|
|
|
|
} else {
|
|
|
|
|
$data['args'][0]['templateDirectory'] = $templateDirectory;
|
2021-08-17 17:33:43 +00:00
|
|
|
wfDeprecatedMsg(
|
|
|
|
|
'Template directory should be relative to skin or omitted.',
|
|
|
|
|
'1.37'
|
|
|
|
|
);
|
2021-08-13 19:39:48 +00:00
|
|
|
}
|
|
|
|
|
} elseif ( isset( $data['args'][0] ) ) {
|
|
|
|
|
// If not set, we set a sensible default.
|
|
|
|
|
$data['args'][0]['templateDirectory'] = $dir . '/templates';
|
|
|
|
|
}
|
|
|
|
|
$this->globals['wgValidSkinNames'][$skinKey] = $data;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2018-05-20 18:32:57 +00:00
|
|
|
/**
|
|
|
|
|
* @param string $dir
|
|
|
|
|
* @param array $info
|
|
|
|
|
*/
|
|
|
|
|
protected function extractSkinImportPaths( $dir, array $info ) {
|
|
|
|
|
if ( isset( $info['SkinLessImportPaths'] ) ) {
|
|
|
|
|
foreach ( $info['SkinLessImportPaths'] as $skin => $subpath ) {
|
|
|
|
|
$this->attributes['SkinLessImportPaths'][$skin] = "$dir/$subpath";
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-12-30 01:52:11 +00:00
|
|
|
/**
|
|
|
|
|
* @param string $path
|
|
|
|
|
* @param array $info
|
2016-12-01 07:19:37 +00:00
|
|
|
* @return string Name of thing
|
2015-12-30 01:52:11 +00:00
|
|
|
* @throws Exception
|
|
|
|
|
*/
|
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
|
|
|
protected function extractCredits( $path, array $info ) {
|
2016-02-17 09:09:32 +00:00
|
|
|
$credits = [
|
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
|
|
|
'path' => $path,
|
2020-05-25 18:47:06 +00:00
|
|
|
'type' => 'other',
|
2016-02-17 09:09:32 +00:00
|
|
|
];
|
2020-04-07 22:09:05 +00:00
|
|
|
foreach ( self::CREDIT_ATTRIBS as $attr ) {
|
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
|
|
|
if ( isset( $info[$attr] ) ) {
|
|
|
|
|
$credits[$attr] = $info[$attr];
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-12-30 01:52:11 +00:00
|
|
|
$name = $credits['name'];
|
|
|
|
|
|
|
|
|
|
// If someone is loading the same thing twice, throw
|
|
|
|
|
// a nice error (T121493)
|
|
|
|
|
if ( isset( $this->credits[$name] ) ) {
|
|
|
|
|
$firstPath = $this->credits[$name]['path'];
|
|
|
|
|
$secondPath = $credits['path'];
|
|
|
|
|
throw new Exception( "It was attempted to load $name twice, from $firstPath and $secondPath." );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$this->credits[$name] = $credits;
|
2016-12-01 07:19:37 +00:00
|
|
|
|
|
|
|
|
return $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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
/**
|
2016-06-22 22:33:35 +00:00
|
|
|
* Set configuration settings for manifest_version == 1
|
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
|
|
|
* @todo In the future, this should be done via Config interfaces
|
|
|
|
|
*
|
|
|
|
|
* @param array $info
|
|
|
|
|
*/
|
2016-06-22 22:33:35 +00:00
|
|
|
protected function extractConfig1( array $info ) {
|
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
|
|
|
if ( isset( $info['config'] ) ) {
|
2015-08-23 22:56:59 +00:00
|
|
|
if ( isset( $info['config']['_prefix'] ) ) {
|
|
|
|
|
$prefix = $info['config']['_prefix'];
|
|
|
|
|
unset( $info['config']['_prefix'] );
|
|
|
|
|
} else {
|
|
|
|
|
$prefix = 'wg';
|
|
|
|
|
}
|
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
|
|
|
foreach ( $info['config'] as $key => $val ) {
|
2015-01-27 07:00:07 +00:00
|
|
|
if ( $key[0] !== '@' ) {
|
2018-05-15 17:26:43 +00:00
|
|
|
$this->addConfigGlobal( "$prefix$key", $val, $info['name'] );
|
2015-01-27 07:00:07 +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
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2016-06-22 22:33:35 +00:00
|
|
|
/**
|
|
|
|
|
* Set configuration settings for manifest_version == 2
|
|
|
|
|
* @todo In the future, this should be done via Config interfaces
|
|
|
|
|
*
|
|
|
|
|
* @param array $info
|
2016-07-22 22:08:21 +00:00
|
|
|
* @param string $dir
|
2016-06-22 22:33:35 +00:00
|
|
|
*/
|
2016-07-22 22:08:21 +00:00
|
|
|
protected function extractConfig2( array $info, $dir ) {
|
2018-10-20 21:55:44 +00:00
|
|
|
$prefix = $info['config_prefix'] ?? 'wg';
|
2016-06-22 22:33:35 +00:00
|
|
|
if ( isset( $info['config'] ) ) {
|
|
|
|
|
foreach ( $info['config'] as $key => $data ) {
|
2021-05-12 08:10:58 +00:00
|
|
|
if ( !array_key_exists( 'value', $data ) ) {
|
|
|
|
|
throw new UnexpectedValueException( "Missing value for config $key" );
|
|
|
|
|
}
|
|
|
|
|
|
2016-06-22 22:33:35 +00:00
|
|
|
$value = $data['value'];
|
2019-07-26 09:47:37 +00:00
|
|
|
if ( isset( $data['path'] ) && $data['path'] ) {
|
2021-02-10 22:31:02 +00:00
|
|
|
$callback = static function ( $value ) use ( $dir ) {
|
2019-07-26 09:47:37 +00:00
|
|
|
return "$dir/$value";
|
|
|
|
|
};
|
|
|
|
|
if ( is_array( $value ) ) {
|
|
|
|
|
$value = array_map( $callback, $value );
|
|
|
|
|
} else {
|
|
|
|
|
$value = $callback( $value );
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-10-18 04:46:11 +00:00
|
|
|
if ( isset( $data['merge_strategy'] ) ) {
|
2016-07-22 21:59:07 +00:00
|
|
|
$value[ExtensionRegistry::MERGE_STRATEGY] = $data['merge_strategy'];
|
2016-06-22 22:33:35 +00:00
|
|
|
}
|
2018-05-15 17:26:43 +00:00
|
|
|
$this->addConfigGlobal( "$prefix$key", $value, $info['name'] );
|
2017-01-13 05:21:00 +00:00
|
|
|
$data['providedby'] = $info['name'];
|
|
|
|
|
if ( isset( $info['ConfigRegistry'][0] ) ) {
|
|
|
|
|
$data['configregistry'] = array_keys( $info['ConfigRegistry'] )[0];
|
|
|
|
|
}
|
2016-06-22 22:33:35 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2017-08-28 15:03:47 +00:00
|
|
|
/**
|
|
|
|
|
* Helper function to set a value to a specific global, if it isn't set already.
|
|
|
|
|
*
|
|
|
|
|
* @param string $key The config key with the prefix and anything
|
|
|
|
|
* @param mixed $value The value of the config
|
2018-05-15 17:26:43 +00:00
|
|
|
* @param string $extName Name of the extension
|
2017-08-28 15:03:47 +00:00
|
|
|
*/
|
2018-05-15 17:26:43 +00:00
|
|
|
private function addConfigGlobal( $key, $value, $extName ) {
|
2017-08-28 15:03:47 +00:00
|
|
|
if ( array_key_exists( $key, $this->globals ) ) {
|
|
|
|
|
throw new RuntimeException(
|
2018-05-15 17:26:43 +00:00
|
|
|
"The configuration setting '$key' was already set by MediaWiki core or"
|
|
|
|
|
. " another extension, and cannot be set again by $extName." );
|
2017-08-28 15:03:47 +00:00
|
|
|
}
|
|
|
|
|
$this->globals[$key] = $value;
|
|
|
|
|
}
|
|
|
|
|
|
2018-02-10 06:21:19 +00:00
|
|
|
protected function extractPathBasedGlobal( $global, $dir, $paths ) {
|
|
|
|
|
foreach ( $paths as $path ) {
|
|
|
|
|
$this->globals[$global][] = "$dir/$path";
|
2015-05-03 06:02:22 +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
|
|
|
/**
|
2020-04-30 18:23:45 +00:00
|
|
|
* Stores $value to $array; using array_merge_recursive() if $array already contains $name
|
|
|
|
|
*
|
2016-03-03 18:53:30 +00:00
|
|
|
* @param string $path
|
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
|
|
|
* @param string $name
|
2015-06-16 23:08:44 +00:00
|
|
|
* @param array $value
|
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
|
|
|
* @param array &$array
|
2015-06-16 23:08:44 +00:00
|
|
|
* @throws InvalidArgumentException
|
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
|
|
|
*/
|
2020-04-30 18:23:45 +00:00
|
|
|
protected function storeToArrayRecursive( $path, $name, $value, &$array ) {
|
2015-06-16 23:08:44 +00:00
|
|
|
if ( !is_array( $value ) ) {
|
2016-03-03 18:53:30 +00:00
|
|
|
throw new InvalidArgumentException( "The value for '$name' should be an array (from $path)" );
|
2015-06-16 23:08:44 +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
|
|
|
if ( isset( $array[$name] ) ) {
|
|
|
|
|
$array[$name] = array_merge_recursive( $array[$name], $value );
|
|
|
|
|
} else {
|
|
|
|
|
$array[$name] = $value;
|
|
|
|
|
}
|
|
|
|
|
}
|
2015-12-27 09:03:41 +00:00
|
|
|
|
2020-04-30 18:28:44 +00:00
|
|
|
/**
|
|
|
|
|
* Stores $value to $array; using array_merge() if $array already contains $name
|
|
|
|
|
*
|
|
|
|
|
* @param string $path
|
|
|
|
|
* @param string $name
|
|
|
|
|
* @param array $value
|
|
|
|
|
* @param array &$array
|
|
|
|
|
* @throws InvalidArgumentException
|
|
|
|
|
*/
|
|
|
|
|
protected function storeToArray( $path, $name, $value, &$array ) {
|
|
|
|
|
if ( !is_array( $value ) ) {
|
|
|
|
|
throw new InvalidArgumentException( "The value for '$name' should be an array (from $path)" );
|
|
|
|
|
}
|
|
|
|
|
if ( isset( $array[$name] ) ) {
|
|
|
|
|
$array[$name] = array_merge( $array[$name], $value );
|
|
|
|
|
} else {
|
|
|
|
|
$array[$name] = $value;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-12-27 09:03:41 +00:00
|
|
|
public function getExtraAutoloaderPaths( $dir, array $info ) {
|
2016-02-17 09:09:32 +00:00
|
|
|
$paths = [];
|
2015-12-27 09:03:41 +00:00
|
|
|
if ( isset( $info['load_composer_autoloader'] ) && $info['load_composer_autoloader'] === true ) {
|
2017-09-23 05:20:16 +00:00
|
|
|
$paths[] = "$dir/vendor/autoload.php";
|
2015-12-27 09:03:41 +00:00
|
|
|
}
|
|
|
|
|
return $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
|
|
|
}
|
