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
maintenance/mergeMessageFileList.php is used by `scap` to establish a
list of message files to load. To do that, it read extensions paths from
a manually maintained list: wmf-config/extension-list.
This patch adds an optional automatic detection system to add extension
messages. That will reduce the risk of forgetting to update the
extension-list file and will be of good use on labs.
The new parameter is named --extensions-dir and takes a path holding
MediaWiki extensions. The script will take the directory names there and
attempt to load a file named `Foobar/Foobar.php`. --list-file is still
required, you can skip it using /dev/null.
Synopsis:
php maintenance/mergeMessageFileList.php \
--list-file /dev/null \
--extensions-dir /srv/mw-trunk/extensions
Script will bail out whenever an expected PHP file is not found and will
list all of those "missing" files.
Change-Id: I8ab15f899f0333428fd8b2a98c58c07c2fce2962
This reverts commit 5586e73fac.
This broke mergeMessageFileList.php by no longer running the extension
setup files in the global scope.
Change-Id: I8f22d0b3e938ba617f4297802edfc2012d78cc9b
Until now, we relied on setting MW_NO_SETUP which was a) hacky, b) irreversable, and c) likely to be forgotten if you didn't use one of the wrappers like runChild().
Instead, move the freaky magic to doMaintenance and have *it* check if it's in a specific call stack that indicates this is being run from the file scope and should be executed. Rename DO_MAINTENANCE to RUN_MAINTENANCE_IF_MAIN so it's nice and clear what magic happens behind the require_once().
