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
Maintenance::finalSetup should have access to a SettingsBuilder so it
can manipulates config settings without resorting to global variables.
MaintenanceRunner will always provide a SettingsBuilder when calling
this method, so implementations should be able to rely on always getting
one.
The $settings parameter was introduced as optional in order to maintain
backwards compatibility with implementations that did not declare the
parameter. But these should all have been fixed since.
Depends-On: I8a3699b13bfb4dc15f3bed562731ed9d525651cc
Change-Id: I334a103e02fd905faafc43c7c5b95996bc91fd18
This is no longer needed for Wikimedia wikis; wmf-config/extension-list
now only lists JSON files.
Such support is probably now broken anyway, given that any legacy PHP
entry point would no longer be loaded from file scope since commit
9e708cece7.
Change-Id: Ide08c3aac8f5dc72b0e44f728cb2b6fa9e55d2e6
This reverts commit 683cd2f4d7
to restore I349ef565a7c08f90a75b0fc6db49f030cb56f6cf.
Reason: fixed a typo that led to message dirs being ignored:
The correct name of the setting is "wgMessagesDirs", the original
patch had "wgMessageDirs".
I confirmed locally that the new version produces the same output
as the old.
Change-Id: I32f45438ba37ed08075aadc9b1d83db88ca5f014
All the other ways of doing it were ridiculous and much harder to read,
and usually required repeating the needle expression (to get its
length). I found these occurrences by grepping for various expressions,
but I undoubtedly missed some.
I didn't try replacing the many instances of strpos(...) === 0 with
str_starts_with(...), because I think they're readable enough as-is
(although less efficient). Likewise I didn't try porting strpos(...) !==
false to str_contains(...). For case-insensitive comparisons, Tim
Starling requested that we stick with substr_compare() because it's more
efficient than calling strtolower().
On PHP < 8 these functions will be included with a polyfill via
vendor/autoload.php. This is included at the beginning of
includes/AutoLoader.php, so if our autoloader has been included the
polyfill will be available. This means it should be safe to call these
functions from any code that would not be usable without our autoloader.
Three uses that Tim Starling identified as being performance-sensitive
have been split out to a separate commit for porting after the switch to
PHP 8.
Change-Id: I113a8d052b6845852c15969a2f0e6fbbe3e9f8d9
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
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
The `MergeMessageFileList` maintenance class is commonly run prior to
`RebuildLocalisationCache` in bootstrapping a multiversion MediaWiki
installation. However, when the l10n cache is configured but not yet
built and a wiki's `$wgLanguageCode` is set to anything other than 'en',
all maintenance scripts will fail during setup.
Forcing `$wgLanguageCode` to 'en' just prior to the maintenance class
execution works around this issue. It was cargo culted from an identical
workaround in `RebuildLocalisationCache`.
Note that this issue may not be exclusively related to maintenance
scripts but of any post-setup script that attempts to run before l10n
caches have been built as failure occurs when `include/Setup.php`
attempts to set the `$wgContLang` global using a direct call to
`MediaWikiServices->getContentLanguage()` which in turn instantiates the
primary and fallback languages and attempts to preload the missing
cache. This root issue may be solved once `$wgContLang` is fully
deprecated using `DeprecatedGlobal` which will defer the call to
`getContentLanguage()` until the first method call on the global object.
For now, however, this workaround is necessary for successful
bootstrapping.
Change-Id: Ie62e4b8f33ad63813f37a59eacb9f47493a2d4ef
The `mergeMessageFileList` maintenance script does not need database
access and will need to be run in offline environments such as those for
building container images.
Bug: T260827
Bug: T238436
Change-Id: I3b10482e227e2414857d020526f00dc2116ef73e
If the call to file_put_contents fails, say something and exit
non-zero instead of silently ignoring the error.
Additionally, don't write a newline to STDERR in quiet mode.
Change-Id: I3b69c6c40fea6f689b6e1a4d550e87fafd200410
Many files were in the autoloader despite having potentially harmful
file-scope code.
* Exclude all CommandLineInc maintenance scripts from the autoloader.
* Introduce "NO_AUTOLOAD" tag which excludes the file containing it
from the autoloader. Use it on CommandLineInc.php and a few
suspicious-looking files without classes in case they are refactored
to add classes in the future.
* Add a test which parses all non-PSR4 class files and confirms that
they do not contain dangerous file-scope code. It's slow (15s) but
its results were enlightening.
* Several maintenance scripts define constants in the file scope,
intending to modify the behaviour of MediaWiki. Either move the
define() to a later setup function, or protect with NO_AUTOLOAD.
* Use require_once consistently with Maintenance.php and
doMaintenance.php, per the original convention which is supposed to
allow one maintenance script to use the class of another maintenance
script. Using require breaks autoloading of these maintenance class
files.
* When Maintenance.php is included, check if MediaWiki has already
started, and if so, return early. Revert the fix for T250003 which
is incompatible with this safety measure. Hopefully it was superseded
by splitting out the class file.
* In runScript.php add a redundant PHP_SAPI check since it does some
things in file-scope code before any other check will be run.
* Change the if(false) class_alias(...) to something more hackish and
more compatible with the new test.
* Some site-related scripts found Maintenance.php in a non-standard way.
Use the standard way.
* fileOpPerfTest.php called error_reporting(). Probably debugging code
left in; removed.
* Moved mediawiki.compress.7z registration from the class file to the
caller.
Change-Id: I1b1be90343a5ab678df6f1b1bdd03319dcf6537f
Sniff was renamed, phpcs violations are already
suppressed in phpcs.xml, no longer need these
individual line suppressions
Change-Id: I92ca4c6d576f1f0abada103a218155cc3aae38dd
The following function are set to public in the parent class and cannot
have another visibility in subclasses
Maintenance::__construct
Maintenance::execute
Maintenance::getDbType
Maintenance::validateParamsAndArgs
Maintenance::setDB
Change-Id: I0cd6514642d479aca20f1221bf673b0713c21631
*LogPage::timestamp was introduced with r4919 back in 2004, and is unused
since then.
*ApiMain::mCommit was introduced in r33133, then removed in r33381 but that
line was forgotten.
*SpecialRecentChangesLinked::mResultEmpty was introduced in r36682, then
removed at some point with this leftover.
*SpecialStatistics::hook, introduced in r54511 and unused since then.
*MergeMessageFileList::hasError introduced in Id4b16083435ef7f4fce31861c72889e664d07236
and removed in I3d9cf1d614dacaa91fb2092019ccf1d14d61ccab with a leftover
Change-Id: Ie15c148a3217ee8da62874840f3ef7739893f69e
And also update approximated counts, which for the most part are lower
than reported (hooray!)
Bug: T231636
Depends-On: Ica50297ec7c71a81ba2204f9763499da925067bd
Change-Id: I78354bf5f0c831108c8f606e50c87cf6bc00d8bd
The most notable removal is done in the orphans script. This code was
really never used. Brion introduced it in 2005, already disabled.
I have all the respect for what Brion did. I just think it does not make
much sense to keep code around for so long if it does not work anyway,
and must be rewritten from scratch anyway now that we have multi-content
revisions and such.
Change-Id: I4e8050929f90e44a6e6051bf938993a8b0cdf649
Clean up use of @codingStandardsIgnore
- @codingStandardsIgnoreFile -> phpcs:ignoreFile
- @codingStandardsIgnoreLine -> phpcs:ignore
- @codingStandardsIgnoreStart -> phpcs:disable
- @codingStandardsIgnoreEnd -> phpcs:enable
For phpcs:disable always the necessary sniffs are provided.
Some start/end pairs are changed to line ignore
Change-Id: I92ef235849bcc349c69e53504e664a155dd162c8
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
It doesn't make a ton of sense, it's just pointing out that we have
a weird extension for which we cannot detect a standard entry point
for. These (unfortunately) exist, but they're easily worked around
using --list-file
Removing the hard failure allows you to use the two options in
tandem... --extension-dir for the initial pass and then --list-file
for the weirdo outstanding ones
Change-Id: I3d9cf1d614dacaa91fb2092019ccf1d14d61ccab
If scap is modified to pass the path to both extensions/ and skins/ then
the extension-list file in wmf-config will no longer be needed, eliminating
many headaches. (refs T125678)
Bug: T125678
Change-Id: I4fd0c99d68fa32bf2378691955850a1be2c022df
return value from include_once is unreliable, it could be the value
of a 'return;' statement in the included file, or it could be false
when the file wasn't readable. This was breaking deployments because
one of the extensions had "return;" which caused include_once to
return a falsy value.
Change-Id: I48b9a55d5f9e85efe515d87b56b60ee71f939842
Implementation for https://www.mediawiki.org/wiki/Requests_for_comment/Localisation_format
Add $wgExtensionMessagesDirs, which tracks the directory
(or directories) where each extension stores it's JSON i18n files.
In this commit only support for messages is implemented, but adding
support for other i18n variables (e.g. magic words) is easy to do later.
To be backwards compatible, an extension can specify both
$wgExtensionMessagesFiles and $wgExtensionMessagesDirs. Older versions
of MediaWiki will just work, and newer versions will use the JSON files
while ignoring the PHP file (except if the PHP file contains non-message
data like magic words).
Misc changes:
* Updated mergeMessageFileList.php to output both
$wgExtensionMessagesFiles and $wgExtensionMessagesDirs
Change-Id: I8d137e15e1670880a9847263e6ce796c62a4670d
- Removed double spaces
- Added space after if/switch/foreach
- Removed space on elseif
- Added space around parentheses
- Added newline at end of file
- Removed space before semicolon at end of line
Change-Id: Id40b87e04786c6111e6686d7f7eea1e588bdf37d
We're currently working around a bug in an extension (bug 51643) by deviating
from lexicographical order in extension-list to ensure that one extension is
loaded before another. It'd be nice to be able to document that in the file
itself, but there is no convention for adding comments to the file;
mergeMessageFileList.php treats every line as a file name. We've previously
talked about including a comment header in the file as part of our reponse to
bug 50347.
This patch adds some minimal syntax-handling to mergeMessageFileList.php which
causes it to treat as a comment any substring starting with '#' and extending
to the end of the line. This change implements part of what aude projected for
Gerrit change 71056, but I don't see the harm in pushing ahead with it here.
Change-Id: I4b296aa69ad77ecb51f1a0e27ce6a698cf09732b
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
If there is a parse error or if one of the files in the extension list
doesn't exist, exit with an error. mw-update-l10n has set -e so it will
abort without syncing the new file.
Change-Id: Idaad65783127b075626c102a8dc02e22df1588b7
By PSR2 PHP Standard, the files should ends with exactly one newline.
Some of our files have 2 or more and some other were missing a newline.
Fix almost all occurences of CodeSniffer sniff:
PSR2.Files.EndFileNewline.TooMany
I have not fixed the selenium files, I believe we will drop them.
Change-Id: I89fca8c1786fee94855b7b77bb0f364001ee84b6
We can now do this since we finally switched to PHP 5.3 for MW 1.20 and get rid of the silly dirname(__FILE__) stuff :)
Change-Id: Id9b2c9cd2e678197aa81c78adced5d1d31ff57b1
