aboutsummaryrefslogtreecommitdiffstats
path: root/includes/Settings/Config/ArrayConfigBuilder.php
Commit message (Collapse)AuthorAgeFilesLines
* Namespace Config-related classes under \MediaWiki\ConfigJames D. Forrester2023-09-211-1/+1
| | | | | Bug: T166010 Change-Id: I4066885a7ea071d22497abcdb3f95e73e154d08c
* Address contravariance todosTim Starling2022-11-161-3/+1
| | | | | Bug: T278139 Change-Id: If451415b8acbc764b8f2b277dc8635dcfc88ff53
* Move dynamic defaults into MainConfigSchemaAryeh Gregor2022-07-071-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | The goal is to keep the actual default values for settings in the same place as the setting is declared, and applied using the regular means for loading the settings -- not in a separate piece of code that needs to be loaded through some entirely different mechanism. SetupDynamicConfig.php now contains a few categories of things: * Post-processing of configuration settings, where already-set settings are altered. This could be moved to MainConfigSchema too as a separate set of methods. * Processing of old aliases of settings (blacklist, slave) that are not registered as settings anymore and therefore are not available to MainConfigSchema. This could perhaps be moved to LocalSettings processing somehow? * Setting $wgUseEnotif, which is also not registered as a setting. Easiest would be just to declare it as a setting and have it set unconditionally. * Setting the actual timezone to $wgLocaltimezone. This is not related to configuration and should just be in Setup.php. Bug: T305093 Change-Id: Ia5c23b52dbbfcb3d07ffcf5d3b7f2d7befba2a26
* Config builder optimisations (combined)Tim Starling2022-05-061-2/+41
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is a modified rebase of a patch by Tim, see I75f405930a7b14561389c59d147640e870146bec. Some benchmark results (from my laptop): Loading defaults from config-schema.php: - Master: 115/sec ( 8.7ms) - I75f4059: (Tim): 575/sec ( 1.7ms) - Id9dd0bf: (Daniel): 1120/sec ( 0.9ms) - This (Tim+Daniel): 1420/sec ( 0.7ms) Loading defaults and merging settings (worst case): - Master: 80/sec (12.4ms) - I75f4059: (Tim): 93/sec (10.8ms) - Id9dd0bf: (Daniel): 200/sec ( 4.9ms) - This (Tim+Daniel): 682/sec ( 1.5ms) Original commit message by Tim: * Explicitly import function array_key_exists to activate the special opcode * Batch creation of MergeStrategy objects * Batch default assignment to ArrayConfigBuilder The batches mostly help by allowing more inlining, eliminating some function calls. Reduced time for apply/finalize benchmark from 540µs to 170µs. Co-Authored-By: Tim Starling <tstarling@wikimedia.org> Change-Id: I3d4dd685eaaa4351801b3bac6ce1592eea925c5f
* ConfigBuilder: introduce setMulti() for bulk updatesdaniel2022-05-051-5/+5
| | | | | | | | | When no merge strategies are needed, config values can be set in bulk. This patch only uses it for config-overrides, but it is intended to be used for config-schema in a follow-up. Change-Id: Ic7e62513ad5227887f8a83bb8b757b5667643989
* SettingsBuilder: remove @unstable markers.daniel2022-05-031-0/+5
| | | | | | | The @unstable markers were intended for the 1.38 release. The interface can be conisdered stable in 1.39. Change-Id: Ie2fdd5bfe2622aa8845883019c1666dfb3073719
* config-schema: Define types for all arrays.daniel2022-02-231-14/+9
| | | | | | | | | | | | | | | | | | This patch ensures that we know which arrays are lists (JsonSchema type "array") and which are maps (JsonSchema type "object"). We can then default to array_merge for lists and to array_plus for maps. This seems clearer than requiring an explicit merge strategy to be declared for all arrays. This patch specified a mergeTrategy for some config variables that need behavior different from the default. This patch also changes the merging behavior to allow non-array values to replace arrays and vice versa. It also changes the behavior of defaults to allow falsy values to override non-falsy defaults. Bug: T300129 Change-Id: Ia7b0c0250af6a957eac1efb554fb47511f5e093f
* Introduce IterableConfigdaniel2022-02-141-1/+3
| | | | | Bug: T301544 Change-Id: I0a93ebb5305f95cf1b12df276f25a44195fedafa
* SettingsBuilder: fix merging into globalsdaniel2022-01-241-23/+5
| | | | | | | | | | | GlobalConfigBuilder needs to use the appropriate merge strategy to combine new values with the value already rpesent in a global variable. For this, GlobalConfigBuilder needs to actually look at the current value of the global variable. Also, we need to define merge strategies for all settings that need them (at least the ones used directly by ExtensionProcessor). Change-Id: I834d4b3506bdd8d416e5eb6e03fb4dd6b60b6e05
* GlobalConfigSink: don't double-prefix in setDefaultPetr Pchelko2021-11-301-1/+1
| | | | | | | $this->set was calling the overridden method, so if it was called from setDefault, we'd end up double-prefixing the config. Change-Id: I5f912332cc69cb58bb71e87cd9f8154246b53232
* SettingsBuilder: add ability to validate config against schemaPetr Pchelko2021-11-301-3/+3
| | | | | | | | | | | | Not yet sure if config validation makes sense in production, possibly before we write into cache we can validate, and then trust that the cached values are all valid. This patch just adds ability to validate the configuration. "justinrainbow/json-schema" is already a transitive dependency and is already in vendor. Change-Id: Ib039c897a36a7e1911309fd29514657042b1b139
* Introduce MergeStrategies for ConfigSinkPetr Pchelko2021-11-161-22/+29
| | | | Change-Id: Ibb4fdf83d87ad204da5fbc4892c9b7610e979f72
* Introducing SettingsBuilder for loading settings files.daniel2021-11-121-0/+49
The goal is to use SettingsBuilder to load settings from JSON files instead of relying on PHP files that manipulate global variables. To allow for a smooth transition to the new system, config settings read from JSON files will be applied to global variables, and it will be possible to load JSON files programmatically from inside traditional settings files. Bug: T294740 Bug: T295500 Bug: T294741 Change-Id: Ibf52c660715fd0e6e67fea5169811ece9ed67cf7