This is an unconditional and unconfigurable changes to PHP behaviour.
The earlier the better so that there is less code that can run
without it.
Also improve some documentation of other setup logic bits being
documented by the referenced task.
Bug: T189966
Change-Id: Ia8e1478cf0841d80b1c61c266f2ece75be2303e1
Following discussion in Ibb8175981092d7f41864e641cc3c118af70a5c76, this patch
proposes to further reduce the scope of what unit tests may access, by removing
the loading of DefaultSettings and GlobalFunctions.php. This also has the
implied effect of disabling the storage backend, as well as the global service
locator.
MediaWikiTestCase is renamed to MediaWikiIntegrationTestCase so it's scope and
purpose is more clear. Whether we still need to keep `@group Database`
annotation around is debatable, as it's unclear to me what the performance costs
are of implying database access for all tests which extend IntegrationTestCase.
As far as I can tell, `@group Database` is primarily used in CI to run faster
tests before slower ones, and with the new UnitTestCase the annotation seems
redundant.
To run all testsuites, use `composer phpunit`. Other composer scripts:
- `composer phpunit:unit` to run unit tests
- `composer phpunit:integration` to run integration tests
- `composer phpunit:coverage` to generate code coverage reports from unit
tests (requires XDebug).
Note that you can pass arguments to composer scripts with `--`, e.g. `composer
phpunit:integration --exclude-group Dump`.
Other changes:
- Rename bootstrap.php to bootstrap.maintenance.php so it's clear it's part of
the legacy PHPUnit-as-maintenance-class setup
- Create new bootstrap.php which loads the minimal configuration necessary for
the tests, and do additional setup in the run() method of the unit/integration
test case classes
- Move the unit-tests.xml file to phpunit.xml.dist in preparation for this being
the default test configuration
For a follow-up patch:
- Find unit/integration tests for extensions/skins
- Migrate other test suites from suite.xml
- Support running all tests via vendor/bin/phpunit
Bug: T84948
Bug: T89432
Bug: T87781
Change-Id: Ie717b0ecf4fcfd089d46248f14853c80b7ef4a76
Add some of the basic REST API class hierarchies:
* EntryPoint
* Router
* Request
* Response
* Handler
The actual entry point file rest.php has been moved to a separate
commit, so this is just an unused library and service.
Bug: T221177
Change-Id: Ifca6bcb8a304e8e8b7f52b79c607bdcebf805cd1
Currently, $wgSharedTables - if configured - is injected into the LoadBalancer
before the WAN cache autodetection runs. As such, if $wgSharedTables is set
but $wgMainWANCache was not explicitly given, the LoadBalancer will force
a premature instantion of the WAN cache with an EmptyBagOStuff backend,
preventing the autodetection logic from setting a correct backend.
This change moves $wgSharedTables initialization after the WAN cache
autodetection to accunt for this scenario.
Change-Id: I59bb52f42905cda1c2aa47bc589a2f0b36b2a28f
This is not used when the ID is already in "cpPosIndex".
Also, prefix the "ChronologyProtection" header with "MediaWiki-".
The header is currently usused but might be useful for services
in the future.
Bug: T212550
Change-Id: Ia871e95966d3550bac3dc4b2edb58e18359af7d9
* Remove 'channels' field references from config/setup
* Remove 'relayer'/'channels' field reference in unit tests
* Remove unused DEFAULT_PURGE_CHANNEL class constant
* Also remove long-since bogus 'pool' field references
Follow-up to 4753b0a4ed
Change-Id: If6670ff4e1dccc8ae253a08b46d205601da10024
Running Composer manually with a user different from the webserver
user and ending up with a vendor/autoload.php file that's unreadable
to MediaWiki seems like an easy mistake to make. Make the error
message when that happens less cryptic.
Change-Id: I52600adceb38a7fc5384d00b5298e46a782c684f
In PHP before 7.3, the double start doesn't really matter: session_id()
changes the ID even if it was already started, and the warning from
session_start() can just be ignored. Which is what we did.
In PHP 7.3, now session_id() also warns and no longer changes the ID. To
preserve the previous behavior, we'll need to explicitly close the old
session and open the new one.
Bug: T213489
Change-Id: I02a5be1c3adb326927c156fdd00663bccee37477
Using count() function in loops makes things very slow because
of function overheads and this function gets called everytime the
loop runs meaning the bigger the value of the variable in count(),
the slower the loop as its value always gets computed as the loop
runs.
In this case, the use of foreach(...){} is possible in order to
perform the computation making it pretty fast hence improving the
performance.
Change-Id: Ie21fbf8f6acf72373d1da75023725b4592c80386
Add BCP 47 codes to $wgDummyLanguageCodes to ensure that
Language::factory() will return a valid MediaWiki-internal code if
given a BCP 47 alias. We will want to make $wgDummyLanguageCodes a
private property of LanguageCode eventually, but let's start with
removing it from user configuration.
Setting $wgDummyLanguageCodes in LocalSettings.php has been deprecated
since 1.29. Hard deprecate adding entries to $wgDummyLanguageCodes so
that we can eventually remove manual overrides from user
configuration.
This is a follow-up to 48ab87d0a3,
which described the various categories of codes, and
21ead7a98d, which added the correct
BCP 47 mappings.
Bug: T207433
Change-Id: I9f6dda3360f79ab65f6392f44c98926588d851c8
Way back in r8196, a test was added to assert that Setup.php is being
included at file scope.[1] That test was broken when I633a6ff23 moved the
inclusion of DefaultSettings.php into Setup.php itself.
This fixes the test by having it directly set a variable and see if that
variable is a global. Yes, there's several ways to bypass it, but we're
just trying to avoid accidents here rather than trying to be foolproof.
[1]: Or really, in the same scope as DefaultSettings.php. But it
intended to be checking for file scope.
Change-Id: I9b5f15bf01c2903e8d44d85c54465d90c047cb51
The former is already a wrapper around ObjectCache::getInstance().
The latter was identical to ObjectCache::getLocalClusterInstance().
Bug: T115890
Change-Id: Ib4e43bc8d3f4ac9f7a453e36dcce9b3d962666ba
* Remove references to these old configuration variables
from documentation. Rather than wgLocalFileRepo referring to
these for more information, move the docs there, and point
there from the old variables.
* Move all their declarations in DefaultSettings.php together,
and be in the same order as used in Setup.php.
* Add missing @var type and @since version docs.
Bug: T25122
Change-Id: I4eb9490ed4e978b2c3954de0593a9d0d3c5fe73c
Previously, if an internal service forwarded the cookies for a
user (e.g. for permissions) but not the User-Agent header or not
the IP address (e.g. XFF), ChronologyProtector could timeout
waiting for a matching writeIndex to appear for the wrong key.
The cookie now tethers the client to the key that holds the
DB positions from their last state-changing request.
Bug: T194403
Bug: T190082
Change-Id: I84f2cbea82532d911cdfed14644008894498813a
This is controlled by a new config variable, $wgPageCreationLog,
which is set to false by default.
Bug: T12331
Change-Id: Ie3f6cc5ece0134433d5e4a572ea5eb0c3b700b8c
Since it takes time for the agent to get the response and set the
cookie and, as well, the time into a request that a LoadBalancer is
initialized varies by many seconds (cookies loaded from the start),
give the cookie a much lower TTL than the DB positions in the stash.
This avoids having to wait for a position with a given cpPosIndex
value, when the position already expired from the store, which is
a waste of time.
Also include the timestamp in "cpPosIndex" cookies to implement
logical expiration in case clients do not expire them correctly.
Bug: T194403
Bug: T190082
Change-Id: I97d8f108dec59c5ccead66432a097cda8ef4a178
* Remove left-over mention of the .php5 entry points in docs.
* Remove dead logic in NoLocalSettings for php5 entry points.
* Remove dead match in WebRequest for php5 entry points (they'd
redirect since 1.25, and not seen by PHP).
Change-Id: Ia0ee8588591860b8fe34030c8503f38e9bce31f3
Follows-up 26c2d03c17, 41d1fa1c3a and r11547 (c7f363f886).
Also add references to the relevant tasks about why the check
exists.
Bug: T189966
Change-Id: Ic1f0c79a1b5638bb30351a0cab55699931d1fded
$wgProfiler was introduced in 3ea576aa25 (r15605; 2006; MW 1.8).
The global was used from the Profiler.php class file, which
would be manually from StartProfiler.php, which then (if enabled)
assigned the global an actual instance of the Profiler class.
We needed it that way because we actually instantiated and used
the Profiler object (via wfProfileIn) very early on in WebStart.
Specifically, before any settings and classes load.
This first changed in 5a6d1ee2d3 (r86228; 2011; MW 1.17).
That commit deprecated use of $wgProfiler as an object in favour
of assigning it an array that MediaWiki would use to construct
the class. Profiling methods were also changed to lazy-instantiate
the class, which would first happen via a wfProfileIn() call two
lines before loading DefaultSettings and LocalSettings.
Some more relevant clean up happened in a0123d0549 (r89206; 2011).
Now, in 2018, we don't actually lazy-instantiate the Profiler
until after DefaultSetting and LocalSettings load. As such, I
think we can finally get rid of its out-of-bound load strategy.
Instead, we can simply set the default in DefaultSettings, and
recommend admins to set their value in LocalSettings.
Bug: T189966
Change-Id: I4e8dd9558132a5e38c22b26fed9c4b54cd324da7
* This is how it was before d5aa846d8, which accidentally changed
the behavior. The WAN cache call in Setup.php was too coupled to
the ChronologyProtector cookies. It made the assumption that DB
positions and cookies are stored even when there are no replica
databases setup (which changed in that patch).
* Check the "UseDC" cookie instead, which is already set in exactly
the cases this logic should apply.
Bug: T185328
Change-Id: I4dd2a6ca6cdead0052d59be86e6030dbe01f141b
This is step one in migration, 1.35 LTS should make it
[ 'html5', 'legacy' ].
Also issue deprecation warnings for $wgExperimentalHtmlIds.
Bug: T152540
Bug: T139744
Change-Id: I8780bb589002a4f836ba90bd18093a56cddc3ddf
This handles multi-DB transactions properly, instead of causing wait
timeouts in the WaitConditionLoop. It also is more correct in using
a counter instead of relying on wall clocks.
In addition:
* Refactor related code in MediaWiki.php to be comprehensible.
* Always send the cookie even the "remote wiki redirect" case.
* Renamed ChronologyProtector field and constant to avoid any
confusion of "wait for server X to reach Y" with "wait for Y
to show up in position store".
* Add an "asOfTime" field to the position keys for debugging.
Bug: T182322
Change-Id: I5c73cd07eaf664f02ba00c38fab9f49b609f4284
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
Also removed useless line from testLockTSE(). That would have needed
to be using $this->internalCache and those locks are freed immediately.
Bug: T180035
Change-Id: Ida1a923f779aaf8410da76643457d2200da6cb20
Setup.php was only injected the value from $_GET. LBFactory used
to check both before 0e5cd18b74, with the cookie check left
in LBFactoryMW. After d175b391ae, LBFactoryMW class switched to
the default LBFactory method for making a ChronologyProtector
instance, so the cookie check was lost there too.
This means that an HTTP GET request due to a redirect from a POST
request will still make sure the DB position store is up-to-date.
This only matters is that store uses replication (e.g. cross DC).
Also refactor LBFactory handling of the cpPosTime URL parameter.
Change-Id: Ie5744577609f4c193cacd71334f92b30f02e3846
