Changes to the use statements done automatically via script
Addition of missing use statement done manually
Change-Id: Ic4d4dd61de5ab896fb6173eb579c81f164a1e4a3
Passing the target user as performer allows taking into account
global permissions. This is in theory more important Setup.php
(autologin) than in AuthManager (login), and in any case it
probably actually works in Setup.php while it doesn't in
AuthManager (there are too many permission checks happening
at other places which ignore global permissions).
Follows up I2ad825317e900e865fffa39d4ea644f07beb4cf8.
Bug: T316303
Change-Id: I4dd1651702281cd1b68111b8613344cdae3875e9
For precedent see also change I6492f51428, I1e76d2f5ae, I98ea4670e8,
and many other results for "parse_url" in Codesearch (WMF Deployed).
This follows recent commits that clarified dependency on UrlUtils:
* I3f1d7a2da2f67a38a7d7a7b4268a93e01a01bf1e: Setup.php.
Same as before, no fallback check, because $wgServer must be valid.
* I5e36ee80e5c30e95b79bf45e7b26860cb2668d56: UserMailer.php.
Fallback to empty string, same as before.
* Id82a9fba6b3cdae3caf169eef5192766b33f0550: ParsoidHandler.php.
Change-Id: I57a8e7ea1b379779f31f562920888acc6656569e
At this point in Setup.php, we already have the services container,
so we can use the UrlUtils service and avoid the global function.
Change-Id: I3f1d7a2da2f67a38a7d7a7b4268a93e01a01bf1e
We can't pass the actual Status objects due to T269676, but
stringifying them is not good either, as the handlers for this
channel expect just a message key.
Bug: T275085
Change-Id: Idfcaf3455c04b8929dc820a43533cf008e9f41e8
The base phan config uses a file_exists check to determine whether to
use the namespaced class name, but it doesn't work when running against
core because MW_INSTALL_PATH isn't set. So specify the type in the local
config, and remove @phan-var annotations added in I6bbdbbe6.
Also use `::class` instead of string literals for classes.
Change-Id: I994a0ed32ea948253ed07ee3cc8868a0eaa6d8b9
And namespace it to MediaWiki\Config
This should be eventually deprecated and removed but this has been
blocking the reorg for long enough.
Bug: T321882
Change-Id: I7a1a073495469623f6f77e6f74b23b7b4c18033a
Promote the deprecation to an error in the context of PHPUnit tests. The
point of hard deprecations is to make tests fail and this will help with
that, and also with eventually promoting the deprecation to an error
outside of tests.
Adjust code in parser tests that was accessing MediaWikiServices via
Title too early.
Avoid hack of resetting the error handler after loading Setup.php, and
conditionally install MW's hadler instead. This is particularly
important in scenarios where an exception is thrown before the handler
is reset, because MW's exception handler may also access
MediaWikiServices.
Bug: T227900
Bug: T273261
Change-Id: I7c5234046379cf4abd25d65e78c0a99ac9f32600
The Hooks class contains deprecated functions and the whole class is
going to get removed, so remove the convenience function and inline the
code.
Bug: T335536
Change-Id: I8ef3468a64a0199996f26ef293543fcacdf2797f
This introduces the MW_AUTOLOAD_TEST_CLASSES switch to tell Setup.php
to enable auto-loading for test classes.
This switch can be set in file scope by core maintenance scripts that
need access to test classes. This is consistent with the mechanism used
by maintenance scripts to control other aspects of Setup.php
This is an alternative solution to the fix proposed in I17ff5867c5f57c524.
Change-Id: I2a0000f6a885c1ce1b28b748e8cc762af5584c2c
* Inappropriate @inheritDoc usage. Arguably all @inheritDoc is
inappropriate but these are the ones PHPStorm flags as misleading
due to the method not being inherited.
* Doc comment type does not match actual argument/return type.
* I replaced "@return void|never" with "@return void" since never means
never, it doesn't make sense for it to be conditional. If a method
can return (even if that is unlikely) then @return contains the type
that it returns. "@return never" means that there is no such type
because the method never returns.
* Incomplete/partial/broken doc tags
Change-Id: Ide86bd6d2b44387f37d234c2b059d6fbc42ec962
Unless this isn't a typo and I'm about to learn something.
Introduced in I157abfd9049fb8382da53005a084ab86f47e8d8a
Change-Id: Ic2f77071696a914f4aa388e020d4e7417cd9f898
wgCanonicalServer is false by default. Setup.php tried to set it to the
result of a wfExpandUrl() call, which initialised the UrlUtils
service with the current value of wgCanonicalServer, i.e. false.
UrlUtils had a fallback for null but not false. So subsequent calls to
wfExpandUrl() would always use the empty string for the canonical
server. Probably since 472a914c63.
So, have UrlUtils handle the fallback, and have Setup.php ask UrlUtils
for the final value.
Bug: T325529
Change-Id: I99329e75bd53049ae84a8ae7a2536ad12cfeeb3b
Based on Project:Support_desk, this seems to be a very common error.
Many more novice users seem to get confused by the technical message
involving "stat failed". Given that this might be the first user's
first experience with MW, I think its prudent to make it friendly
as possible.
This error message does not do i18n. I didn't do i18n to avoid
dependencies on MW stuff as it is very early in the setup process,
exceptions aren't usually i18n'd, and its entirely possible that
this error happens before a language is even set.
This does not respect $wgShowExceptionDetails. I think that can
be justified because this error happens during setup and not during
normal operation and there would be no user controlled values in
the backtrace just paths.
Bug: T321363
Change-Id: I4ed0d333d57626d05c361d08f1bf4a919115d550
$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
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
Maintenance scripts can now be run like this:
maintenance/run.php <class>
NOTE: This introduces a new callback into Setup.php,
MW_FINAL_SETUP_CALLBACK. In contrast to MW_SETUP_CALLBACK, it is
called after extensions have been initialized.
Bug: T99268
Change-Id: Ia221f72d6b7d23df74623d60ade7fe3e5d913074
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
MediaWikiTitleCodec: I removed the comment about dbkey being
"conveniently nullified" since that is no longer correct. The first
preg_replace() can return null, and that is guarded. The second
preg_replace() hopefully can't return null, because if it does, trim()
will generate a deprecation notice on PHP 8.1.
Some other self-explanatory changes.
Change-Id: Iad0ace821eba782c3033ec8abfeac461ac4e8ace
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
Follows-up I58ff3c193190d78a. Small step toward not run-time reading
the global (and using Config here is non-trivial/unsafe).
Change-Id: Ic527e493baabe700c50f75fadaa5b51615a5e597
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
Apparently, $wgLocaltimezone is set to the empty string in many
existing LocalSettings.php file, presumably because the installer
failed to detect the correct time zone.
The new code for handling automatic defaults will only trigger if
$wgLocaltimezone is null, not when it is otherwise empty.
This adds fallback code in strategic places to ensure that the empty
string is handled correctly.
Bug: T305093
Change-Id: I39226466f2bb6a36823ae9032fc62f981eabc64a
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
Follows-up I8520d8cb16 and Ib941c22d6b7ec5f1b9, and adds an internal
setter for use by Setup.php, and for wmf-config:rpc/RunSingleJob.php
which is a use case for setting it after Setup.php but before most
code execution. Interact with a component owner instead of directly
maintaining state and providing a shared API through the Config object.
Change-Id: I5c3d4b11f4e0eb3906ccb5b5fe3979e026459859
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
Allow callers of MWExceptionHandler::getStructuredExceptionData() and
jsonSerializeException() to explicitly control whether a backtrace is
included in the return value. This avoids the need to rely on the
LogExceptionBacktrace setting in static methods.
Bug: T294739
Change-Id: Ib941c22d6b7ec5f1b984bf5ded90652e42ad7b67
