Instead of checking if the resulting $matches array is complete, we can
safely assume it is, as long as the preg_match() call returned a
non-false value.
Note that some of these used empty() before and are actually bogus
because of this! empty() considers the string "0" to be empty. In case
of a ==0== headline that's an actual bug.
I'm also removing the `= []` initialization before the preg_match.
I understand why it was added: to make it a little more obvious that the
variable is guaranteed to be initialized. But:
* This is guaranteed by the preg_match anyway.
* Neither initializing it with null or an empty array makes much sense
because the code below assumes so much more, e.g. that specific
elements exist, and are arrays. Again, these guarantees are all given
by the preg_match.
I find the additional initialization more distracting than helpful.
Change-Id: I22b192b59038d9fa51a7e6f04d8d76634ae3de73
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
And include tests :)
This code is independent of MediaWiki, but not really large enough to be
worth librarizing right now.
Bug: T200626
Change-Id: I022c074e8a708fb5219bc4ff4b53e7e31f60dc4b
For consistency with other data files. Also, like the other data files:
* For automated fetching of the Unicode files,
move the steps from Makefile to a bash script.
* Switch to a static array file format.
Change-Id: If07487950a270283b8eaeda9a507e723ed2d89c4
Deprecated in 1.25, last vestiges have been removed.
Inline one last function that's not supposed to be public anyway.
Change-Id: If44c6a9cce7d2d95dc63e6f135b73b8c969f1c07
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
This drops support for the custom utf8 normal PHP extension in favor
of the intl extension.
Bug: T90825
Change-Id: Ifbaeb2ef684217cf6187ccc4fb4d303f89608300
0X is a legal hex prefix, but tools like pfff and my syntax highlighter
prefer the more common 0x.
Change-Id: I38bba068f9a97566b0df9fb0a2fe72d25519a21b
- Added/removed spaces around parenthesis
- Added space after switch/if/foreach
- changed else if to elseif
Change-Id: I99cda543e0e077320091addd75c188cb6e3a42c2
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
And added/removed spaces around some other tokens,
like +, -, *, /, <, >, =, !
Fixed windows newline style
Change-Id: I0b9c8c408f3f6bfc0d685a074d7ec468fb848fc8
It will be necessary to be able to use correct version of Unicode
data files.
The constant INTL_ICU_VERSION this getter returns isn't really
documented. It is available since PHP 5.3.7 (see PHP bug 54561),
the getter will fail gracefully on older PHPs. It should be possible to
determine the ICU version on these by grepping the output of phpinfo(),
but I don't think such a minor improvement is worth such a huge hack.
Change-Id: I85353559439bfddee7c5ba90894d30dd8ef0e0e8
Variables in classes should be declared using public $foo
instead of var $foo for various reasons. As we require PHP 5.3
we don't have to take care about that PHP4 left over, but can
get rid of it in favour of the more clear and better readable
public.
See also: http://php.net/manual/en/language.oop5.visibility.php
(Divided into several commits to keep reviewable)
Change-Id: Ic723d0347ab2e3c78bc0097345c68bbee3dc035a
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
* Added a maintenance script which generates a list of first letters. Unified Han are omitted for performance, and because they shouldn't be used as headings anyway. A future collation specific to Chinese would provide the KangXi radicals as "first letters".
* Provided a precomputed list of first letters. Used Unicode 6.0.0 data and ICU 4.2.
* Moved collation functionality from Language to a Collation class hierarchy with factory function. Removed the recently-added methods from Language and updated all callers.
* Changed Title::getCategorySortkey() to separate its parts with a line break instead of a null character. All collations supported by the intl extension ignore the null character, i.e. "ab" == "a\0b". It would have required a lot of hacking to make it work.
* Fixed the uppercase collation to handle non-ASCII characters, redundantly with r80436. I don't think it's necessary to change the collation name as was done there, so I reverted that in the course of my conflict merge. A --force option to updateCollation.php might be nice though.
