Previously, each of the four derived config schema files had to be
regenerated using a separate maintenance script. This change simplifies
regeneration by combining all for scripts into a single command that can
be used to regenerate all relevant files after changing
MainConfigSchema.
Change-Id: I7d38d8a4aede60475c4bdd0053d2e10e298b9843
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 was changed to support in-place updates of files,
but the idea which was since abandoned. So we can go back to
using stdout.
Change-Id: I825a00258c4f50244679fc47c81b6920dd241647
We can generate a class that contains constants for all config variable
names. This removes the need to rely on string literals when calling
Config::get, and it provides a place for documentation that integrates
better with IDEs than the markdown file.
Change-Id: I817dc14c4ce8fc0a29d9c07e8fd393c4f359cade
Instead of maintaining the config schema as a yaml file, we
maintain it as a set of constants in a class. From the information in
these constants, we can generate a JSON schema (yaml) file, and an
php file containing optimized arrays for fast loading.
Advantages:
- PHP doc available to IDEs. The generated markdown file is no longer
needed.
- Can use PHP constants when defining default values.
NOTE: needs backport to 1.38
Change-Id: I663c08b8a200644cbe7e5f65c20f1592a4f3974d
This ensures that assertions work in a uniform way,
and provides meaningful messages in cause of failure.
Change-Id: Ic01715b9a55444d3df6b5d4097e78cb8ac082b3e
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
$wgStyleSheetPath has been a deprecated alias for $wgStylePath since 1.3 (2004).
Time to get rid of it.
Change-Id: I78a6394003b9aefab7aa8559b8e2b22bc50154fc
This would have saved me around an hour if I knew it earlier. Let's make
it not happen for others.
Change-Id: I2e146424fc01677383a15d98071d8cbc2d832d9b
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
This is a first draft of the configuration doc renderer.
The resulting markdown certainly needs some love, but
we can work on improvements incrementally. This gives
us a baseline to reference on doc.wikimedia.org
Bug: T296647
Change-Id: I3c426b9fc37b1cf7ce8423969b2d7589767ee6cc
In order to allow configuration default to come from JsonSchema,
and dynamic defaults need to be initialized in Setup.php.
This movesd the initialialization of $wgExtensionDirectory and $wgStyleDirectory
to Setup.php
Bug: T294788
Change-Id: I11f5723aa299caa210cf6a1f5b7436f191b1ffc2
The config-schema.yaml follows the settings file format.
It's not used in reality yet, but tests were added
to compare the yaml with the result of DefaultSettings.php
importing.
The list of properties not yet included:
- 'wgVersion' - deprecated alias to MW_VERSION
- 'wgConf' - instance of SiteConfiguration
- 'wgStyleSheetPath' - alias to another global
- 'wgExtensionDirectory', - depends on $IP
- 'wgStyleDirectory' - depends on $IP
- 'wgServiceWiringFiles' - depends on __DIR__
- 'wgHTTPMaxTimeout' - infinity default
- 'wgHTTPMaxConnectTimeout', - Infinity default
The PHPDoc was copied over as is into description fields,
it will be converted to something more pleasant in a separate
iteration.
The types were parsed out of PHPDoc and fixed up manually.
Default values come from executing DefaultSettings and serializing
the values into YAML.
Change-Id: I9aa9ad9713bdbdac2bd7b528c609772154b5a135
