Requests for comment/Configuration database 2

Storage
Settings are stored in a "LocalSettings.json" file. It uses a simple key storage method.

This will be cached in $wgMemc for performance.

In the future, this could use a DataStore backend.

You might ask, why not use ContentHandler? There are security issues with storing private information in page text, and it would be difficult to access another wiki's settings.

Metadata
DefaultSettings.php will become a huge array of metadata, similar to how the Configure extension works.

An example might look like:

A hook will be available to extensions to add their own configuration options.

Limitations
Not all settings can be set using the database. $wgDBname and $wgDBpass are probably two of the best examples.

A new global will be introduced to limit what will show up on the special page:

These values are not shown on the special page at all.

Loading order

 * First the default is loaded from DefaultSettings.php
 * That is overridden with whatever is in LocalSettings.php
 * Then the configuration database is loaded, and overwrites values. (Unless it is in $wgHiddenConfigOptions).
 * Something similar to SiteConfiguration::extractAllGlobals will be called so any existing code using globals will not have to be changed.

Special page

 * New special page at Special:ConfigureSettings. It will look similar to Special:Preferences, and uses HTMLForm.
 * The page is based on categories, so if you want to edit something in the "site" category, you would go to Special:ConfigureSettings/site. For SpamBlacklist, it would be Special:ConfigureSettings/SpamBlacklist.
 * The main Special:ConfigureSettings is just a landing page with a listing of various categories.
 * If users cannot edit certain fields because they do not have the proper rights, they can still view the current value (unless it's set to private).

User rights

 * There is one super powerful right named 'configure' which lets you configure everything (except for $wgHiddenConfigOptions)
 * Each category by default checks for 'configure-$name', unless there is a 'right' key set. If a variable in this category uses a more specific right, it is not automatically inherited.
 * Each right checks for 'configure-$wgName', unless there is a 'right' key set.

Logging

 * This will use the standard MediaWiki logging mechanism.
 * Entries will look like "Tim changed $wgMagicEnabled from false to true (happiness for everyone!)".
 * If a variable is set to private, the log entry will only say: "Tim changed $wgMagicEnabled".