* 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 $lang and $site placeholder variables don't just work on
strings assigned to wg-globals, they also work on strings within
arrays.
Add a test for this because it turns out this part is the slowest
part of the entire extraction process despite the fact that of the
thousands of variables, only a handful use these placeholders,
and even fewer use them within an array.
Bug: T169821
Change-Id: I1706a95764aa7d0ebfa627fb353fa496ccda5eee
This changeset resumes work on T89432 and related tickets
by porting an initial set of tests to the new unit test suite
separated out in I69b92db3e70093570e05cc0a64c7780a278b321a.
The tests were only ported if they worked immediately without
requiring any changes other than changing the test case class
to MediaWikiUnitTestCase and moving the test to the new suite.
If a test failed for any reason (even trivial misconfiguration),
it was NOT ported.
With this change, the unit tests suite now consits of a total
of 455 tests. As before, you can run these tests via the following
command:
$ composer phpunit:unit
Bug: T84948
Bug: T89432
Bug: T87781
Change-Id: Ibb8175981092d7f41864e641cc3c118af70a5c76
This changeset implements T89432 and related tickets and is based on exploration
done at the Prague Hackathon. The goal is to identify tests in MediaWiki core
that can be run without having to install & configure MediaWiki and its dependencies,
and provide a way to execute these tests via the standard phpunit entry point,
allowing for faster development and integration with existing tooling like IDEs.
The initial set of tests that met these criteria were identified using the work Amir did in
I88822667693d9e00ac3d4639c87bc24e5083e5e8. These tests were then moved into a new subdirectory
under phpunit/ and organized into a separate test suite. The environment for this suite
is set up via a PHPUnit bootstrap file without a custom entry point.
You can execute these tests by running:
$ vendor/bin/phpunit -d memory_limit=512M -c tests/phpunit/unit-tests.xml
Bug: T89432
Bug: T87781
Bug: T84948
Change-Id: Iad01033a0548afd4d2a6f2c1ef6fcc9debf72c0d
2019-06-13 22:56:31 +02:00
Renamed from tests/phpunit/includes/SiteConfigurationTest.php (Browse further)
