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
|
|
|
|
|
|
2024-05-16 12:28:33 +00:00
|
|
|
use MediaWiki\Json\FormatJson;
|
2024-08-10 05:17:59 +00:00
|
|
|
use MediaWiki\Registration\ExtensionProcessor;
|
|
|
|
|
use MediaWiki\Registration\ExtensionRegistry;
|
2024-01-13 18:41:24 +00:00
|
|
|
use Wikimedia\Composer\ComposerJson;
|
|
|
|
|
|
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
|
|
|
require_once __DIR__ . '/Maintenance.php';
|
|
|
|
|
|
|
|
|
|
class ConvertExtensionToRegistration extends Maintenance {
|
|
|
|
|
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $custom = [
|
2015-01-11 04:17:36 +00:00
|
|
|
'MessagesDirs' => 'handleMessagesDirs',
|
2015-05-01 03:32:44 +00:00
|
|
|
'ExtensionMessagesFiles' => 'handleExtensionMessagesFiles',
|
Implement extension registration from an extension.json file
Introduces wfLoadExtension()/wfLoadSkin() which should be used in
LocalSettings.php rather than require-ing a PHP entry point.
Extensions and skins would add "extension.json" or "skin.json" files
in their root, which contains all the information typically
present in PHP entry point files (classes to autoload, special pages,
API modules, etc.) A full schema can be found at
docs/extension.schema.json, and a script to validate these to the
schema is provided. An additional script is provided to convert
typical PHP entry point files into their JSON equivalents.
The basic flow of loading an extension goes like:
* Get the ExtensionRegistry singleton instance
* ExtensionRegistry takes a filename, reads the file or tries
to get the parsed JSON from APC if possible.
* The JSON is run through a Processor instance,
which registers things with the appropriate
global settings.
* The output of the processor is cached in APC if possible.
* The extension/skin is marked as loaded in the
ExtensionRegistry and a callback function is executed
if one was specified.
For ideal performance, a batch loading method is also provided:
* The absolute path name to the JSON file is queued
in the ExtensionRegistry instance.
* When loadFromQueue() is called, it constructs a hash
unique to the members of the current queue, and sees
if the queue has been cached in APC. If not, it processes
each file individually, and combines the result of each
Processor into one giant array, which is cached in APC.
* The giant array then sets various global settings,
defines constants, and calls callbacks.
To invalidate the cached processed info, by default the mtime
of each JSON file is checked. However that can be slow if you
have a large number of extensions, so you can set $wgExtensionInfoMTime
to the mtime of one file, and `touch` it whenever you update
your extensions.
Change-Id: I7074b65d07c5c7d4e3f1fb0755d74a0b07ed4596
2014-10-15 00:31:15 +00:00
|
|
|
'AutoloadClasses' => 'removeAbsolutePath',
|
|
|
|
|
'ExtensionCredits' => 'handleCredits',
|
|
|
|
|
'ResourceModules' => 'handleResourceModules',
|
2015-04-02 17:12:52 +00:00
|
|
|
'ResourceModuleSkinStyles' => 'handleResourceModules',
|
Implement extension registration from an extension.json file
Introduces wfLoadExtension()/wfLoadSkin() which should be used in
LocalSettings.php rather than require-ing a PHP entry point.
Extensions and skins would add "extension.json" or "skin.json" files
in their root, which contains all the information typically
present in PHP entry point files (classes to autoload, special pages,
API modules, etc.) A full schema can be found at
docs/extension.schema.json, and a script to validate these to the
schema is provided. An additional script is provided to convert
typical PHP entry point files into their JSON equivalents.
The basic flow of loading an extension goes like:
* Get the ExtensionRegistry singleton instance
* ExtensionRegistry takes a filename, reads the file or tries
to get the parsed JSON from APC if possible.
* The JSON is run through a Processor instance,
which registers things with the appropriate
global settings.
* The output of the processor is cached in APC if possible.
* The extension/skin is marked as loaded in the
ExtensionRegistry and a callback function is executed
if one was specified.
For ideal performance, a batch loading method is also provided:
* The absolute path name to the JSON file is queued
in the ExtensionRegistry instance.
* When loadFromQueue() is called, it constructs a hash
unique to the members of the current queue, and sees
if the queue has been cached in APC. If not, it processes
each file individually, and combines the result of each
Processor into one giant array, which is cached in APC.
* The giant array then sets various global settings,
defines constants, and calls callbacks.
To invalidate the cached processed info, by default the mtime
of each JSON file is checked. However that can be slow if you
have a large number of extensions, so you can set $wgExtensionInfoMTime
to the mtime of one file, and `touch` it whenever you update
your extensions.
Change-Id: I7074b65d07c5c7d4e3f1fb0755d74a0b07ed4596
2014-10-15 00:31:15 +00:00
|
|
|
'Hooks' => 'handleHooks',
|
|
|
|
|
'ExtensionFunctions' => 'handleExtensionFunctions',
|
2018-04-13 18:44:59 +00:00
|
|
|
'ParserTestFiles' => 'removeAutodiscoveredParserTestFiles',
|
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-01-29 23:21:14 +00:00
|
|
|
/**
|
|
|
|
|
* Things that were formerly globals and should still be converted
|
|
|
|
|
*
|
2019-02-28 11:33:47 +00:00
|
|
|
* @var string[]
|
2015-01-29 23:21:14 +00:00
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $formerGlobals = [
|
2015-01-29 23:21:14 +00:00
|
|
|
'TrackingCategories',
|
2016-02-17 09:09:32 +00:00
|
|
|
];
|
2015-01-29 23:21:14 +00:00
|
|
|
|
2015-05-16 11:45:24 +00:00
|
|
|
/**
|
|
|
|
|
* No longer supported globals (with reason) should not be converted and emit a warning
|
|
|
|
|
*
|
2019-02-28 11:33:47 +00:00
|
|
|
* @var string[]
|
2015-05-16 11:45:24 +00:00
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $noLongerSupportedGlobals = [
|
2015-06-25 16:40:18 +00:00
|
|
|
'SpecialPageGroups' => 'deprecated', // Deprecated 1.21, removed in 1.26
|
2016-02-17 09:09:32 +00:00
|
|
|
];
|
2015-05-16 11:45:24 +00:00
|
|
|
|
2015-01-13 19:31:45 +00:00
|
|
|
/**
|
|
|
|
|
* Keys that should be put at the top of the generated JSON file (T86608)
|
|
|
|
|
*
|
2019-02-28 11:33:47 +00:00
|
|
|
* @var string[]
|
2015-01-13 19:31:45 +00:00
|
|
|
*/
|
2016-02-17 09:09:32 +00:00
|
|
|
protected $promote = [
|
2015-01-13 19:31:45 +00:00
|
|
|
'name',
|
2015-09-25 17:28:43 +00:00
|
|
|
'namemsg',
|
2015-01-13 19:31:45 +00:00
|
|
|
'version',
|
|
|
|
|
'author',
|
|
|
|
|
'url',
|
|
|
|
|
'description',
|
|
|
|
|
'descriptionmsg',
|
|
|
|
|
'license-name',
|
|
|
|
|
'type',
|
2016-02-17 09:09:32 +00:00
|
|
|
];
|
2015-01-13 19:31:45 +00:00
|
|
|
|
2024-04-21 14:43:04 +00:00
|
|
|
private array $json;
|
|
|
|
|
private string $dir;
|
|
|
|
|
private bool $hasWarning = false;
|
Implement extension registration from an extension.json file
Introduces wfLoadExtension()/wfLoadSkin() which should be used in
LocalSettings.php rather than require-ing a PHP entry point.
Extensions and skins would add "extension.json" or "skin.json" files
in their root, which contains all the information typically
present in PHP entry point files (classes to autoload, special pages,
API modules, etc.) A full schema can be found at
docs/extension.schema.json, and a script to validate these to the
schema is provided. An additional script is provided to convert
typical PHP entry point files into their JSON equivalents.
The basic flow of loading an extension goes like:
* Get the ExtensionRegistry singleton instance
* ExtensionRegistry takes a filename, reads the file or tries
to get the parsed JSON from APC if possible.
* The JSON is run through a Processor instance,
which registers things with the appropriate
global settings.
* The output of the processor is cached in APC if possible.
* The extension/skin is marked as loaded in the
ExtensionRegistry and a callback function is executed
if one was specified.
For ideal performance, a batch loading method is also provided:
* The absolute path name to the JSON file is queued
in the ExtensionRegistry instance.
* When loadFromQueue() is called, it constructs a hash
unique to the members of the current queue, and sees
if the queue has been cached in APC. If not, it processes
each file individually, and combines the result of each
Processor into one giant array, which is cached in APC.
* The giant array then sets various global settings,
defines constants, and calls callbacks.
To invalidate the cached processed info, by default the mtime
of each JSON file is checked. However that can be slow if you
have a large number of extensions, so you can set $wgExtensionInfoMTime
to the mtime of one file, and `touch` it whenever you update
your extensions.
Change-Id: I7074b65d07c5c7d4e3f1fb0755d74a0b07ed4596
2014-10-15 00:31:15 +00:00
|
|
|
|
|
|
|
|
public function __construct() {
|
|
|
|
|
parent::__construct();
|
2016-01-30 02:48:47 +00:00
|
|
|
$this->addDescription( 'Converts extension entry points to the new JSON registration format' );
|
2015-06-15 06:35:58 +00:00
|
|
|
$this->addArg( 'path', 'Location to the PHP entry point you wish to convert',
|
|
|
|
|
/* $required = */ true );
|
2015-01-29 20:24:49 +00:00
|
|
|
$this->addOption( 'skin', 'Whether to write to skin.json', false, false );
|
2016-05-25 16:42:41 +00:00
|
|
|
$this->addOption( 'config-prefix', 'Custom prefix for configuration settings', false, true );
|
Implement extension registration from an extension.json file
Introduces wfLoadExtension()/wfLoadSkin() which should be used in
LocalSettings.php rather than require-ing a PHP entry point.
Extensions and skins would add "extension.json" or "skin.json" files
in their root, which contains all the information typically
present in PHP entry point files (classes to autoload, special pages,
API modules, etc.) A full schema can be found at
docs/extension.schema.json, and a script to validate these to the
schema is provided. An additional script is provided to convert
typical PHP entry point files into their JSON equivalents.
The basic flow of loading an extension goes like:
* Get the ExtensionRegistry singleton instance
* ExtensionRegistry takes a filename, reads the file or tries
to get the parsed JSON from APC if possible.
* The JSON is run through a Processor instance,
which registers things with the appropriate
global settings.
* The output of the processor is cached in APC if possible.
* The extension/skin is marked as loaded in the
ExtensionRegistry and a callback function is executed
if one was specified.
For ideal performance, a batch loading method is also provided:
* The absolute path name to the JSON file is queued
in the ExtensionRegistry instance.
* When loadFromQueue() is called, it constructs a hash
unique to the members of the current queue, and sees
if the queue has been cached in APC. If not, it processes
each file individually, and combines the result of each
Processor into one giant array, which is cached in APC.
* The giant array then sets various global settings,
defines constants, and calls callbacks.
To invalidate the cached processed info, by default the mtime
of each JSON file is checked. However that can be slow if you
have a large number of extensions, so you can set $wgExtensionInfoMTime
to the mtime of one file, and `touch` it whenever you update
your extensions.
Change-Id: I7074b65d07c5c7d4e3f1fb0755d74a0b07ed4596
2014-10-15 00:31:15 +00:00
|
|
|
}
|
|
|
|
|
|
2015-01-11 04:17:36 +00:00
|
|
|
protected function getAllGlobals() {
|
2018-01-13 00:02:09 +00:00
|
|
|
$processor = new ReflectionClass( ExtensionProcessor::class );
|
2015-01-11 04:17:36 +00:00
|
|
|
$settings = $processor->getProperty( 'globalSettings' );
|
|
|
|
|
$settings->setAccessible( true );
|
2016-08-08 09:56:39 +00:00
|
|
|
return array_merge( $settings->getValue(), $this->formerGlobals );
|
2015-01-11 04:17:36 +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
|
|
|
public function execute() {
|
2015-01-11 04:17:36 +00:00
|
|
|
// Extensions will do stuff like $wgResourceModules += array(...) which is a
|
|
|
|
|
// fatal unless an array is already set. So set an empty value.
|
2015-05-12 16:26:24 +00:00
|
|
|
// And use the weird $__settings name to avoid any conflicts
|
|
|
|
|
// with real poorly named settings.
|
|
|
|
|
$__settings = array_merge( $this->getAllGlobals(), array_keys( $this->custom ) );
|
|
|
|
|
foreach ( $__settings as $var ) {
|
2015-01-11 04:17:36 +00:00
|
|
|
$var = 'wg' . $var;
|
2016-02-17 09:09:32 +00:00
|
|
|
$$var = [];
|
2015-01-11 04:17:36 +00:00
|
|
|
}
|
|
|
|
|
unset( $var );
|
2015-11-12 22:15:07 +00:00
|
|
|
$arg = $this->getArg( 0 );
|
|
|
|
|
if ( !is_file( $arg ) ) {
|
2017-11-20 00:36:54 +00:00
|
|
|
$this->fatalError( "$arg is not a file." );
|
2015-11-12 22:15:07 +00:00
|
|
|
}
|
|
|
|
|
require $arg;
|
|
|
|
|
unset( $arg );
|
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
|
|
|
// Try not to create any local variables before this line
|
|
|
|
|
$vars = get_defined_vars();
|
|
|
|
|
unset( $vars['this'] );
|
2015-05-12 16:26:24 +00:00
|
|
|
unset( $vars['__settings'] );
|
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->dir = dirname( realpath( $this->getArg( 0 ) ) );
|
2016-02-17 09:09:32 +00:00
|
|
|
$this->json = [];
|
2015-01-11 04:17:36 +00:00
|
|
|
$globalSettings = $this->getAllGlobals();
|
2016-05-25 16:42:41 +00:00
|
|
|
$configPrefix = $this->getOption( 'config-prefix', 'wg' );
|
|
|
|
|
if ( $configPrefix !== 'wg' ) {
|
|
|
|
|
$this->json['config']['_prefix'] = $configPrefix;
|
|
|
|
|
}
|
2019-06-21 08:15:41 +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
|
|
|
foreach ( $vars as $name => $value ) {
|
2015-05-12 16:26:24 +00:00
|
|
|
$realName = substr( $name, 2 ); // Strip 'wg'
|
2016-05-20 14:27:56 +00:00
|
|
|
if ( $realName === false ) {
|
|
|
|
|
continue;
|
|
|
|
|
}
|
2015-05-12 16:26:24 +00:00
|
|
|
|
|
|
|
|
// If it's an empty array that we likely set, skip it
|
|
|
|
|
if ( is_array( $value ) && count( $value ) === 0 && in_array( $realName, $__settings ) ) {
|
2015-01-11 04:17:36 +00:00
|
|
|
continue;
|
|
|
|
|
}
|
2015-05-12 16:26:24 +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( $this->custom[$realName] ) ) {
|
2016-02-17 09:09:32 +00:00
|
|
|
call_user_func_array( [ $this, $this->custom[$realName] ],
|
|
|
|
|
[ $realName, $value, $vars ] );
|
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
|
|
|
} elseif ( in_array( $realName, $globalSettings ) ) {
|
|
|
|
|
$this->json[$realName] = $value;
|
2015-05-16 11:45:24 +00:00
|
|
|
} elseif ( array_key_exists( $realName, $this->noLongerSupportedGlobals ) ) {
|
|
|
|
|
$this->output( 'Warning: Skipped global "' . $name . '" (' .
|
|
|
|
|
$this->noLongerSupportedGlobals[$realName] . '). ' .
|
|
|
|
|
"Please update the entry point before convert to registration.\n" );
|
|
|
|
|
$this->hasWarning = true;
|
2016-05-25 16:42:41 +00:00
|
|
|
} elseif ( strpos( $name, $configPrefix ) === 0 ) {
|
2019-06-21 08:15:41 +00:00
|
|
|
$configName = substr( $name, strlen( $configPrefix ) );
|
|
|
|
|
|
|
|
|
|
$isPath = false;
|
|
|
|
|
if ( is_array( $value ) ) {
|
|
|
|
|
foreach ( $value as $k => $v ) {
|
|
|
|
|
if ( strpos( $v, $this->dir ) !== false ) {
|
|
|
|
|
$value[$k] = $this->stripPath( $v, $this->dir );
|
|
|
|
|
$isPath = true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
} elseif ( is_string( $value ) && strpos( $value, $this->dir ) !== false ) {
|
|
|
|
|
$value = $this->stripPath( $value, $this->dir );
|
|
|
|
|
$isPath = true;
|
|
|
|
|
}
|
|
|
|
|
|
Implement extension registration from an extension.json file
Introduces wfLoadExtension()/wfLoadSkin() which should be used in
LocalSettings.php rather than require-ing a PHP entry point.
Extensions and skins would add "extension.json" or "skin.json" files
in their root, which contains all the information typically
present in PHP entry point files (classes to autoload, special pages,
API modules, etc.) A full schema can be found at
docs/extension.schema.json, and a script to validate these to the
schema is provided. An additional script is provided to convert
typical PHP entry point files into their JSON equivalents.
The basic flow of loading an extension goes like:
* Get the ExtensionRegistry singleton instance
* ExtensionRegistry takes a filename, reads the file or tries
to get the parsed JSON from APC if possible.
* The JSON is run through a Processor instance,
which registers things with the appropriate
global settings.
* The output of the processor is cached in APC if possible.
* The extension/skin is marked as loaded in the
ExtensionRegistry and a callback function is executed
if one was specified.
For ideal performance, a batch loading method is also provided:
* The absolute path name to the JSON file is queued
in the ExtensionRegistry instance.
* When loadFromQueue() is called, it constructs a hash
unique to the members of the current queue, and sees
if the queue has been cached in APC. If not, it processes
each file individually, and combines the result of each
Processor into one giant array, which is cached in APC.
* The giant array then sets various global settings,
defines constants, and calls callbacks.
To invalidate the cached processed info, by default the mtime
of each JSON file is checked. However that can be slow if you
have a large number of extensions, so you can set $wgExtensionInfoMTime
to the mtime of one file, and `touch` it whenever you update
your extensions.
Change-Id: I7074b65d07c5c7d4e3f1fb0755d74a0b07ed4596
2014-10-15 00:31:15 +00:00
|
|
|
// Most likely a config setting
|
2019-06-21 08:15:41 +00:00
|
|
|
$this->json['config'][$configName] = [ 'value' => $value ];
|
|
|
|
|
|
|
|
|
|
if ( $isPath ) {
|
|
|
|
|
$this->json['config'][$configName]['path'] = true;
|
|
|
|
|
}
|
2016-05-25 16:42:41 +00:00
|
|
|
} elseif ( $configPrefix !== 'wg' && strpos( $name, 'wg' ) === 0 ) {
|
|
|
|
|
// Warn about this
|
|
|
|
|
$this->output( 'Warning: Skipped global "' . $name . '" (' .
|
|
|
|
|
'config prefix is "' . $configPrefix . '"). ' .
|
|
|
|
|
"Please check that this setting isn't needed.\n" );
|
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-12-30 15:11:38 +00:00
|
|
|
// check, if the extension requires composer libraries
|
|
|
|
|
if ( $this->needsComposerAutoloader( dirname( $this->getArg( 0 ) ) ) ) {
|
|
|
|
|
// set the load composer autoloader automatically property
|
|
|
|
|
$this->output( "Detected composer dependencies, setting 'load_composer_autoloader' to true.\n" );
|
|
|
|
|
$this->json['load_composer_autoloader'] = true;
|
|
|
|
|
}
|
|
|
|
|
|
2015-01-13 19:31:45 +00:00
|
|
|
// Move some keys to the top
|
2016-02-17 09:09:32 +00:00
|
|
|
$out = [];
|
2015-01-13 19:31:45 +00:00
|
|
|
foreach ( $this->promote as $key ) {
|
|
|
|
|
if ( isset( $this->json[$key] ) ) {
|
|
|
|
|
$out[$key] = $this->json[$key];
|
|
|
|
|
unset( $this->json[$key] );
|
|
|
|
|
}
|
|
|
|
|
}
|
2018-02-02 22:19:43 +00:00
|
|
|
// Set a requirement on the MediaWiki version that the current MANIFEST_VERSION
|
|
|
|
|
// was introduced in.
|
|
|
|
|
$out['requires'] = [
|
|
|
|
|
ExtensionRegistry::MEDIAWIKI_CORE => ExtensionRegistry::MANIFEST_VERSION_MW_VERSION
|
|
|
|
|
];
|
2015-01-13 19:31:45 +00:00
|
|
|
$out += $this->json;
|
2015-05-20 01:45:10 +00:00
|
|
|
// Put this at the bottom
|
|
|
|
|
$out['manifest_version'] = ExtensionRegistry::MANIFEST_VERSION;
|
2015-01-29 20:24:49 +00:00
|
|
|
$type = $this->hasOption( 'skin' ) ? 'skin' : 'extension';
|
|
|
|
|
$fname = "{$this->dir}/$type.json";
|
2015-01-13 19:31:45 +00:00
|
|
|
$prettyJSON = FormatJson::encode( $out, "\t", FormatJson::ALL_OK );
|
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
|
|
|
file_put_contents( $fname, $prettyJSON . "\n" );
|
|
|
|
|
$this->output( "Wrote output to $fname.\n" );
|
2015-05-16 11:45:24 +00:00
|
|
|
if ( $this->hasWarning ) {
|
|
|
|
|
$this->output( "Found warnings! Please resolve the warnings and rerun this script.\n" );
|
|
|
|
|
}
|
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 handleExtensionFunctions( $realName, $value ) {
|
|
|
|
|
foreach ( $value as $func ) {
|
|
|
|
|
if ( $func instanceof Closure ) {
|
2017-11-20 00:36:54 +00:00
|
|
|
$this->fatalError( "Error: Closures cannot be converted to JSON. " .
|
|
|
|
|
"Please move your extension function somewhere else."
|
2015-06-15 06:35:58 +00:00
|
|
|
);
|
2019-08-30 13:09:51 +00:00
|
|
|
} elseif ( function_exists( $func ) ) {
|
|
|
|
|
// check if $func exists in the global scope
|
2017-11-20 00:36:54 +00:00
|
|
|
$this->fatalError( "Error: Global functions cannot be converted to JSON. " .
|
|
|
|
|
"Please move your extension function ($func) into a class."
|
2016-01-09 19:27:54 +00:00
|
|
|
);
|
|
|
|
|
}
|
Implement extension registration from an extension.json file
Introduces wfLoadExtension()/wfLoadSkin() which should be used in
LocalSettings.php rather than require-ing a PHP entry point.
Extensions and skins would add "extension.json" or "skin.json" files
in their root, which contains all the information typically
present in PHP entry point files (classes to autoload, special pages,
API modules, etc.) A full schema can be found at
docs/extension.schema.json, and a script to validate these to the
schema is provided. An additional script is provided to convert
typical PHP entry point files into their JSON equivalents.
The basic flow of loading an extension goes like:
* Get the ExtensionRegistry singleton instance
* ExtensionRegistry takes a filename, reads the file or tries
to get the parsed JSON from APC if possible.
* The JSON is run through a Processor instance,
which registers things with the appropriate
global settings.
* The output of the processor is cached in APC if possible.
* The extension/skin is marked as loaded in the
ExtensionRegistry and a callback function is executed
if one was specified.
For ideal performance, a batch loading method is also provided:
* The absolute path name to the JSON file is queued
in the ExtensionRegistry instance.
* When loadFromQueue() is called, it constructs a hash
unique to the members of the current queue, and sees
if the queue has been cached in APC. If not, it processes
each file individually, and combines the result of each
Processor into one giant array, which is cached in APC.
* The giant array then sets various global settings,
defines constants, and calls callbacks.
To invalidate the cached processed info, by default the mtime
of each JSON file is checked. However that can be slow if you
have a large number of extensions, so you can set $wgExtensionInfoMTime
to the mtime of one file, and `touch` it whenever you update
your extensions.
Change-Id: I7074b65d07c5c7d4e3f1fb0755d74a0b07ed4596
2014-10-15 00:31:15 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
$this->json[$realName] = $value;
|
|
|
|
|
}
|
|
|
|
|
|
2015-01-11 04:17:36 +00:00
|
|
|
protected function handleMessagesDirs( $realName, $value ) {
|
|
|
|
|
foreach ( $value as $key => $dirs ) {
|
|
|
|
|
foreach ( (array)$dirs as $dir ) {
|
|
|
|
|
$this->json[$realName][$key][] = $this->stripPath( $dir, $this->dir );
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2015-05-01 03:32:44 +00:00
|
|
|
protected function handleExtensionMessagesFiles( $realName, $value, $vars ) {
|
|
|
|
|
foreach ( $value as $key => $file ) {
|
|
|
|
|
$strippedFile = $this->stripPath( $file, $this->dir );
|
|
|
|
|
if ( isset( $vars['wgMessagesDirs'][$key] ) ) {
|
|
|
|
|
$this->output(
|
|
|
|
|
"Note: Ignoring PHP shim $strippedFile. " .
|
|
|
|
|
"If your extension no longer supports versions of MediaWiki " .
|
|
|
|
|
"older than 1.23.0, you can safely delete it.\n"
|
|
|
|
|
);
|
|
|
|
|
} else {
|
|
|
|
|
$this->json[$realName][$key] = $strippedFile;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
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
|
|
|
private function stripPath( $val, $dir ) {
|
2015-01-11 04:17:36 +00:00
|
|
|
if ( $val === $dir ) {
|
|
|
|
|
$val = '';
|
|
|
|
|
} elseif ( strpos( $val, $dir ) === 0 ) {
|
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
|
|
|
// +1 is for the trailing / that won't be in $this->dir
|
|
|
|
|
$val = substr( $val, strlen( $dir ) + 1 );
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
return $val;
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
protected function removeAbsolutePath( $realName, $value ) {
|
2016-02-17 09:09:32 +00:00
|
|
|
$out = [];
|
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 ( $value as $key => $val ) {
|
|
|
|
|
$out[$key] = $this->stripPath( $val, $this->dir );
|
|
|
|
|
}
|
|
|
|
|
$this->json[$realName] = $out;
|
|
|
|
|
}
|
|
|
|
|
|
2018-04-13 18:44:59 +00:00
|
|
|
protected function removeAutodiscoveredParserTestFiles( $realName, $value ) {
|
|
|
|
|
$out = [];
|
|
|
|
|
foreach ( $value as $key => $val ) {
|
|
|
|
|
$path = $this->stripPath( $val, $this->dir );
|
|
|
|
|
// When path starts with tests/parser/ the file would be autodiscovered with
|
|
|
|
|
// extension registry, so no need to add it to extension.json
|
2023-05-20 12:16:32 +00:00
|
|
|
if ( !str_starts_with( $path, 'tests/parser/' ) || !str_ends_with( $path, '.txt' ) ) {
|
2018-04-13 18:44:59 +00:00
|
|
|
$out[$key] = $path;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
// in the best case all entries are filtered out
|
|
|
|
|
if ( $out ) {
|
|
|
|
|
$this->json[$realName] = $out;
|
|
|
|
|
}
|
2022-10-12 21:02:51 +00:00
|
|
|
// FIXME: the ParserTestFiles key was deprecated in
|
|
|
|
|
// MW 1.30 and removed in MW 1.40. If not all entries were filtered
|
|
|
|
|
// out by the above, we *should* recommend the user move the
|
|
|
|
|
// parser tests under `tests/parser` *not* generate an extension.json
|
|
|
|
|
// with a ParserTestFiles key that will no longer validate.
|
2018-04-13 18:44:59 +00:00
|
|
|
}
|
|
|
|
|
|
2015-06-16 19:06:19 +00:00
|
|
|
protected function handleCredits( $realName, $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
|
|
|
$keys = array_keys( $value );
|
|
|
|
|
$this->json['type'] = $keys[0];
|
|
|
|
|
$values = array_values( $value );
|
|
|
|
|
foreach ( $values[0][0] as $name => $val ) {
|
|
|
|
|
if ( $name !== 'path' ) {
|
|
|
|
|
$this->json[$name] = $val;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
public function handleHooks( $realName, $value ) {
|
2016-04-29 21:21:40 +00:00
|
|
|
foreach ( $value as $hookName => &$handlers ) {
|
2016-08-07 09:27:09 +00:00
|
|
|
if ( $hookName === 'UnitTestsList' ) {
|
|
|
|
|
$this->output( "Note: the UnitTestsList hook is no longer necessary as " .
|
|
|
|
|
"long as your tests are located in the \"tests/phpunit/\" directory. " .
|
|
|
|
|
"Please see <https://www.mediawiki.org/wiki/Manual:PHP_unit_testing/" .
|
|
|
|
|
"Writing_unit_tests_for_extensions#Register_your_tests> for more details.\n"
|
|
|
|
|
);
|
|
|
|
|
}
|
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 ( $handlers as $func ) {
|
|
|
|
|
if ( $func instanceof Closure ) {
|
2017-11-20 00:36:54 +00:00
|
|
|
$this->fatalError( "Error: Closures cannot be converted to JSON. " .
|
|
|
|
|
"Please move the handler for $hookName somewhere else."
|
2015-06-15 06:35:58 +00:00
|
|
|
);
|
2019-08-30 13:09:51 +00:00
|
|
|
} elseif ( function_exists( $func ) ) {
|
|
|
|
|
// Check if $func exists in the global scope
|
2017-11-20 00:36:54 +00:00
|
|
|
$this->fatalError( "Error: Global functions cannot be converted to JSON. " .
|
|
|
|
|
"Please move the handler for $hookName inside a class."
|
2016-01-09 19:27:54 +00:00
|
|
|
);
|
|
|
|
|
}
|
Implement extension registration from an extension.json file
Introduces wfLoadExtension()/wfLoadSkin() which should be used in
LocalSettings.php rather than require-ing a PHP entry point.
Extensions and skins would add "extension.json" or "skin.json" files
in their root, which contains all the information typically
present in PHP entry point files (classes to autoload, special pages,
API modules, etc.) A full schema can be found at
docs/extension.schema.json, and a script to validate these to the
schema is provided. An additional script is provided to convert
typical PHP entry point files into their JSON equivalents.
The basic flow of loading an extension goes like:
* Get the ExtensionRegistry singleton instance
* ExtensionRegistry takes a filename, reads the file or tries
to get the parsed JSON from APC if possible.
* The JSON is run through a Processor instance,
which registers things with the appropriate
global settings.
* The output of the processor is cached in APC if possible.
* The extension/skin is marked as loaded in the
ExtensionRegistry and a callback function is executed
if one was specified.
For ideal performance, a batch loading method is also provided:
* The absolute path name to the JSON file is queued
in the ExtensionRegistry instance.
* When loadFromQueue() is called, it constructs a hash
unique to the members of the current queue, and sees
if the queue has been cached in APC. If not, it processes
each file individually, and combines the result of each
Processor into one giant array, which is cached in APC.
* The giant array then sets various global settings,
defines constants, and calls callbacks.
To invalidate the cached processed info, by default the mtime
of each JSON file is checked. However that can be slow if you
have a large number of extensions, so you can set $wgExtensionInfoMTime
to the mtime of one file, and `touch` it whenever you update
your extensions.
Change-Id: I7074b65d07c5c7d4e3f1fb0755d74a0b07ed4596
2014-10-15 00:31:15 +00:00
|
|
|
}
|
2016-04-29 21:21:40 +00:00
|
|
|
if ( count( $handlers ) === 1 ) {
|
|
|
|
|
$handlers = $handlers[0];
|
|
|
|
|
}
|
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->json[$realName] = $value;
|
|
|
|
|
}
|
|
|
|
|
|
2019-08-30 18:17:32 +00:00
|
|
|
/**
|
|
|
|
|
* @param string $realName
|
|
|
|
|
* @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
|
|
|
protected function handleResourceModules( $realName, $value ) {
|
2016-02-17 09:09:32 +00:00
|
|
|
$defaults = [];
|
2015-02-06 09:46:05 +00:00
|
|
|
$remote = $this->hasOption( 'skin' ) ? 'remoteSkinPath' : 'remoteExtPath';
|
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 ( $value as $name => $data ) {
|
|
|
|
|
if ( isset( $data['localBasePath'] ) ) {
|
|
|
|
|
$data['localBasePath'] = $this->stripPath( $data['localBasePath'], $this->dir );
|
2015-02-06 09:46:05 +00:00
|
|
|
if ( !$defaults ) {
|
|
|
|
|
$defaults['localBasePath'] = $data['localBasePath'];
|
|
|
|
|
unset( $data['localBasePath'] );
|
|
|
|
|
if ( isset( $data[$remote] ) ) {
|
|
|
|
|
$defaults[$remote] = $data[$remote];
|
|
|
|
|
unset( $data[$remote] );
|
|
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
if ( $data['localBasePath'] === $defaults['localBasePath'] ) {
|
|
|
|
|
unset( $data['localBasePath'] );
|
|
|
|
|
}
|
|
|
|
|
if ( isset( $data[$remote] ) && isset( $defaults[$remote] )
|
|
|
|
|
&& $data[$remote] === $defaults[$remote]
|
|
|
|
|
) {
|
|
|
|
|
unset( $data[$remote] );
|
|
|
|
|
}
|
|
|
|
|
}
|
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 09:46:05 +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
|
|
|
$this->json[$realName][$name] = $data;
|
|
|
|
|
}
|
2015-02-06 09:46:05 +00:00
|
|
|
if ( $defaults ) {
|
|
|
|
|
$this->json['ResourceFileModulePaths'] = $defaults;
|
|
|
|
|
}
|
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-12-30 15:11:38 +00:00
|
|
|
|
|
|
|
|
protected function needsComposerAutoloader( $path ) {
|
|
|
|
|
$path .= '/composer.json';
|
|
|
|
|
if ( file_exists( $path ) ) {
|
2024-01-13 18:41:24 +00:00
|
|
|
// assume that the composer.json file is in the root of the extension path
|
2015-12-30 15:11:38 +00:00
|
|
|
$composerJson = new ComposerJson( $path );
|
2024-01-13 18:41:24 +00:00
|
|
|
// check if there are some dependencies in the require section
|
2015-12-30 15:11:38 +00:00
|
|
|
if ( $composerJson->getRequiredDependencies() ) {
|
|
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
return false;
|
|
|
|
|
}
|
Implement extension registration from an extension.json file
Introduces wfLoadExtension()/wfLoadSkin() which should be used in
LocalSettings.php rather than require-ing a PHP entry point.
Extensions and skins would add "extension.json" or "skin.json" files
in their root, which contains all the information typically
present in PHP entry point files (classes to autoload, special pages,
API modules, etc.) A full schema can be found at
docs/extension.schema.json, and a script to validate these to the
schema is provided. An additional script is provided to convert
typical PHP entry point files into their JSON equivalents.
The basic flow of loading an extension goes like:
* Get the ExtensionRegistry singleton instance
* ExtensionRegistry takes a filename, reads the file or tries
to get the parsed JSON from APC if possible.
* The JSON is run through a Processor instance,
which registers things with the appropriate
global settings.
* The output of the processor is cached in APC if possible.
* The extension/skin is marked as loaded in the
ExtensionRegistry and a callback function is executed
if one was specified.
For ideal performance, a batch loading method is also provided:
* The absolute path name to the JSON file is queued
in the ExtensionRegistry instance.
* When loadFromQueue() is called, it constructs a hash
unique to the members of the current queue, and sees
if the queue has been cached in APC. If not, it processes
each file individually, and combines the result of each
Processor into one giant array, which is cached in APC.
* The giant array then sets various global settings,
defines constants, and calls callbacks.
To invalidate the cached processed info, by default the mtime
of each JSON file is checked. However that can be slow if you
have a large number of extensions, so you can set $wgExtensionInfoMTime
to the mtime of one file, and `touch` it whenever you update
your extensions.
Change-Id: I7074b65d07c5c7d4e3f1fb0755d74a0b07ed4596
2014-10-15 00:31:15 +00:00
|
|
|
}
|
|
|
|
|
|
2018-01-13 00:02:09 +00:00
|
|
|
$maintClass = ConvertExtensionToRegistration::class;
|
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
|
|
|
require_once RUN_MAINTENANCE_IF_MAIN;
|