It'd be really useful if there was a way to have a variable completely override an array. ie we set defaults in the extension config, but in LocalSettings (or CommonSettings et al) we can wipe that out, not use it, and use whatever we've defined there
|mediawiki/core : master||ExtensionRegistry: Add 'override' merge strategy|
- Mentioned In
- T229644: RelatedArticles showing on all German and Russian Wikipedia due to incorrect configuration settings
T121378: Impossible to override an array-valued global created by extension registration
T151891: Clean up inappropriate usages of wmg prefix in Reading-web maintained extensions
T163114: Regression: Fix config to disable related pages where it's not wanted
- Mentioned Here
- T211063: It should be possible to turn lead paragraph on in other namespaces
T62419: Types of throttles are hardcoded in SpecialOverrideThrottle::getFormFields
T156877: Create a config object for each extension/skin during registration
Not only useful, but essential. The current behaviour is highly misleading.
If extension.json defines:
wgMoo = ['a']
and in LocalSettings in production I put
wgMoo = ;
wgMoo should not be ['a'].
You can use $wgFoo = [ 'foobar' => true ]. If someone wants to remove it, they can set it to false.
I thought I had left a comment on this ticket earlier, in general I don't like encouraging full overrides. Defaults should be sane, and full overrides end up require needing more maintenance later on. If the defaults aren't sane, that's a different problem. Flat arrays have always been problematic since you need to write some amount of code to be able to remove a single item from them, and we are trying to move away from code in configuration.
Okay, I see the rationale for not introducing new flat arrays. I'll just use boolean ones for the task that drove me here then.
But still, we currently need workarounds like this one in the configuration. I'm not convinced that's a good way either.
I understand your comment as a suggestion of declining this task and abandoning the patch (correct me if that's wrong). What's the alternative for dealing with existing flat arrays then? If it is the removal all flat array config variables from all major extensions, is it realistic that all will be refactored in the foreseeable future? If we can't do that, there should probably be a way of dealing with flat arrays - without applying workarounds.
Ideally extensions would have migrated during the conversion like what VisualEditor did. Usually we introduce a new config variable that uses key/value, deprecate the old one and map the old one to the new config, and then after a while, deprecate and remove the old config variable.
Is there some function that effectively maps boolean config variables to flat arrays internally in core? So one could have a config variable $wgVar = [ 'foo' => true, 'bar' => false, 'foobar' => true, 'baz' => 'false' ] and then call Something::getBooleanConfigAsFlatArray( 'wgVar' ) which would return [ 'foo', 'foobar' ]? I'm primarily interested in a way to simply iterate over a config variable (which works fine with flat arrays, but not with boolean ones, at least I'm not aware of a really short way) and wrote such a function for https://gerrit.wikimedia.org/r/#/c/380061/. Maybe it'd be worth to have such a helper function in core. That way one could use the boolean config variables and overwrite them in whatever way seems best, but still get config variables as flat arrays when it's necessary/easier at runtime.