In MediaWiki 1.41.0 the function WebRequest::detectServer() started to generate server URL strings containing default ports such as 80
for http and 443 for https.
Before 1.41.0: https://my.wiki
After 1.41.0: https://my.wiki:443
detectServer() uses IPUtils::combineHostAndPort() to build the URL. The
latter function has actually a mechanism built in that intends to omit
standard ports, so the new behavior in MW 1.41.0 seems unintended.
As this broke WDQS over here in our Wikibase Suite bundle, I
investigated the cause.
MediaWiki 1.41.0 updates IPUtils from 4 to 5. With this update, there
was a change that compares the port now via === instead of ==.
(e68cf6a14e%5E%21/#F1
Line 383) The new behavior is correct, as the function expects an int.
MediaWiki passes in a string though. This bug was hidden with IPUtils 4,
but is triggered now in IPUtils 5.
I think this should be backported to REL1_41.
Change-Id: Ib707ee72e02cf99225168d268d5fedab3f548ead
Bug: T360608
1) Introduce EntryPointEnvironment which wraps functions that interact
with the PHP runtime, so they can be mocked for testing.
2) Allow server info fields to be overwritten in FauxRequest.
3) Make MediaWikiEntryPoint use WebResponse to set headers
Bug: T354216
Change-Id: Ic21950c956de5d2b5a7dd66a1e2de58f807cfd9f
WebRequest::getFuzzyBool() will emit a deprecation warning on PHP 8.1 or
newer if the parameter to be fetched is absent and the $default value is
set to `true`, because strcasecmp() no longer accepts nulls. Fix it by
returning out if the parameter is wholly absent and add a test for this
scenario.
Bug: T351088
Change-Id: I85bbfec6aabef4e85859a76b6e50c80781024ae5
