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