If an extension specifies a require section in its composer.json, which contains
some dependencies, we can assume that this extension needs to load the composer
autoloader.
The maintenance script convertExtensionToRegistration.php will now check if the
extension has such a composer.json and, if so, adds the load_composer_autoloader
property in extension.json, which will try to load the autoloader of composer
is it is present.
Also add a check for existence of a require section in ComposerJson library
(ComposerJson::getRequiredDependencies()).
Bug: T119766
Change-Id: Icdbc37abc44e642afee2aab4c0e9298d3471124d
Currently when converting from PHP to extension.json, 'namemsg' isn't
underneath 'name', it is halfway down instead.
Change-Id: I1be42a818bda6908643702cc5f7c959d2d2fdfba
Functions must not contain multiple empty lines in a row
(Squiz.WhiteSpace.SuperfluousWhitespace sniff).
Bug: T102774
Change-Id: Ib706e4fc34b95c0d7c887e54af0ea61227767d8f
Versioning the extension.json schema will allow us to make breaking changes
to the schema in a non-breaking manner.
Extensiosn and skins will set a 'manifest_version' value, stating which
version of the schema the file is written for. Processor::extractInfo() will
be passed the version number, and can switch behavior depending upon it.
For backwards-compatability, a version number of 1 is assumed if none is set.
The validateRegistrationFile.php script will emit a warning if this is the
case.
Bug: T99344
Change-Id: I2086a1465ceaeedd1ccc6804fda2c304ad16ffa0
Remember which settings we set to an empty array and then only skip
those settings.
The weird variable name "$__settings" is used to avoid any conflicts
similar to what eval.php does.
Bug: T98739
Change-Id: Iefbf8a98fd433cfbe0087aca6821d90c2786b0cb
$wgSpecialPageGroups is deprecated since 1.21
The code should be migrated to override SpecialPage::getGroupName before
adding an extension.json to the extension, instead of allowing setting
this over extension.json
Also added a warning to convertExtensionToRegistration.php for the no
longer supported global
Change-Id: Idccbe41b649de93548c5b0fca03145da716bcc65
Structurally, it's set up exactly the same as ResourceModules, so we can
re-use the same code.
Bug: T91566
Change-Id: I7cd1330edc3e97b4658c81aac67071a90ac61fb6
This allows for extensions to specify common arguments to ResourceLoader
module definitions by only specifying them once.
The only supported values are "localBasePath" (which is relative to the
current directory), "remoteSkinPath", and "remoteExtPath". If a module
is using a custom class or is already specifying paths, the default paths
will not be added.
Tests are included to cover existing functionality and newly added
functionality. The convertExtensionToRegistration.php script was also
extended to try and guess what the default paths should be.
Bug: T88786
Change-Id: I802461796e8d8584dacf3b0c811b5ba97a4a8f7f
It's an attribute now rather than a global, but we still want
to convert it.
This follows up 247ecab445.
Change-Id: Ibb61b1689e3e6b454d7bf2f300ab465e30ca774a
* Handle constructs like $wgResourceModules += array(...)
* Support $wgMessagesDirs['FooBar'] = array(...)
* Handle stripping paths where it is the current directory
* Use FormatJson::ALL_OK when writing the file
Bug: T86311
Change-Id: I9434f6634fd6e460a5c2f6dac95c9065da35a51a
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
