Manual:Configuration for developers


 * For documentation about configuring MediaWiki, see Manual:Configuration.

This is a guide for core and extension developers about creating and accessing configuration settings.

For core
To access a configuration variable such as :

If you don't have access to any ContextSources, you can get a Config object with

This should not be used to fetch global variable objects such as or.

Configuration using (recommended)
Extensions that have an  file should set up configuration variables as described in this section.

If your extension is called, in   you'd write:

In PHP, whenever you want your configuration values:

If the prefix for your configuration keys is not the full extension name (e.g. is an abbreviation) you can specify it with the  or   key, depending on the schema version (see docs). You should make sure it doesn't collide with any existing extension. Generally this is a bad idea though, and will probably break the use of attributes.

Configuration using globals
If you can, use the  file for configuration (see above). If you can't, use this snippet (only works with  prefixed variables):

Custom prefixes
In the past, some extensions used "eg" instead of "wg". We want to move away from prefixes, but you can still continue to use them:

If you use extension registration, there is a  or   (depending on the schema version) field you can use instead.

Testing
When debugging, you use the following to test that you are accessing the right Config instance. You should do this in place of the $wgConfigRegistry shown in the for extensions section above.

If you are accessing the wrong Config instance, a will be produced.

For modifying configuration variables in PhpUnit tests in extensions using manifest version 1 (or in MediaWiki core), you can do the following in test cases that extend :

Upgrading from before MediaWiki 1.23
Starting with MediaWiki 1.23, there a new  interface was introduced to access configuration options. This allowed us to abstract the backend in which we stored configuration options.

Pre-1.23 code would look like:

1.23+ code should look like this:

You'll notice a few changes here:
 * We use  to get the default   object. Most contexts implement.
 * Rather than checking for "wgFoo", you ask the Config object for "Foo", without any wg prefix.

For core
To access a configuration variable such as :

If you don't have access to any ContextSources, you can get a Config object with

This should not be used to fetch global variable objects such as or.

Configuration using (recommended)
Extensions that have an  file should set up configuration variables as described in this section.

If your extension is called, in   you'd write:

In PHP, whenever you want your configuration values:

If the prefix for your configuration keys is not the full extension name (e.g. is an abbreviation) you can specify it with the  or   key, depending on the schema version (see docs). You should make sure it doesn't collide with any existing extension. Generally this is a bad idea though, and will probably break the use of attributes.

Configuration using globals
If you can, use the  file for configuration (see above). If you can't, use this snippet (only works with  prefixed variables):

Custom prefixes
In the past, some extensions used "eg" instead of "wg". We want to move away from prefixes, but you can still continue to use them:

If you use extension registration, there is a  or   (depending on the schema version) field you can use instead.

Testing
When debugging, you use the following to test that you are accessing the right Config instance. You should do this in place of the $wgConfigRegistry shown in the for extensions section above.

If you are accessing the wrong Config instance, a will be produced.

For modifying configuration variables in PhpUnit tests in extensions using manifest version 1 (or in MediaWiki core), you can do the following in test cases that extend :

Upgrading from before MediaWiki 1.23
Starting with MediaWiki 1.23, there a new  interface was introduced to access configuration options. This allowed us to abstract the backend in which we stored configuration options.

Pre-1.23 code would look like:

1.23+ code should look like this:

You'll notice a few changes here:
 * We use  to get the default   object. Most contexts implement.
 * Rather than checking for "wgFoo", you ask the Config object for "Foo", without any wg prefix.