array_fill_keys() was introduced in PHP 5.2.0 and works like
array_flip() except that it does only one thing (copying keys) instead
of two things (copying keys and values). That makes it faster and more
obvious.
When array_flip() calls were paired, I left them as is, because that
pattern is too cute. I couldn't kill something so cute.
Sometimes it was hard to figure out whether the values in array_flip()
result were used. That's the point of this change. If you use
array_fill_keys(), the intention is obvious.
Change-Id: If8d340a8bc816a15afec37e64f00106ae45e10ed
This is most likely a micro-optimisation from a time where MW
still ran mainly on PHP 4, during which copy-on-write wasn't as
well implemented (or not as well understood).
Nowadays, this actually makes the method slower, and also makes
the internals hard to reason about due to the side effects a
downstream mutation could cause.
Remove this undocumented feature, and also make the method
explicitly public.
Bug: T169821
Change-Id: I1887021282bbc4ab619a46e80a8c54bf1fc794ab
Deprecated since 1.25 and not used anywhere in Codesearch.
Interestingly, this probably didn't need to go through deprecation
as the ability to set and get members on a foreign object the class
itself doesn't use, is available on all PHP objects by default.
Change-Id: If2230d1806e5540b616cd28d993ab473c0036d05
* Remove the outer loop and with that, the (unused) variadic
arguments feature. It is only ever called with exactly two arrays.
* Make it private.
* Refactor the loop body to not evaluate the same conditions
multiple times.
* Document what this thing does and doesn't do.
In particular, the fact that its "merge by appending" behaviour
kicks in based on key conflicts, not just based on keys being
numerical. This means numerical keys are generally preserved,
which is quite important for namespace-related settings.
* Also two minor changes I forgot to commit as part of 268759c154:
- Remove the obsolete null check at the end of processSetting(),
the doReplace() function already checks for string and arrays,
which means it can't be null anyhow.
- Inline it because it's only a few lines of code and used in
one place.
Bug: T169821
Change-Id: I2b90e8e9b0a38c0ac3d4b3d480923c3279b781cc
* getSetting() was retreiving the overrides array from $this->settings
by settingName. But, the getAll() caller already had this array
locally available from its foreach loop as "$stuff" which was
previously unused.
The protected getSetting() was renamed to processSetting(),
and now takes this array directly.
* Remove the code duplication in processSetting() for handling
of 'tags' and handling of 'suffix'. Instead, treat the 'suffix'
as an extra tag internally, which is exactly how it was behaving
already. This happens in mergeParmas(), which now documents this
feature and what it means practically.
This means for WMF that it can remove the duplication between
$wgConf->suffices and wikifamily dblist files. These are redundant
given the suffix for those wikis is identical to the tag name.
This will save about a dozen dblist file reads in production,
once we utilize this decade-old feature.
* Rewrite the internal do-while in processSetting() in a more
procedural fashion. The only reason it used do-while was to
perform an "early return" from the given block in two places.
One was rewritten with a simple if/else that devides before/after,
and the other was rewritten by explicitly tracking the action it
wanted to skip (which is: applying of 'default' value').
* Document this scary code, including the various anti-features
I found along the way (such as 'default' overridding '+wiki').
No changes in behaviour for now.
Bug: T169821
Bug: T246858
Bug: T246213
Change-Id: I723133e6814a5d15c3b0b9e785921505ec7b9a69
The runtime numbers in each bullet point are based on a local
benchmark that use a copy of WMF's InitialiseSettings.php file
to compute enwiki's $globals via SiteConfiguration::getAll().
Source code and results can be found at
<https://gist.github.com/Krinkle/2ef2fe72218b5f5cea91679df56a0b18>.
* The getSetting() method (called by getAll) was iterating over
each find/replace pair and performing a separate call to str_replace()
via doReplace().
Instead, iterate the pairs only to create a replacements array
(this array differs from the pairs in that it has a leading "$" in the
search keys), and then call doReplace() once for each setting value,
instead of multiple times.
Also, switch from str_replace() to strtr() while at it (which promises
to only search the string once, instead of repeatedly until it no
longer finds any of the search patterns).
Also also, generate the replacements array outside the getSetting()
method and do this in the mergeParams() method instead, which is called
before the getSetting-loop in getArray begins, thus further reducing
identically repeated work.
In my local benchmark for WMF/enwiki this reduced runtime from
~7.5-8.1ms to ~6.9-7.3ms.
* The getSetting() method was using a by-reference assignment
for a local variable that would hold a read-only copy a class member
`$thisSetting =& $this->settings[$settingName];`.
This was presumably a PHP4 or PHP5 era optimisation to avoid
an eager memory copy given the promise to only read the data.
However, in PHP5/PHP7 this is redundant given that PHP
does copy-on-write.
Removing the "&" symbol here made a drastic perf improvement,
reducing my WMF/enwiki benchmark runtime from ~6ms to ~1ms.
Bug: T169821
Change-Id: I0e8b395920c143f2b42f9d87c1afaffa2bfdaf2e
In all these cases, the foreach() loop specifies a variable for the
current value. We don't need two ways to access the same value. This
makes the code harder to read.
Change-Id: I6ed7a518439963b7091057194de993a7e977be32
HHVM does not support variadic arguments with type hints. This is
mostly not a big problem, because we can just drop the type hint, but
for some reason PHPUnit adds a type hint of "array" when it creates
mocks, so a class with a variadic method can't be mocked (at least in
some cases). As such, I left alone all the classes that seem like
someone might like to mock them, like Title and User. If anyone wants
to mock them in the future, they'll have to switch back to
func_get_args(). Some of the changes are definitely safe, like
functions and test classes.
In most cases, func_get_args() (and/or func_get_arg(), func_num_args() )
were only present because the code was written before we required PHP
5.6, and writing them as variadic functions is strictly superior. In
some cases I left them alone, aside from HHVM compatibility:
* Forwarding all arguments to another function. It's useful to keep
func_get_args() here where we want to keep the list of expected
arguments and their meanings in the function signature line for
documentation purposes, but don't want to copy-paste a long line of
argument names.
* Handling deprecated calling conventions.
* One or two miscellaneous cases where we're basically using the
arguments individually but want to use them as an array as well for
some reason.
Change-Id: I066ec95a7beb7c0665146195a08e7cce1222c788
Note there is an important difference between the two ways to express
this: strlen() does a string cast, but the `=== ''` and `!== ''`
comparisons will only detect empty strings, but not null, false, or any
other falsy value that becomes an empty string when cast to be one.
I am only touching code where I'm sure the variable is guaranteed to be
a string.
This change is done because I find the strict comparisons much more
readable. The code does exactly one thing now, and no magic casts any
more.
Change-Id: I3e908a0c7c7b6c29b0e5a1414f2ba9062a215b93
Using domains means thats JobQueueDB has the right value to use for calls
like LoadBalancer::getConnection(). The full domain includes the schema in
the case of Postgres. This makes calls to getConnection() less awkward by
not relying on the fallback logic in reallyOpenConnection() for null schemas.
Make getWikiIdFromDomain/isCurrentWikiDomain account for the schema if it
is both defined and is not simply the generic "mediawiki" schema MediaWiki
uses by default. If all wikis use the default schema, the wiki IDs can get
by with DB/prefix alone, which various config and methods may be built around.
Otherwise, the config callbacks must account for schema and the config must
include it in various wiki domain ID lists to properly disambiguate wikis.
Also, clean up SiteConfiguration::siteFromDB() since it is not meant
to handle schemas unless the callback method was taylored to do so.
Finally, add more comments to DefaultSettings.php about already existing
limitations of wiki domain IDs and their components.
Change-Id: I8d94a650e5c99a19ee50551c5be9544318eb05b1
Use these in place of various wfWikiID() calls.
Also cleanup UserRightsProxy wiki ID variable names and removed unused
and poorly named getDBname() method.
Change-Id: Ib28889663989382d845511f8d34712b08317f60e
Starting HHVM may require writing very large files, so it can't have the
same file size limit as image scaling etc. The memory limit was already
disabled for much the same reason.
This is the only caller of wfShellWikiCmd() in core which proceeds to
call wfShellExec().
Bug: T145819
Change-Id: I1ab35edbbdb63c2d6f5f578cba2547be79a965ef
Most of these are simply changing annotations to reflect
reality. If a function can return false to indicate failure
the @return should indicate it.
Some are fixing preg_match calls, preg match returns 1, 0 or false,
but the functions all claim to return booleans.
This is far from all the incorrect return types in mediawiki, there
are around 250 detected by phan, but have to start somewhere.
Change-Id: I1bbdfee6190747bde460f8a7084212ccafe169ef
If we don't have a valid canonical server and path to pass, there's no
point in returning a WikiReference that will fail in strange and unusal
ways.
This also documents that $wgServer/$wgCanonicalServer and $wgArticlePath
are required in SiteConfiguration.
Change-Id: Ib08011e9f1d0817a5d1bb165aba6b424785eaa6a
The former is independent of the remaining of the SiteConfiguration
class, and as thus makes more sense to be defined as an explicit
configuration setting rather that being hidden in $wgConf.
Change-Id: I25204d37c5cfffb6953fe53e14316dc3df5b5b10
Now that we require PHP 5.1 (for quite some time actually)
we can force method parameters to be array.
Change-Id: Ia4a262320344e05cc1625c041a3aa4ec41034ad7
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Also added some missing @param.
Change-Id: I0056b4a8df243cfc0c5f25378de48f7a35170aca
Added spaces after/before parenthesis
Removed unneeded parenthesis around some statements
Broke a long line
Change-Id: I7fbe129f7bbf524dd0598ece2a9708643f08453b
* Removed spaces around array index
* Removed double spaces or added spaces to begin or end of function
calls, method signature, conditions or foreachs
* Added braces to one-line ifs
* Changed multi line conditions to one line conditions
* Realigned some arrays
Change-Id: Ia04d2a99d663b07101013c2d53b3b2e872fd9cc3
Doxygen expects parameter types to come before the
parameter name in @param tags. Used a quick regex
to switch everything around where possible. This
only fixes cases where a primitve variable (or a
primitive followed by other types) is the variable
type. Other cases will need to be fixed manually.
Change-Id: Ic59fd20856eb0489d70f3469a56ebce0efb3db13
* getQueueTypes() now gets the config of the target wiki.
Previously, for WMF, if an extension using jobs was not
on aawiki, those job queues would not be seen by nextJobDB.
* Also fixed nextJobDB.php so that it no longer only considers
jobs types known to aawiki for picking a DB for default jobs.
* Note that $wgJobTypesExcludedFromDefaultQueue should be global.
* This adds a SiteConfiguration::getConfig() function, which calls
a new getConfiguration.php script.
Change-Id: I7e6904ead17efa407291f423a2b18e3c866d55fd
Also made file/class documentation more consistent and removed a duplicate comment from SpecialPageFactory.php in SpecialPage.php.
Change-Id: I99dd2de7fe461f2fad4e0bd315ebc2899958a90f