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().
