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
Unused since change I88754b52c2 (commit 9e95539fc9) – this was only used
for SessionProviders, which is now a map/object instead.
Change-Id: I8da686e6379eb33a63799874fb44f9b0030ab5ba
This adds support for JSONSchema style property declarations with nested
schemas. This is a step towards using more nested structured for
configuration, rather than adding to the over 700 keys already defined
in the main config schema.
Defaults from property schemas are aggregated into a default value in
the top level schema. Descriptions are however not yet aggregated.
Change-Id: Iaf46a9ecc83bee3566098c56137a1be66bff2ab9
By optimizing the structure of config-schema.php for fast loading,
some information needed for schema validation was lost. This patch
ensures that all schema information is retained in config-schema.php.
The code for consuming this field already existed, as written for
what we already output to the generated config.schema.yaml file.
Bug: T307769
Change-Id: I8adcdfd2b8fb5f5b96308eea74c07d8cc7a4d6ba
DefaultSettings.php has been replaced by MainConfigSchema.
Loading DefaultSettings.php is deprecated.
Code that needs to have access to configuration defaults should use the
ConfigSchema service object.
Bug: T300129
Change-Id: I7b2c0ca95a78990be1cdb9dd9ace92f6dcf1af15
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
If we pre-generate the data structure for holding schemas in a way
that is optimized for the way we typically access this information
we can save time on initialization:
Instead of having the schema for a given setting in one array with keys
for the default, type, etc, this puts all defaults into one array, all
types into another array, etc. This allows the default values to be
copied in bulk, without having to iterate over the 700+ settings and
look for a default value in each schema array.
Benchmark results from my laptop: 0.85ms for loading config-schema.php,
that is a 85% improvement over the 6.3ms it took before.
It's even 32% faster than loading DefaultSettings.php, which takes 1.26ms.
Bug: T300129
Change-Id: Id9dd0bff6a6d4b501e74237b5d7198088c38c302
Since PHP arrays make no clear distinction between lists (JSON arrays)
and maps (JSON objects), some edge case handling is needed to make
validation work reliably when we declare types for all arrays:
1) Allow array keys to be ignored, so an associative PHP array validates
as a JSON array. This is needed for the SessionProviders setting.
2) Allow associative arrays with numeric keys to validate as JSON
objects. This is done by ignoring the type validation when numeric keys
are detected. A warning is returned in the status object.
3) Work around validation failing on float values that are expected to
be integers. All numbers come from the yaml parser as floats, and the
"integer" type in JSON schema should accept floats with if the
fractional part is 0. But that doesn't seem to work, we need to cast the
values to integers explicitly.
Also, this fixes some mistakes in the schema: LockManagers is a list,
so it should use the JSON type "array". NamespacesToBeSearchedDefault
is a map (JSON object), even though it uses numeric keys. The Actions
registry is also a map.
Change-Id: I9d0453d740c377b7cce574df743536c39a0ec619
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
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
