Just methods where adding "static" to the declaration was enough, I
didn't do anything with providers that used $this.
Initially by search and replace. There were many mistakes which I
found mostly by running the PHPStorm inspection which searches for
$this usage in a static method. Later I used the PHPStorm "make static"
action which avoids the more obvious mistakes.
Bug: T332865
Change-Id: I47ed6692945607dfa5c139d42edbd934fa4f3a36
Subclasses of Maintenance that can function without database access can
now override canExecuteWithoutLocalSettings to return true.
This is useful for scripts that need to be able to run before or without
installing MediaWiki.
When no config file is present, the storage backend will be disabled.
Any attempt to access the database will result in an error.
NOTE: This makes MediaWikiServices::disableBackendServices() more
comprehensive, to avoid premature failures during service
construction. This change makes it necessary to adjust how the
installer manages service overrides.
The CLI installer is covered by CI, I tested the web installer
manually.
Change-Id: Ie84010c80f32cbdfd34aff9dde1bfde1ed531793
Mocks a ContainerInterface to support a specific list of services,
with has() and get() working correctly, and uses that for a real
ObjectFactory object.
Change-Id: Ie49b5a34e0f449cc4b9f6b31d6cc1bc943d04b43
First step towards constraining how the targets system can be used
with the eventual goal of dismantling target system altogether.
As part of the many modernization efforts in place, we should
be targeting mobile experiences by default. For now I am
targeting only modules that are writing ES6 code for desktop
only. In future this should be expanded to modules using
packageFiles and modules targetting mobile only.
The implication of this change is that any ES6 module that has
not specified targets, will now automatically load on mobile site.
In the case of the 3 depends-on there doesn't seem to be any
problem with targeting mobile as the way these modules are
loaded is restricted based on context.
We will log warnings to inform us where modules disobey this
rule.
Bug: T323542
Depends-On: I2e31ba2bd2aea192f428531f6c92afa551448fef
Change-Id: Iff6bfbba406dec5b8c8be644dbf21ee3b3879fda
I consider it busywork to maintain this, for no tangible benefit.
Limiting the credited coverage to a class is limiting enough to
exclude unintended coverage from reports. Especially as this
helps ensure tracking coverage correctly for implementation details
such as helper methods and internal methods that do not warrant
their own test as that would defeat the purpose of tests exercising
the contract and demonstrating good usage.
Change-Id: Icf865f15cbd86585bbc02fc4943a960efb40c0eb
In a comment on I248f828f69d404d2bad8fe8c878e6204ca4b021e, Krinkle
says a module name should never be null for RL.
Change-Id: I1c03e3f47086a1cbe7175deb6aca1357735978dc
ResourceLoader's FilePath is designed to allow a FileModule
to include files that exist outside of the module's localBasePath,
to allow skins and extensions to extend core MediaWiki modules.
This is accomplished by having the FileModule use the FilePath's
localBasePath instead, in FileModule::getLocalPath.
(Similarly for remoteBasePath, but these are going out of fashion.)
However, the code processing 'packageFiles' did not handle this right:
it used FilePath's localBasePath when it appeared as a 'file',
but not when it was returned by a 'callback' or 'versionCallback',
using the FileModule's localBasePath instead in that case. Most
existing uses of FilePath in 'packageFiles' required the same base
path as the module, so it was convenient to avoid providing it twice.
To keep that convenience (already relied on by some extensions too)
while also allowing skins and extensions to add files from their own
directories to existing modules, the code processing 'packageFiles'
now uses FilePath's base paths in all cases, but they are optional,
and will fall back to the FileModule's paths when not provided.
Follow-up to 2890bca27d.
Change-Id: I38a0761ae4633a567b685b52c1d73b6ce280ffb7
The getConfig of a ContextSource should only be used, if the
ContextSource is available. Getting the global context just for the
config looks harder to fix/inject as using the MainConfig from
MediaWikiServices
Change-Id: Iaf14bfc7bd68cc315672e1c256887faf87e22542
Move ResourceLoader classes to their own namespace. Strip the
"ResourceLoader" prefix from all except ResourceLoader itself.
Move the tests by analogy.
I used a namespace alias "RL" in some callers since RL\Module is less
ambiguous at the call site than just "Module".
I did not address DependencyStore which continues to have a non-standard
location and namespace.
Revert of a241d83e0a.
Bug: T308718
Change-Id: Id08a220e1d6085e2b33f3f6c9d0e3935a4204659
This reverts commit e08ea8ccb9.
Reason for revert: Breaks Phan in extensions, and as far as I’m aware,
this change isn’t urgently needed for anything, so the simplest fix is
to revert it again for now. After PHP 7.4 it should be safer to try this
again (we hopefully won’t need the two “hack” classes by then).
Bug: T308443
Change-Id: Iff3318cbf97a67f821f78e60da62a583f63e389e
Move ResourceLoader classes to their own namespace. Strip the
"ResourceLoader" prefix from all except ResourceLoader and
ResourceLoaderContext.
Move the tests by analogy.
I used a namespace alias "RL" in some callers since RL\Module is less
ambiguous at the call site than just "Module".
I did not address DependencyStore which continues to have a non-standard
location and namespace.
Change-Id: I92998ae6a82e0b935c13e02a183e7c324fa410a3
2022-05-16 14:41:27 +10:00
Renamed from tests/phpunit/includes/resourceloader/ResourceLoaderFileModuleTest.php (Browse further)
