aboutsummaryrefslogtreecommitdiffstats
path: root/includes/Settings/SettingsBuilder.php
Commit message (Collapse)AuthorAgeFilesLines
* Use explicit nullable type on parameter argumentsUmherirrender2024-10-161-1/+1
| | | | | | | | | | | Implicitly marking parameter $... as nullable is deprecated in php8.4, the explicit nullable type must be used instead Created with autofix from Ide15839e98a6229c22584d1c1c88c690982e1d7a Break one long line in SpecialPage.php Bug: T376276 Change-Id: I807257b2ba1ab2744ab74d9572c9c3d3ac2a968e
* Add MediaWiki\Registration namespace to registration classesEbrahim Byagowi2024-08-101-1/+1
| | | | | Bug: T353458 Change-Id: Ifa3b6a6e0353bb4ce21a3f4456f1fc696c8d377c
* Add namespace to the root classes of ObjectCacheEbrahim Byagowi2024-07-101-1/+1
| | | | | | | | | And deprecated aliases for the the no namespaced classes. ReplicatedBagOStuff that already is deprecated isn't moved. Bug: T353458 Change-Id: Ie01962517e5b53e59b9721e9996d4f1ea95abb51
* Namespace Config-related classes under \MediaWiki\ConfigJames D. Forrester2023-09-211-2/+2
| | | | | Bug: T166010 Change-Id: I4066885a7ea071d22497abcdb3f95e73e154d08c
* SettingsBuilder: prevent access to the global instance in unit testsDaimona Eaytoy2023-09-121-0/+27
| | | | | | Unit tests must use dependency injection, not global instances. Change-Id: If7e35a67edc2337657bec4e35724d7f6bc034418
* Treat $wgHooks as a regular settingdaniel2023-03-091-0/+17
| | | | | | | | | | | | | | | | | | $wgHooks should be treated like a regular setting, which cannot be manipulated after bootstrapping is complete. This will allow us to greatly simplify the logic in HookContainer. Replacing $wgHooks with a fake array after bootstrapping allows us to detect any remaining live access to $wgHooks without breaking functionality. The plan is to have the fake array emit deprecation warnings in the 1.40 release, and make it throw exceptions in later releases. See Iddcb760cf8961316d6527e81b9aa968657d8354c for the deprecation warnings. Bug: T331602 Change-Id: I0ebba9a29f81b0d86ad8fd84d478fb244f9e9c15
* SettingsBuilder: introduce a "registration" stagedaniel2022-12-161-18/+121
| | | | | | | | | | | | | | | | | | Previously, SettingsBuilder would allow configuration to be loaded and modified until it was "finalized", at which point configuration became read only. This patch introduces an intermediate stage where registration dynamic manipulation of config values can be performed, after all extensions have been loaded and all config schemas are known. Motivation: Extension registration callbacks are typically used to dynamically set config variables, often based on other configuration. This should be done using SettingsBuilder rather than global variables. But previously, we could only be sure that all extensions are known after SettingsBuilder was "finalized", at which point it would be impossible to change config values. Change-Id: I6f8f9f3f7252f0024282d7b005671f28a5b3acc3
* Settings: Introduce SettingsBuilder::getInstance to avoid $wgSettingsdaniel2022-11-171-0/+30
| | | | | | | | | While accessing a SettingsBuilder instance via global state should not be encouraged, we still need it sometimes. So use a static getter instead of a global variable. That way, we can emit deprecation warnings when we have proper alternatives available. Change-Id: I0013bdab474710fd521532dd2653b3789e2ede34
* Settings: add support for obsolete configdaniel2022-10-141-1/+38
| | | | | | | | | | | | | | | | | | This allows config variables to be declared obsolete. Obsolete config will be omitted from the schema, defaults, name constants, etc. The purpose of keeping a declaration of obsolete config around is to allow the updater to warn admins that they are using a config variable that no longer has any effect, and provide them with a remedy. The idea is that support for deprecated config can be removed after one release per the stable interface policy, but the declaration of obsolete config should be kept for as long as we support updates, that is, at least two LTS releases. See https://www.mediawiki.org/wiki/Topic:X4bh4nf3pe2ho5jj for discussion. Change-Id: Ia7a00742ea7a5311e820a6a43b11135a3f2a825f
* SettingsBuilder: report warningsdaniel2022-07-151-0/+60
| | | | | | | | | | | This adds functionality to SettingsBuilder for collecting warnings to be logged later, when the logging mechanism has been set up. This also adds a validation step to update.php that aborts the update if any warnings have been registered in SettingsBuilder, or the settings fail to validate against the settings schema. Change-Id: I387905289fb93591f79b96bf4c6cb5ec692b2aff
* Move dynamic defaults into MainConfigSchemaAryeh Gregor2022-07-071-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add support for nested property schemas in MainConfigSchema.daniel2022-06-291-2/+2
| | | | | | | | | | | | 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
* Turn DefaultSettings.php into a deprecated stubdaniel2022-05-171-2/+19
| | | | | | | | | | | 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
* Config builder optimisations (combined)Tim Starling2022-05-061-13/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Use inverted schema definition for fast loading.daniel2022-05-061-22/+57
| | | | | | | | | | | | | | | | | | | 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
* ConfigBuilder: introduce setMulti() for bulk updatesdaniel2022-05-051-3/+3
| | | | | | | | | 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
* Settings: Skip merging logic for defaults when possibledaniel2022-05-051-10/+59
| | | | | | | | | | | | When loading defaults from config-schema (previously known as DefaultSettings), we can just blindly set the values, as no overrides have been applied yet at this point (e.g. from LocalSettings.php), and thus no need for backward merging. We only need to apply backwards merging of defaults for config variables that may have actually already at the time that the default is loaded. Change-Id: I415f865a77c091b75a2ce38da02d1dfbd7ead106
* SettingsBuilder: remove @unstable markers.daniel2022-05-031-15/+4
| | | | | | | The @unstable markers were intended for the 1.38 release. The interface can be conisdered stable in 1.39. Change-Id: Ie2fdd5bfe2622aa8845883019c1666dfb3073719
* Use MainConfigNames instead of string literals, #4Aryeh Gregor2022-04-261-4/+5
| | | | | | | | | | | | | | | | | | | | | Now largely automated: VARS=$(grep -o "'[A-Za-z0-9_]*'" includes/MainConfigNames.php | \ tr "\n" '|' | sed "s/|$/\n/;s/'//g") sed -i -E "s/'($VARS)'/MainConfigNames::\1/g" \ $(grep -ERIl "'($VARS)'" includes/) Then git add -p with lots of error-prone manual checking. Then semi-manually add all the necessary "use" lines: vim $(grep -L 'use MediaWiki\\MainConfigNames;' \ $(git diff --cached --name-only --diff-filter=M HEAD^)) I didn't bother fixing lines that were over 100 characters unless they were over 120 and triggered phpcs. Bug: T305805 Change-Id: I74e0ab511abecb276717ad4276a124760a268147
* Add wiki-farm supportdaniel2022-04-011-0/+15
| | | | | | | | | | | | Added support for an easy to configure multi-tenant ("wiki farm") mode: Settings for each site can be placed in a directory specified by $wgWikiFarmSettingsDirectory. Site detection is controlled by $wgWikiFarmSiteDetector and defaults to the requested host name. Instructions for manual testing: https://etherpad.wikimedia.org/p/T221535 Bug: T221535 Change-Id: I7581921b7d99ba1fe7e25523fde691d76b67a99c
* phan: Remove PhanPossiblyUndeclaredVariable suppressionUmherirrender2022-03-301-1/+1
| | | | | | | | | Make phan stricter about conditional variable declaration Remaining false positive issues are suppressed. The suppression and the setting change can only be done together Bug: T259172 Change-Id: I1f200ac37df7448453688bf464a8250c97313e5d
* Allow LocalSettings.php to be loaded in function scope.daniel2022-03-281-0/+10
| | | | | | | | | | | | | | This adds an experimental mode that loads LocalSettings.php in a function, rather than in top level global scope. This is controlled using the MW_USE_LOCAL_SETTINGS_LOADER environment variable. This is not intended for use in production as this time. The experimental mode should be available in the 1.38 release, so people can try it out with different setups. Bug: T304183 Depends-On: Ie6245ff8cd2bc7bab2af3b1450070185dbc2d824 Change-Id: I0f20024803336064ecb07b51fa56581af7b67a85
* SettingsBuilder: add comments about batched caching.daniel2022-03-231-0/+3
| | | | | | | | | | | | One reason to have batching in SettingsBuilder is so we can cache an entire batch of settings after merging them, rather than caching each file individually. However, this has not been implemented, and it's not entirely clear if it's a good idea. This patch adds comments to SettingsBuilder that point to the relevant ticket, for reference and consideration when working on SettingsBuilder in the future. Bug: T304493 Change-Id: I1fb7b7e4a97e6d0788c9b1732a1718f3c8b365d5
* phan: Disable null_casts_as_any_type settingUmherirrender2022-03-211-0/+1
| | | | | | | | | | | Make phan stricter about null types by setting null_casts_as_any_type to false (the default in mediawiki-phan-config) Remaining false positive issues are suppressed. The suppression and the setting change can only be done together Bug: T242536 Bug: T301991 Change-Id: I0f295382b96fb3be8037a01c10487d9d591e7e01
* Fix edge cases in schema validation.daniel2022-03-081-26/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix various documentation related to null typesUmherirrender2022-02-261-1/+1
| | | | | | | | The functions returning null or the class property is set explict null Found by phan strict checks Change-Id: I4a271093fb6526564d8083a08249c64cb21f2453
* Merge "Avoid references to DefaultSettings."jenkins-bot2022-02-221-2/+3
|\
| * Avoid references to DefaultSettings.daniel2022-02-221-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This replaces references to DefaultSettings with references to config-schema.yaml where appropriate. NOTE: this does not yet change Setup.php. DefaultSettings.php remains intact and is still being used. NOTE: this does not remove usages in the installer, see I5d8843a1062fbf for that. Bug: T300129 Change-Id: Ie6152cf510c3be61bc22167ca6d90dfc28910a45
* | Allow config merge strategies to be bypassed.daniel2022-02-221-14/+69
|/ | | | | | | | | | Sometimes, we need to force an exact value and bypass the default behavior of merging config variables. This also renames setConfigValue to putConfigValue, to avoid confusion about the behavior of that method. Change-Id: I82c606632b94f974e655a44a0b63394de7a0804b
* Reapply "SettingsBuilder: allow maintenance scripts to manipulate config"Ppchelko2022-01-261-5/+86
| | | | | | | | | | This reverts commit 4f7a4a2477ceeac68011d8f550a30d005c78dfdf. Reason for revert: This change is good, just need some preparation in extensions. Depends-On: I24221be2cedfa132fc94d39d72e4a133cc3cdb12 Depends-On: I5e6119b650e581c6aa5a1132aa071b49cff8b8ca Change-Id: I5a5a9000751fa3914c9d432eb49475091b3bdb80
* Revert "SettingsBuilder: allow maintenance scripts to manipulate config"Ppchelko2022-01-261-86/+5
| | | | | | | | This reverts commit a652f306a542c0efdfa0bef33cd68c8f6587e0bc. Reason for revert: need to prepare extensions first Change-Id: Iccedf38a8dc964db7c49fd51c971912655122081
* SettingsBuilder: allow maintenance scripts to manipulate configdaniel2022-01-261-5/+86
| | | | | | | | | | | Maintenance scripts often need to manipulate configuration settings. This introduces a way to do this cleanly via SettingsBuilder, removing the need to rely on global variables. Bug: T294739 Bug: T294742 Bug: T300128 Change-Id: Ibf443fd564bbbf388cce8ab4dabba55ebca0dfa4
* SettingsBuilder: expose default configPetr Pchelko2022-01-201-0/+11
| | | | | | | This will be useful in CI Bug: T296045 Change-Id: I4d412c5ff2abe9c07f4cbe0b299f0ddf6fb6a169
* SettingsBuilder: load settings recursivelydaniel2022-01-181-13/+80
| | | | | | Allows settings files to include other settings files. Change-Id: Ieab7def1ada8b255e60c58927850a58e18309f6e
* Refactor SettingsBuilder to use BagOStuff.Dan Duvall2021-12-101-7/+7
| | | | | | | | | | | | | | Removed use of Psr\SimpleCache\CacheInterface in favor of BagOStuff, as the latter is a tried-and-true abstraction and the former offers no real upfront benefits since the caching patterns of SettingsBuilder are quite basic at this time. The simplicity of cache interface use is largely in part to the minimal probabilistic stampede protection implementation within CachedSource which is left untouched by this change. Bug: T294748 Change-Id: Ie59b37a8d5c7bf96225757fa9eb9d2c762476713
* SettingsBuilder: load skins and extensionsdaniel2021-12-071-0/+31
| | | | | | | | | | | | This is a minimal baseline implementation that allows skins and extensions to be loaded from settings files. This should be improved by closely integrating SettingsBuilder with ExtensionRegistry. They should probably end up being the same thing eventually. Loading extension.json is essentially the same as loading settings files. Change-Id: I02a1d9b517815463f150b53c0602927609ff9eeb
* Settings: Prevent applying more settings after invoking `->finalize()`Derick Alangi2021-12-021-0/+32
| | | | | | | | | | | | When we're done applying settings and we call `finalize()`, any further attempt to apply settings too late should throw. This is a defensive mechanism for us to track the state of settings applied in during setup process and will guide us to bring all settings to be applied in the appropriate place so unexpected things don't happen. Bug: T296684 Change-Id: Id58654c8265bc8310e1fe464ff5a480aad8a8666
* SettingsBuilder: add ability to validate config against schemaPetr Pchelko2021-11-301-5/+46
| | | | | | | | | | | | 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
* Cache loading of SettingsBuilder sourcesDan Duvall2021-11-291-4/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The `SettingsBuilder` now accepts a PSR-16 cache interface with which to store and query settings before attempting to load from each source. By default, no cache is used, but any object that implements the `Psr\SimpleCache\CacheInterface` may be provided to the constructor. An explicit dependency on "psr/simple-cache" has been added to `composer.json`. Note that this dependency already existed in vendor albeit it as a transitive one. An APCu based `SharedMemoryCache` adapter is provided as a canonical PSR-16 compliant interface for production use. Sources are now queued by the `SettingsBuilder` when calling `load()`. If a cache interface has been provided, and the source is considered cacheable (implements `CacheableSource`), then it is wrapped as a `CachedSource` which will query the cache first before loading from the wrapped source. Cache stampedes are mitigated using probabilistic early expiry. The implementation for this was partially based on symfony/cache-contract source code but also from the Wikipedia article and paper referenced therein. See https://en.wikipedia.org/wiki/Cache_stampede#Probabilistic_early_expiration Bug: T294748 Change-Id: I52ab3899731546876ee58265bd4a1927886746dc
* Introduce setting PHP_INI env configs via a settings sourceDerick Alangi2021-11-251-1/+15
| | | | | | | | | | | | | | | | | | | | This feature enables the SettingsBuilder to be able to set php-ini environment variables at run-time. We just do so by specifying the various key/value pairs to the `php-ini` key like below: ``` "php-ini": { "key": "value", ... } ``` This will allow us to set things like `display_errors`, `memory_limits` etc. Bug: T294752 Change-Id: I2ff0e7abc010342537bbaf1e1b71fb84d02a153b
* SettingsBuilder: Apply merge strategy from the schema to the configPetr Pchelko2021-11-161-31/+36
| | | | Change-Id: Ia75f501c29d7589782cbbe99f723841dcd2acb75
* Introduce MergeStrategies for ConfigSinkPetr Pchelko2021-11-161-1/+1
| | | | Change-Id: Ibb4fdf83d87ad204da5fbc4892c9b7610e979f72
* Introduced settings sources and formatsDan Duvall2021-11-151-43/+38
| | | | | | | | | | | | | | | | | | | | | | A `SettingsSource` is meant to represent any kind of local or remote store from which settings can be read, be this a local file, remote URL, database, etc. It is concerned with reading in (and possibly decoding) settings data, and computing a consistent hash key that may be used in caching. A `SettingsFormat` is meant to detect supported file types and/or decode source contents into settings arrays. As of now, JSON is the only supported format but others may be implemented. `FileSource` is the first source implementation, with its default format being JSON, meant to read settings from local JSON files. `ArraySource` is mostly useful for testing using array literals. Refactored `SettingsBuilder` methods to use the new source abstractions. Bug: T295499 Change-Id: If7869609c4ad1ccd0894d5ba358f885007168972
* Introducing SettingsBuilder for loading settings files.daniel2021-11-121-0/+131
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
generated by cgit v1.2.3 (git 2.25.1) at 2025-04-25 03:25:02 +0000