Allow extensions with very special modules that can't be called in a
testing environment to skip ResourcesTest::testRespond().
Needed by If1186797fd047d4f for ext.wikisource.OCR.
Change-Id: Id02915d9633c2d8209d2ff2e60f6748095ec10fe
Ironically, our replacements to improve readability of Vue templates in
debug mode actually ended up eating newlines in the string that is sent
to the Vue template compiler. This caused bugs when inline comments were
used in multi-line JS expressions in templates.
Bug: T351771
Change-Id: I6b3ad5736a836ba75f57a49fd9b7ca2e237074c0
* 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
Follows-up Ib4caa80bb700, which introduced MW_INSTALL_PATH as
alternative to $IP, but also introduced $wgBaseDirectory.
Its not clear to me whether we actually want/need $wgBaseDirectory
long-term as it introduces significant complexity for a distinction
that remains theoretical, not enforced, and lacking a use case.
But, at least here we don't need it as these all explicitly reference
files that are in the source tree. Mocking the path differently would
fail the tests.
There are some individual methods (OutputPage, used via SkinModule)
that do not make assumptions on file paths and work with any file
paths at runtime. Those indeed need $wgBaseDirectory for DI and
testability.
Change-Id: I56c28d36e2d7bbf7ec5a8f2f5ae99b291e7ee4e8
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
Otherwise content ends up being null, and a less specific exception is
thrown.
Depends-On: Id951da0d4ffa31f4593b2396c806dd6081670d36
Change-Id: Ic2ccd76df70ffba0ed25100925db3dd3086c5e8c
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
In Ia062ff2d8b8732b0d3498c1a614bbf6a3e3a7ddb, we changed the default
targets to desktop/mobile. This broke CI for PageTriage, which has a RL
module that extends ResourceLoader\Module, and which sets the default
targets for "desktop" only.
I am not sure if leaving ResourceLoader\Module as "desktop" only was a
deliberate choice or an oversight, but it seems to be more consistent to
have it defined as desktop/mobile. This will fix the issue for
PageTriage and other extensions that extend ResourceLoader\Module and
don't have any targets explicitly defined for their RL modules.
Follows-Up: Ia062ff2d8b8732b0d3498c1a614bbf6a3e3a7ddb
Bug: T127268
Bug: T328497
Change-Id: I48ed19912610a74af66d620510c192c7ba87039a
If not specified, going forward all modules which do not define
targets should be assumed to be mobile AND desktop. I think this is
a fair expectation given that most new features should be built with
mobile in mind. This also avoids the issue where features are
unexpectedly not shipped to mobile.
The work in T324723 has ensured that all modules that need to remain
desktop only have been marked as such. After the audit, we can be
reasonably confident that enabling the remaining modules is okay,
given these modules run in isolated parts of the UI (not on every page
view).
I'm assuming CI is catching all offenders here. If not, any impacted
modules would require a trivial update to explicitly define modules
as mobile only. This would allow us to see clearly which modules
are depending on the target system and strategize around updating
them.
Once this patch is merged we can focus on fixing the modules we've
identified as mobile or desktop targeted and finally dismantling the
targets system altogether.
Bug: T127268
Change-Id: Ia062ff2d8b8732b0d3498c1a614bbf6a3e3a7ddb
The motivation is to make the code less confusing. I hope this is the
case.
?? is an older PHP 7.0 feature.
??= was added in PHP 7.4, which we can finally use.
Change-Id: Id807affa52bd1151a74c064623b41d950a389560
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
All callers provide 'media' for $option and 'all' for $default, just use
those values directly. Class is not stable to extend so this protected
method is not part of the stable interface, codesearch shows no
code on gerrit outside of core that calls the method. Since the $option
parameter is removed, the name no longer makes sense, renamed and
made private.
Change-Id: I875942d5b8c339031fd302f547c9cf16328c9bf2
Follows-up I56a0ee74595404e1, I38a0761ae4633 and I6c3d186de1877f73d4.
Remove most "Usage" examples as these are internal and
mostly-normalized class fields. This is not where end-users should
look for documentation. Besides, many of the examples were wrong or
outdated, and almost all were incomplete. It also had an inherent
dilimma between describing all possible valid input and describing
what we actually store in that instance variable after normalization
in the class constructor. The usage docs have long been moved
to the MW config file, so we can omit that.
In its stead, place more complete and accurate type hints for Phan
to understand the possible code paths, in particular to reflect
the use of FilePath objects.
Change-Id: I1cc002f350785d3f46f79be5defb7b3cadbebf34
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
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 includes/resourceloader/ResourceLoaderFileModule.php (Browse further)
