All the other ways of doing it were ridiculous and much harder to read,
and usually required repeating the needle expression (to get its
length). I found these occurrences by grepping for various expressions,
but I undoubtedly missed some.
I didn't try replacing the many instances of strpos(...) === 0 with
str_starts_with(...), because I think they're readable enough as-is
(although less efficient). Likewise I didn't try porting strpos(...) !==
false to str_contains(...). For case-insensitive comparisons, Tim
Starling requested that we stick with substr_compare() because it's more
efficient than calling strtolower().
On PHP < 8 these functions will be included with a polyfill via
vendor/autoload.php. This is included at the beginning of
includes/AutoLoader.php, so if our autoloader has been included the
polyfill will be available. This means it should be safe to call these
functions from any code that would not be usable without our autoloader.
Three uses that Tim Starling identified as being performance-sensitive
have been split out to a separate commit for porting after the switch to
PHP 8.
Change-Id: I113a8d052b6845852c15969a2f0e6fbbe3e9f8d9
Part 1, proof of concept. Hundreds of files left to go. These changes
brought to you in large part by vim macros.
Bug: T305805
Change-Id: I44789091e9f6394c800a11b29f22528c8dcacf71
MediaWiki still supports PHP 7.2+, but we want to mainly test in newer versions
of PHP. Setting minimum_target_php_version to 7.2 this lets us run phan without
phan trying to get us to make PHP 7.2-incompatible changes to 'appease' PHP 8.0
or whatever later changes.
Some switches of generic 'resource' type-hinting to 'resource|object' to inform
phan to ignore this (triggering PHPCS at the time, ah well), rather than trying
to hint the specific novel PHP encapsulation classes to that have replaced them
from PHP 8.0 onwards but don't yet exist, and fixes from where we were checking
the results of implode and explode.
Bug: T293924
Change-Id: I629e3fb3adfad73beb3d424a07e643c2e079d9bb
Make phan stricter about scalar types by setting scalar_implicit_cast to
false (the default in mediawiki-phan-config)
Bug: T242536
Bug: T301991
Change-Id: Ia2fe30b17804186571722e728578121c8b75d455
Url query parameter sometimes contains integer,
which are not allowed on string[], just use array instead.
Found by phan strict checks
Change-Id: I7eabe69ee7a78ffee05413a022caec940672ae9f
This was originally added in changes linked to T77093 without
coordination with maintainers and took various shortcuts and lacked
proper integration.
* Rather than reading a global variable from LocalRepo::getInfo,
inject this option from Setup.php, the same as for other local
settings.
* Apply the wfExpandUrl() call in the base class getInfo() method.
This is done so that $wgForeignFileRepos and $wgLocalFileRepo
settings via LocalSettings.php or wmf-config get the same treatment
and benefit (support for paths) as $wgFavicon, which one would
generally expect.
Other reasons to do this at run-time are 1) We can't safely call
wfExpandUrl() during Setup.php as it is too early, and 2) We generally
avoid doing computational work during Setup.php given it's not
needed for most web requests to most entry points (T189966, etc.).
* Document the option in DefaultSettings.php.
* Fix bad doc in FileRepo.php, to reflect that it is optional
and may be null.
* Remove now-redundant hack in ForeignDBRepo::getInfo,
which had to jump over its parent class previously to avoid
inheriting the other hack in LocalRepo::getInfo, which is now
gone as well.
Bug: T77093
Change-Id: I9102b5a246ff81a3435748a3fd1c759a4b884a51
- Use DeletePage in FileDeleteForm instead of
WikiPage::doDeleteArticleReal
- Properly handle scheduled deletions in FileDeleteForm: previously, a
null status value could indicate a missing page OR a scheduled
deletion, but the code always assumed the first, and it would generate
a duplicated log entry. The API response would also not contain the
"delete-scheduled" message. This has been broken since the introduction
of scheduled deletion.
- In ApiDelete, for file deletions, check whether the status is OK not
good. The two might be equivalent, but this way it's more consistent.
- Add some documentation for the Status objects returned by file-related
methods. This is still incomplete, as there are many methods using
Status and none of them says what the status could be. In particular,
this means that for now we keep checking whether the status is OK
instead of good, even though it's unclear what could produce a
non-fatal error.
- In LocalFileDeleteBatch, avoid using a class property for the returned
status, as that's hard to follow. Instead, use a local variable and
pass it around when needed.
Bug: T288758
Change-Id: I22d60c05bdd4a3ea531e63dbb9e49efc36935137
This helps phan to detect unreachable code and also impossible types
after the functions.
It helps phan to avoid false positives for array keys
when the keys are checked before
Bug: T240141
Change-Id: I895f70e82b3053a46cd44135b15437e6f82a07b2
SpecialUploadStash would check $wgUploadStashScalerBaseUrl to see if
remote scaling is enabled, but would then throw the value away and use
thumbProxyUrl instead. So:
* Refactor SpecialUploadStash so that thumbProxyUrl is checked first.
* Soft-deprecate $wgUploadStashScalerBaseUrl.
* Don't use thumbProxySecret in the $wgUploadStashScalerBaseUrl case
* Document thumbProxyUrl and thumbProxySecret in DefaultSettings.php
* Add disableLocalTransform, which enforces this configuration and
ensures nothing else tries to do local scaling.
Bug: T260504
Change-Id: I111c01ae7e07ac7a943a32192c867ce9754b690a
Deconstructing non-sparse, numerically indexed arrays directly in
foreach (a.k.a. using the list() syntax in foreach) is possible since
PHP 5.5.
The possibility to use string array keys as well as non-sequential
numeric keys in array deconstruction was added in PHP 7.1.
Change-Id: I56a48552a45f61cedc291b306cad8548fc70d485
This includes fixing some mistakes, as well as removing
redundant text that doesn't add new information, either because
it literally repeats what the code already says, or is actually
duplicated.
Change-Id: I3a8dd8ce57192deda8916cc444c87d7ab1a36515
Add a fallback to RequestContext::getMain()->getUser()
in FileRepo::findFiles, per task
Bug: T263033
Change-Id: I57b49a8e33af4f69ce2b9e464dc39b4099cfe4fd
Depends-On: Iedde4a39dcc3192616e36a45690a0619efeb7309
The ArchivedFile::userCan and OldLocalFile::userCan() methods, along
with a number of other methods where the user parameter was optional,
were deprecated in 1.35, but this case was overlooked. This patch is
intended for backport to 1.35, so that the $user parameter can be
removed in 1.36 in accordance with the deprecation policy.
This path is known to be used by LocalRepo::findFile(),
FileRepo::findFile(), and FileRepo::findFileFromKey(), so hacky
workarounds have been added in this patch to avoid triggering
deprecation warnings in 1.35. T263033 has been filed to fix these
'correctly' in 1.36.
Bug: T263014
Change-Id: I17cab8ce043a5965aeab089392068b91c686025e
This patch replaces all usages of @protected in core.
The @protected tag was removed in cases where it was redundant or
contradictory. It has been replaced by @internal where usage outside of
core is not desired, and with @note for cases where use by extensions
is desired, but should be limited.
Bug: T247862
Change-Id: I5da208e5cb4504dde4113afb3a44922fd01325a3
A terminating line break has not been required in wfDebug() since 2014,
however no migration was done. Some of these line breaks found their way
into LoggerInterface::debug() calls, where they mess up the formatting
of the debug log.
So, remove terminating line breaks from wfDebug() and
LoggerInterface::debug() calls.
Also:
* Fix the stripping of leading line breaks from the log header emitted
by Setup.php. This feature, accidentally broken in 2014, allows
requests to be distinguished in the log file.
* Avoid using the global variable $self.
* Move the logging of the client IP back to Setup.php. It was moved to
WebRequest in the hopes that it would not always be needed, however
$wgRequest->getIP() is now called unconditionally a few lines up in
Setup.php. This means that it is put in its proper place after the
"start request" message.
* Wrap the log header code in a closure so that variables like $name do
not leak into global scope.
* In Linker.php, remove a few instances of an unnecessary second
parameter to wfDebug().
Change-Id: I96651d3044a95b9d210b51cb8368edc76bebbb9e
Functions references as callbacks are passed outside the class
Bug: T253922
Change-Id: I301283aeb814b558d338e600390b8af5679d7f70
Follows-Up: I44cd7ba39a898a27f0f66cf34238ab95370d2279
* Move 'hashLevels' docs from $wgHashedUploadDirectory to $wgLocalFileRepo.
* Add docs for the 'deletedHashLevels' option.
* Cross-reference between LocalRepo constructor and $wgLocalFileRepo
so that its option docs can be more easily found.
* Remove the TODO for deprecating 'hashLevels' per T199590.
Change-Id: I19c28fd0c2fb937608963fe0643607b07af69c70
The FileRepo, FileBackend, and JobQueue classes include documentation
files that don’t appear in the generated Doxygen docs. This PR:
* Converts these files to Markdown
* Links to each file from the respective class description
* Adds an ingroup tag so the files appear in the sidebar at the
module level
* Updates the exclude pattern in the Doxyfile to surface these pages
Bug: T87796
Change-Id: I94f0636ab489d741ab505f15da43a5d63c1ca61a
The only use-case for this was if the local wiki's File namespace didn't
allow initial-lowercase names but a remote repo did. This case is
unlikely to be useful and was broken anyway, so it's now prohibited, and
getUserCaseDBKey is no longer needed. It's now an alias for getDBkey
until we remove it.
This includes a breaking change to
MediaWikiTitleCodec::splitTitleString, but that was always intended as
an internal method and I have now marked it officially as such. There is
one caller in code search outside core (JsonConfig), but it looks like
it will be unaffected.
Bug: T202094
Depends-On: I4b8ceb8a7f4624d6a3763aca6df41bf1a0d7293f
Depends-On: I724be15e93421f874fb202f0ec2ca6940e56a20a
Change-Id: I4fd64d4b0036b6dabdcfeee18766df18bf538542