This patch introduces a namespace declaration for the
MediaWiki\Json to FormatJson and establishes a class
alias marked as deprecated since version 1.43.
Bug: T353458
Change-Id: I5e1311e4eb7a878a7db319b725ae262f40671c32
This reverts commit 4f7a4a2477.
Reason for revert: This change is good, just need some preparation in extensions.
Depends-On: I24221be2cedfa132fc94d39d72e4a133cc3cdb12
Depends-On: I5e6119b650e581c6aa5a1132aa071b49cff8b8ca
Change-Id: I5a5a9000751fa3914c9d432eb49475091b3bdb80
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
Add a config flag to allow for partial output on error. An extra
configuration variable is exported with the result so the client can
know that an error occurred during serialization.
Misc:
* Remove the unneeded $out variable null declaration
Bug: T294786
Change-Id: I8f8f504cf614cbd81323f536e7ea255a4aff5907
T110209 caused maintenance scripts to fail on unknown parameters,
which is normally desirable. However, some extensions (notably
SemanticMediaWiki) need to support additional params and had no
way to add them to the list of expected parameters. It will
now be possible them to update.php via a new hook:
MaintenanceUpdateAddParams.
Bug: T213893
Change-Id: Ia40949ccb2f32090f21e0f3f7e5b9c4aef322330
Deprecate the second argument to Maintenance::error() in favor of a new
Maintenance::fatalError() method. This is intended to make it easier to
review flow control in maintenance scripts.
Change-Id: I75699008638f7e99b11210c7bb9e2e131fca7c9e
isset() will return false with a value is null. Null is an acceptable
result for a configuration variable, so switch to array_key_exists.
Change-Id: I11a3feb07d2bdc7ee30975014db29365086f89bc
This patch causes php maintenance/getConfiguration.php to die with a fatal
error:
Fatal error: Call to a member function isItemLoaded() on a non-object
in includes/GlobalFunctions.php on line 1268
Call Stack:
1. {main}() maintenance/getConfiguration.php:0
2. require_once('maintenance/doMaintenance.php')
maintenance/getConfiguration.php:196
3. wfLogProfilingData() maintenance/doMaintenance.php:116
When calling wfLogProfilingData() the $wgUser is undefined which causes the
fatal at:
if ( $wgUser->isItemLoaded( 'id' ) && $wgUser->isAnon() ) {
$forward .= ' anon';
}
This reverts commit 2c9de255f7.
Change-Id: I093d8fbe2c08875808868d449a90b620cc6c94a6
Let us dump global settings based on regex.
* --regex and --iregex to filter globals in $GLOBALS
* validation of --format
* format is now case insensitive
* vardump format
Change-Id: I3a1ddc8ab3c9e41a47b55f412e7f2b018e99b647
Follows-up I1343872de7, Ia533aedf63 and I2df2f80b81.
Also updated usage in text in documentation and the
installer LocalSettingsGenerator.
Most of them were handled by this regex:
- find: (require|include|require_once|include_once)\s*\(\s*(.+?)\s*\)\s*;$
- replace: $1 $2;
Change-Id: I6b38aad9a5149c9c43ce18bd8edbab14b8ce43fa
Squiz.WhiteSpace.LanguageConstructSpacing:
Language constructs must be followed by a single space;
expected "require_once expression" but found
"require_once(expression)"
It is a keyword (e.g. like `new`, `return` and `print`). As
such the parentheses don't make sense.
Per our code conventions, we use a space after keywords like
these. We appeared to have an unwritten exception for `require`
that doesn't make sense. About 60% of require/include usage
was missing the space and/or had superfluous parentheses.
It is as silly as print("foo") or return("foo"), it works
because keywords have no significance for whitespace between
it and the expression that follows, and since experessions can
be wrapped in parentheses for clarity (e.g. when doing string
concatenation or mathematical operations) the parenthesis
before and after basiclaly just ignored.
Change-Id: I2df2f80b8123714bea7e0771bf94b51ad5bb4b87
* getQueueTypes() now gets the config of the target wiki.
Previously, for WMF, if an extension using jobs was not
on aawiki, those job queues would not be seen by nextJobDB.
* Also fixed nextJobDB.php so that it no longer only considers
jobs types known to aawiki for picking a DB for default jobs.
* Note that $wgJobTypesExcludedFromDefaultQueue should be global.
* This adds a SiteConfiguration::getConfig() function, which calls
a new getConfiguration.php script.
Change-Id: I7e6904ead17efa407291f423a2b18e3c866d55fd
