With extension registration, it is now possible to gather the config variables of each extension/skin, separately. So we can make a HashConfig for the defaults of each extension and merge in the user defined settings. Furthermore, we can also make a HashConfig of core default settings then merge in the user defined settings. This means we can deprecate GlobalVarConfig and get rid of most globals. Globals would still be defined in local settings but unset after merging.
RequestContext::getConfig() can then also be deprecated, especially as it doesn't depend on the request as noted in the file. We should instead provide some common objects like APIBase with a config accessor (itself implemented via a MW service). Some modules like RessourceLoader may even want to make their own config independently of the main config.
Description
Description
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | None | T11968 Reduce use of global and public variables | |||
| Open | None | T156646 Make a config object for each extension/skin, deprecate GlobalVarConfig and RequestContext::getConfig() | |||
| Declined | Cenarium | T156877 Create a config object for each extension/skin during registration |
Event Timeline
Comment Actions
The before-comma clause looks like T71084: Convert things to use Config classes instead of globals and its subtasks?
Comment Actions
Well, I feel like we have huge documentation issues regarding current state of the art in config settings, especially for extensions, so I'm not sure. However, I think this task has a bit of a different scope, especially considering this:
We should instead provide some common objects like APIBase with a config accessor (itself implemented via a MW service). Some modules like RessourceLoader may even want to make their own config independently of the main config.
Furthermore, as I see it, this task is more about how xonfig should work for extensions in general, if I take a look on the patch provided for T156877.