Hi everyone,
I've written an RfC about changing the way extensions store metadata about themselves and also how we load them. It's at https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration.
A brief summary:
Extensions register a lot of things, like classes, hooks, special pages, configuration options, and plenty more. Currently all of these are usually stored in the extension's main entry point ($IP/extensions/Foo/Foo.php).
This creates two problems. First, it's difficult to tell what an extension is going to register without actually enabling the extension. Second, registration currently depends on global state ($wgHooks, $wgSpecialPages, etc.) which we are trying to move away from.
My proposal is that we store this information in a JSON file (I've provided an example on the RfC), and have MediaWiki read them when loading extensions. We would no longer use the current method of require_once "Foo.php";, but instead $wgEnableExtensions[] = 'foo';, and MediaWiki would take care of the rest.
Please leave any comments or thoughts you might have on the talk page.
Thanks, -- Legoktm
A few more updates about the RfC after the IRC meeting. In case you missed it, the logs are at [1].
== Extension locations == We agreed that we should require extensions to all be in the same directory, but that directory should be configurable. By default it will point to $IP/extensions.
== Setting default configuration values == In my initial proposal I had something like: $wgEnabledExtensions[] = 'Math'; $wgMathSomeOption = 'bar'; $wgEnabledExtensions[] = 'SpamBlacklist'; My plan was when loading the extension.json file, MediaWiki would check if the config values are set, and if so, don't overwrite it with the defaults. However since we're using $GLOBALS as the configuration backend, this opens up a register_globals vulnerability.
What do people think of stopping caring about register_globals (while we still support 5.3) and being ok with isset($wgWhatever)? Chad was of the opinion that it's your own fault if you turn on register_globals. :P
A few other options were discussed in the meeting: wfEnableExtension( 'Math' ); $wgMathSomeOption = 'bar'; Where the function sets the default globals, and then the user overwrites them. This won't work for when we want to store configuration in the database since extensions to be loaded are no longer in an array.
Another one was something like: $wgEnabledExtensions += array( 'Math', 'SpamBlacklist' ); wfLoadExtensions(); // Loads all extensions and sets defaults // All config values after function call $wgMathSomeOption = 'bar'; I'm not a huge fan of this one since IMO MediaWiki should do the extension loading on its own, and not require the user to put a function call in their configuration.
== Schema == I've written a basic JSON schema for extension.json files and put it up at [2].
[1] https://www.mediawiki.org/wiki/Architecture_meetings/RFC_review_2014-05-30 [2] https://www.mediawiki.org/wiki/Requests_for_comment/Extension_registration/S...
-- Legoktm
On Wed, Jun 4, 2014 at 10:29 AM, Legoktm legoktm.wikipedia@gmail.com wrote:
== Extension locations == We agreed that we should require extensions to all be in the same directory, but that directory should be configurable. By default it will point to $IP/extensions.
How about a library that registers resources in ResourceLoader (we have that a lot for Wikidata.org)? Currently they would be installed to $IP/vendor. Should they all be regarded as a MediaWiki extension just because they (also) support ResourceLoader?
[…] IMO MediaWiki should do the extension loading on its own, and not require the user to put a function call in their configuration.
I'm not too sure about that one. I think having the code for something installed without actually running it has its use cases. For example, you find an issue with an extension but have no time to investigate it right now. Having all extensions automatically loaded if they are present would force you to uninstall the extension to disable it.
On 6/4/14, 1:42 AM, Adrian Lang wrote:
[…] IMO MediaWiki should do the extension loading on its own, and not require the user to put a function call in their configuration.
I'm not too sure about that one. I think having the code for something installed without actually running it has its use cases. For example, you find an issue with an extension but have no time to investigate it right now. Having all extensions automatically loaded if they are present would force you to uninstall the extension to disable it.
Sorry, I should have been more clear about this. I didn't mean autoloading in the sense of if the extension is present, MediaWiki will automatically enable it. What I meant was, that if your configuration has: $wgEnabledExtensions[] = 'Math';
You shouldn't *also* have to write: wfLoadExtensions();
Just the first alone should be necessary.
-- Legoktm
On 2014-06-04, 1:29 AM, Legoktm wrote:
A few more updates about the RfC after the IRC meeting. In case you missed it, the logs are at [1].
== Extension locations == We agreed that we should require extensions to all be in the same directory, but that directory should be configurable. By default it will point to $IP/extensions.
I still do NOT like this idea.
By all means there should be one directory for extensions that are managed by a web/cli installer and the method of loading extensions from that one directory should be simple even when we're still using a php settings file. But when someone is intentionally not using that and doing complex config then we shouldn't stop them from saying to load an extension from a specific directory.
A few other options were discussed in the meeting: wfEnableExtension( 'Math' ); $wgMathSomeOption = 'bar'; Where the function sets the default globals, and then the user overwrites them. This won't work for when we want to store configuration in the database since extensions to be loaded are no longer in an array.
I don't understand where you get this assertion, this should have no effect on whether we can or can't have config in the DB.
A wfEnableExtension would do the exact same thing as $wgEnabledExtensions would do to load an extension, just earlier.
~Daniel Friesen (Dantman, Nadir-Seen-Fire) [http://danielfriesen.name/]
Sorry about the super super late reply.
On 6/4/14, 2:12 AM, Daniel Friesen wrote:
On 2014-06-04, 1:29 AM, Legoktm wrote:
A few more updates about the RfC after the IRC meeting. In case you missed it, the logs are at [1].
== Extension locations == We agreed that we should require extensions to all be in the same directory, but that directory should be configurable. By default it will point to $IP/extensions.
I still do NOT like this idea.
By all means there should be one directory for extensions that are managed by a web/cli installer and the method of loading extensions from that one directory should be simple even when we're still using a php settings file. But when someone is intentionally not using that and doing complex config then we shouldn't stop them from saying to load an extension from a specific directory.
Ok, I think that's reasonable.
A few other options were discussed in the meeting: wfEnableExtension( 'Math' ); $wgMathSomeOption = 'bar'; Where the function sets the default globals, and then the user overwrites them. This won't work for when we want to store configuration in the database since extensions to be loaded are no longer in an array.
I don't understand where you get this assertion, this should have no effect on whether we can or can't have config in the DB.
A wfEnableExtension would do the exact same thing as $wgEnabledExtensions would do to load an extension, just earlier.
Now looking back, I'm not sure where I came up with that either. What you said makes sense.
I'll work on updating the RfC with this and a few other things today.
-- Legoktm
wikitech-l@lists.wikimedia.org