| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
Change-Id: I2c1bc3b4e0ee782076ddaeae133672b730d345d9
|
| |
|
|
|
|
|
| |
Found via disabling phan's alias support for a run (and ignoring wgLang's
hard-coded state of being a \Language, alas).
Change-Id: I4753bcd84d72d6de111fc7ffc5841fa417bf7333
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Why:
* Maintenance scripts in core have bolierplate code that is
added before and after the class to allow directly running
the maintenance script.
* Running the maintenance script directly has been deprecated
since 1.40, so this boilerplate code is only to support a now
deprecated method of running maintenance scripts.
* This code cannot also be marked as covered, due to PHPUnit
not recognising code coverage for files.
* Therefore, it is best to ignore this boilerplate code in code
coverage reports as it cannot be marked as covered and also
is for deprecated code.
What:
* Wrap the boilerplate code (requiring Maintenance.php and then
later defining the maintenance script class and running if the
maintenance script was called directly) with @codeCoverageIgnore
comments.
* Some files use a different boilerplate code, however, these
should also be marked as ignored for coverage for the same
reason that coverage is not properly reported for files.
Bug: T371167
Change-Id: I32f5c6362dfb354149a48ce9c28da9a7fc494f7c
|
| |
|
|
|
| |
Bug: T353458
Change-Id: Ifa3b6a6e0353bb4ce21a3f4456f1fc696c8d377c
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The purpose of MW_USE_LEGACY_DEFAULT_SETTINGS was to allow Setup.php to
load default values from DefaultSettings.php, instead of using
MainConfigSchema. It was put into place for the benefit of third-party
installations that encounter issues with using MainConfigSchema. No such
issues have been reported, so we can remove the compatibility switch in
1.40.
The use of DefaultSettings.php as been deprecated since 1.39, but there
are still several extensions that rely on loading it. It remains a stub
for MainConfigSchema::listDefaultValues() for now.
Change-Id: I280f80e5be15fbcd809596087b299add5f83af1f
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
| |
Bug: T305093
Change-Id: I7f4d6b2f2a4be01e5e5a65f94b7d91565e417b4b
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
Change-Id: I323a3469c574b55ad78abb35863f30b1007f3135
|
