Leave class aliases behind because they might be being used somewhere,
but we don't normally flag these kinds of things in the release notes,
do we?
Bug: T357823
Change-Id: I7fc7f34494d5c4df81f6746d63df1d0f990f8ae9
… or with $this->fail() from the PHPUnit TestCase base class.
I hope this makes the code more readable, i.e. communicate the
intention better. The output should be the same, i.e. the test fails
as before in case of an error.
Change-Id: Ied8a045141ac92d6af6398682bb5d9ca7ca88c49
* Have FileModule::getScript() always return an array with a filePath
or fakeFilePath, not a string. This allows source maps to be
constructed.
* Make the scripts returned from Module::buildContent() always be an
array. Module::getScript() may still return a string for b/c.
* In makeLoaderImplementScript(), interpret the new plainScripts array.
Factor out the package file normalization loop from
makeLoaderImplementScript().
* Fix missing base path in mediawiki.base.
* Improve relevant doc comments.
Bug: T47514
Change-Id: I392a8cce9a0febc707b6cb17412e3b723c9cc686
It's awkward to construct a source map when the file contents is
modified after loading. Delivering deprecation warnings as JS code
seems like an odd convention anyway.
So, send the module deprecation warning as an additional parameter to
mediawiki.loader.implement().
Deprecation warnings are no longer displayed in only=scripts mode.
Remove deprecation tests from FileModuleTest since FileModule no longer
has any relevant deprecation code. Add tests to ModuleTest.
Deprecate Module::getDeprecationInformation().
Bug: T47514
Change-Id: I20938cf4ab78afc9a2d72fbd163a7c5f21755820
To implement source maps, we want FileModule::getScript() to return
an array with path information, but that would break subclasses of
FileModule which concatenate to the return value of parent::getScript().
So allow scripts to be generated by a callback, eliminating the need for
concatenation in subclasses.
* Factor out most of the loop body of expandPackageFiles() into
expandFileInfo(). Add 'name' to the return value. Ensure 'filePath'
is always a FilePath object since we need that to safely return it
to ResourceLoader later. Document the return value.
* Make sure the base path is always set in FilePath objects returned by
expandFileInfo().
* Factor out the loop body of the final stage of file info expansion
into readFileInfo(). Retain filePath, do not unset it.
* Assert that $fileInfo['content'] is definitely set.
* Convert array_map() in getDefinitionSummary() to a loop.
* Migrate LanguageDataModule.
Bug: T47514
Change-Id: I97d61b5793159cea365740e0563f7b733e0f16de
The UA sniffs that overrode the feature tests are no longer needed.
* MSIE 10: Fine, rejected by feature checks.
* UC Mini "Speed Mode": Redundant, the version that this sniff
matched is pre-ES6. Current versions of UC Mini don't appear to
support enabling "Speed Mode" on random websites nor does it offer
it for Wikipedia specifically.
Details at https://phabricator.wikimedia.org/T178356#8740573.
* Google Web Light: Redundant, shutdown as of 2022.
Any references or extensions that still reach the proxy, get
redirected to our online URLs
https://googleweblight.com/?lite_url=https://en.m.wikipedia.org/wiki/Bananahttps://phabricator.wikimedia.org/T152602https://en.wikipedia.org/wiki/Google_Web_Light
* MeeGo: Redundant, discontinued and presumed rejected.
Either way, unsupported.
* Opera Mini: Fine, rejected by checks.
Details at https://phabricator.wikimedia.org/T178356#8740573.
* Ovi Browser: Redundant, discontinued and presumed rejected.
Either way, unsupported.
* Google Glass: Improve UX (since 2013, T58008).
* NetFront: Redundant. Old versions are presumed rejected.
Current versions are Chromium-based and presumed fine.
The exclusion was not UX based, but due to jQuery explicitly not
supporting it in 2013. This is no longer the case, so we can let
the feature test lead the way here.
* PlayStation: Redundant, same story as NetFront.
The version that matched the sniff is presumed rejected.
Current versions probably fine, but even not, don't match
our sniff so are already enabled today.
Bug: T178356
Change-Id: Ib6263ce3ffd11af5e501de8857f3e48a248c6210
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)
