There are three cases in CSSMin::remap where performs path
resolution.
1. Absolute local path URLs to full URL.
Example: url(/static/foo.png), url(/w/index.php?…), etc.
These previously used wfExpandUrl(), which got the server
name and protocol directly from $wgServer.
We will now use the $remote parameter to get this information
instead, which is generally set to something like
https://wiki/w/resources/foo, and thus naturally contains
the server name and protocol.
The resolution is powered by the Net_URL2 library, allowing
this to work outside Mediawiki as well.
Some tests needed to change because they were calling CSSMin::remap
with an incomplete $remote dummy values like "/" or "/w, because
the test author (past me) was trying to be clever by not supplying
it, knowing MW would ignore it. Now that it is consistently used,
like normal calls from ResourceLoader would, the expected values
will always be based on http://localhost/w, instead of sometimes
the competing $wgServer value of `https://expand.example`.
2. Relative local path to full URL
Example: url(foo.png), url(../foo.png), url(bar/foo.png)
These were already using $remote. The only change is that
they now use Net_URL2 library instead of blind string
concatenation. One of the benefits of this is that we will
no longer need to call wfRemoveDotSegments() to get rid
of things like double slashes or redundant "../" sequences.
Previously, thing like "foo//bar" or "foo/../bar" were cleaned
up only due to wfRemoveDotSegments(). This is now naturally
handled by Net_URL2.
3. Remote URLs
Example: url(http://example.org/bar.png), url(//example.org/bar.png)
This is generally not used in source code, but gadgets may use this,
e.g. for upload.wikimedia.org or cross-wiki imports.
Other changes:
* One test case used spaces within the URL string in CSS, which the
net_url2 library represents with percent-encoding instead.
Same thing either way.
Bug: T88914
Change-Id: Ibef70cc934c0ee8260a244c51bca9fb88c1c0d88
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
For example, documenting the method getUser() with "get the User
object" does not add any information that's not already there.
But I have to read the text first to understand that it doesn't
document anything that's not already obvious from the code.
Some of this is from a time when we had a PHPCS sniff that was
complaining when a line like `@param User $user` doesn't end
with some descriptive text. Some users started adding text like
`@param User $user The User` back then. Let's please remove
this.
Change-Id: I0ea8d051bc732466c73940de9259f87ffb86ce7a
Add the SkinLessImportPaths attribute for skin-specific LESS import
paths, which skins can use to override the mediawiki.skin.variables.less
file.
As a starting point, add the following 5 variables:
* device widths (3x)
To help phase out 'mediawiki.ui/variables'. These are
commonly used by MobileFrontend.
* @font-family-sans
Recommended by Volker. Used by multiple skins.
* @border-radius-base
Recommended by Volker as example of something that we currently
hardcode in MediaWiki core for Vector and OOUI/WikimediaUI
in 'mediawiki.widgets.datetime' but should instead be allowed
to vary by skin and OOUI theme.
Remove the hardcoded value for '@border-radius-base' in
various places in favour of importing from mediawiki.skin.
The default is a bare default of 0 (as border-radius is off
by default in the browser).
The value for Vector is restored there by I47da304667811.
The value for MonoBook is improved by I000f319ab31b.
Bug: T112747
Change-Id: Icf86c930a3b5524254bb549624737d3b9dccb032
* Skin::getAllowedSkins
* Skin::getSkinNames
Both are hard-deprecated and their equivalents in
SkinFactory should be used instead.
Bug: T257993
Depends-On: Ib8e4ec28f6755abec7e33476efefa78dcc2c6b78
Depends-On: Icc945ce1e3287a3b25152702818e5b2a90232677
Change-Id: I9595248ae5410361a5db50d1b95df1e513ac5a2c
* Add a void return hint to methods that are not meant to return
anything. This helps catch accidental return statements in the
future, lets Phan better understand how methods are meant to be
used, and might also allow PHP to better optimise the compiled
code form (speculation).
I did not, however, add it to publicly extended methods as that
might mess with strict mode.
* Remove the internal getResourceLoader() method from MessageBlobStore.
This has been redundant since 3edaa0b37c.
The method was protected, and not considered stable to subclass
for extensions. Hence not a breaking change.
* Add Throwable typehint to formatException() and friends.
This is the narrowest one I could add given that the methods
called from here already enforce the same typehint.
Update the doc to match for now. There isn't a reason right now
to limit this only to Exception, and given this is the method
and not the catch statement itself, does not change behaviour.
* Remove unused ResourceLoader->getHookContainer().
Added within 1.35 cycle, safe to remove.
* Remove unexpected `@since` for `@internal` getHookRunner().
* Remove redundant `@internal` from ResourceLoaderMwUrlModule
methods, which itself is already `@internal`.
Change-Id: I68d33ff6feca7ef95282a7ff03eb9332adfde31c
This fixes an issue with HTML tags inside the <script> tag.
Remex also doesn't throw errors on attributes like @click, although it
does mangle them when producing DOM. To work around this, don't use DOM
serialization for the template HTML, but parse everything again using a
Remex parse+serialize pipeline that extracts the template and
(optionally) removes comments and strips whitespace.
One important effect of this change is that we'll have to forbid
self-closing tags in Vue templates, because Remex doesn't handle those
correctly (or rather, handles them *too* correctly). But on the up side,
we can now allow shorthands for v-bind/v-on/v-slot again.
Bug: T253334
Bug: T255587
Depends-On: I2253a2317187fe0d781ba5bfefab95e0f97d0a80
Change-Id: Id9a9728b7163601cc60bc587be07b70977d41970
The uppercase spelling would I think be confusing, as the actual
options are lowercase, which should be quoted when referred to
in natural language.
Bug: T251957
Change-Id: Ib97a2bc790799990f3e4b622b20636965a93fca1
The new exception was added in ResourceLoaderFileModule.php that
packageFiles and skinScripts are incompatible.
Bug: T251957
Change-Id: Id51763b9049b9b2041c4c1c47575d1a6cb3452b0
Added documentation markup for $wgResourceModules in DefaultSettings.php
and added a reference to it in ResourceLoaderFileModule.php.
Bug: T232566
Change-Id: Ib4c0bd55cc2a06f48ef36ceb069906f1d3a22826
Allows .vue files to be used in package modules as if they were .js
files: they can be added to the 'packageFiles' array in module
definitions, and require()d from JS files.
In the load.php output, each .vue file is transformed to a function that
contains the JS from the <script> tag, then a line that sets
module.exports.template to the contents of the <template> tag (encoded
as a string). The contents of the <style> tag are added to the module's
styles.
Internally, the type of a .vue file is inferred as 'script-vue', and the
file is parsed with VueComponentParser, which extracts the three parts.
After the transformation, the file's type is set to 'script+style', and
files of this type contribute to both getScript() and getStyles().
This change also adds caching to getPackageFiles(), because it now needs
to be called twice (in getScript() and getStyles()).
Change-Id: Ic0a5c771901450a518eb7d24456053956507e1ed
This file had six different almost-identical calls to the system
call file_get_contents(), which makes it hard to fix all nine of
them neatly.
Change-Id: I607f3cd3dbfa0f47f8d9766a27e581fdc127a0cf
This replaces the client-side compiler for 'mediawiki.template.regexp',
with a simple PHP callback.
The regexp temple compiler is not used anywhere after this and will be
removed in a follow-up commit.
Bug: T233676
Change-Id: I1baa1465d88293d03975cadf2efdd57283427722
This can be enabled via a configuration flag. Otherwise, SqlModuleDependencyStore
will be used in order to keep using the module_deps table.
Create a dependency store class, wrapping BagOStuff, that stores known module
dependencies. Inject it into ResourceLoader and inject the path lists into
ResourceLoaderModule directly and via callback.
Bug: T113916
Change-Id: I6da55e78d5554e30e5df6b4bc45d84817f5bea15
ResourceLoaderFileModule::readStyleFile() both reads a style file from
disk and processes it through LESS, CSSJanus and CSSMin. Factor out the
processing part into ResourceLoaderFileModule::processStyle(), which
takes a string of unprocessed CSS/LESS rather than a file. This is
needed for future support for styles that don't come (directly) from a
file, but are generated through packageFiles.
Other changes:
- Use a hash of the source instead of the file name in the cache keys
for the LESS compilation output
- Also prefix the cache key with 'resourceloader' while we're changing
it anyway
- LESS compilation no longer adds the source file itself as a dependency
- Don't pass down $flip, just use $this>getFlip()
Change-Id: I86e880d06af724f0fbae93e042c85e0395771912
If a callback for a virtual file returns a ResourceLoaderFilePath
object, we will load that file from disk and use it in that file's
place. This enables us to port modules that use languageScripts or
skinScripts, by writing a virtual file callback that returns a
ResourceLoaderFilePath pointing to different files depending on the
language/skin.
This also makes the base path parameters to the ResourceLoaderFilePath
constructor optional. Callbacks would construct a ResourceLoaderFilePath
with only one parameter (the file path, but no base paths), and the
RL infrastructure ignores the object's base paths anyway, in favor of
the module's base paths.
Bug: T239371
Change-Id: I8e24f667b4e1944c20f3354a9f7382d5c486055e
Instead of hashing each file separately, hash them in a batch.
Previous research on this area of code has identified the suppressing
and restoring of warnings to have a measurable cost, which is why
this was optimised in 3621ad0f82. However, we never really made
use if it (aisde from the 2:1 change in that commit itself), because
we always call it with a single item, turn it into an array, do the
hash and then merge it again.
Instead, we now let it handle a single module's set of files all
at once. Given that this no longer exposes an array of hashes,
also update the (private) signature of getFileHashes to reflect this.
This means all file modules will have their version bumped during the
next MediaWiki release. In general this happens for most releases
and weekly branches already (due to localisation update, general
maintenance, linting changes, and other internal changes). But,
noting here for future reference as this might not be obvious from
the diff.
Change-Id: I4e141a0f5a5c1c1972e2ba33d4b7be6e64ed6ab6
* Use LanguageFallback::getAll directly instead of the
deprecated wrapper Language::getFallbacksFor.
* For the loop over package files, use foreach instead of the slower array_map.
Also incorporate a simple simple isset() check in that foreach loop,
instead of iterating the values a second time with array_filter.
This also makes the check more explicit (we discard values that have
'filePath' unset or set to null), previously array_filter rejected any
value that could indirectly cast to boolean false.
* For the safeFileHash loop, also use foreach with assignments instead
of the slower array_map. As a side-effect this now makes explicit that
we don't preserve array keys (assignments use []= to push).
This means we can remove the array_values() call, which previously performed
yet another loop and transformation on our array.
Bug: T233059
Change-Id: I3fe9f0a9ddcce8870ac02986193022a12ecc1606
Avoid use of wfTimestamp and wfDebugLog global functions.
Also simplify some of the error messages around processing of
'packageFiles' definitions and throw generic LogicException
instead of MWException.
Change-Id: I55ce1f107f53dfdfe673cbe4411b0a7c4e24b2ea
The PHP code handling 'packageFiles' looks like it only expects
numeric arrays, and not associative arrays. Therefore in JSON the
value for the 'packageFiles' key should be arrays and not objects.
(And a special case of a string, handled the same as single-element
array, is also accepted.)
Individual items in the array can be not only strings, but also
objects, describing data which is pulled from other sources than a
file.
* ResourceLoaderFileModule: Remove unused variable and tweak docs.
Change-Id: I6c3d186de1877f73d4a4e3fec7d6d632a5d5fa83
Currently packageFiles callbacks take 2 parameters, $context and $config.
This patch allows for specifying an extra parameter in the packageFiles
definition that will be passed to the callback. Example:
'callback' => function ( $context, $config, $extra ) { ... },
'callbackParam => [ 'this is val 1', 'this is val 2' ],
The callback will be called with the usual $context and $config
parameters, and the extra array is passed as third parameter.
Bug: T233634
Change-Id: Ie11874665f4f9a557d4e394dcab3a972887e8126
This change allows to use the context in the functions.
The following internal static functions from ResourceLoader get now a
reference to the ResourceLoaderContext object:
* makeLoaderImplementScript
* makeLoaderStateScript
* makeLoaderRegisterScript
* makeLoaderSourcesScript
ResouceLoader::encodeJsonForScript is duplicated to
ResourceLoaderContext::encodeJson loading the debug mode from context.
ResourceLoader::encodeJsonForScript is kept for other usages without
context.
The debug mode is loaded from $context->getDebug() instead of from
ResourceLoader::inDebugMode(). This does not support to enable the debug
mode by setting the cookie 'resourceLoaderDebug' or the configuration
variable wgResourceLoaderDebug. Only the URL parameter debug=true
enables the debug mode. This should be sufficient for the subsequent
ResourceLoader requests. The tests don't need the global variable
wgResourceLoaderDebug anymore. The initial ResourceLoader context in
OutputPage still uses ResourceLoader::inDebugMode() with cookie and
global configuration variable.
This change adds the parameter $context with a ResourceLoaderContext
object to ResourceLoaderModule::getDeprecationInformation and deprecates
omitting the parameter. Ifa1a3bb56b731b83864022a358916c6aca5d7c10
updates this in extension ExtJSBase.
Bug: T229311
Change-Id: I5341f18625209446a6d006f60244990f65530319
* Add license header where missing.
* Add missing `@since` (1.17 for most classes), except
ResourceLoaderLessVarFileModule since 1.32 (1bc62c548c).
* Remove duplicate file-level description for class-only files,
merge with the class description instead.
* Remove my own `@author` annotation from one file.
* Mark core's own FileModule subclasses as `@internal`, except
for the following which we support use of in extensions:
ResourceLoaderLessVarFileModule,
ResourceLoaderOOUIIconPackModule, and
ResourceLoaderWikiModule.
Change-Id: I336af2e4ccdbe2512594e8861b72628d24194e41
Also change a `@private` tag to `@internal` in ResourceLoaderFileModule
for consistency with other RL code.
Change-Id: I8c3a5aa36b643083c0b6d2f3c8d623f344b7c0be
Callbacks used to generate the contents of virtual files in packageFiles
modules only received a ResourceLoaderContext object. They could access
the Config object through ResourceLoaderContext::getConfig(), but that
method is deprecated. Pass the Config object as a second parameter to
these callbacks, so that they don't have to use a deprecated method.
Change-Id: Ia4666914e9b07f298ee5ae30ae8c70a3e83b0910
This change follows I39cc2a735d9625c87bf4ede6f5fb0ec441d47dcc.
docs/extension.schema.v1.json
docs/extension.schema.v2.json
includes/registration/ExtensionProcessor.php
* The new extension attribute 'OOUIThemePaths' can be used to define
custom OOUI themes. See I9187a63e509b601b8558ea82850fa828e5c8cc0a
for an example usage.
includes/resourceloader/ResourceLoaderOOUIModule.php
* Add support for 'OOUIThemePaths'.
* Defining 'images' is now optional. I figure custom themes are
unlikely to have or need them.
* Use ResourceLoaderFilePath objects to allow skin-/extension-defined
OOUI module files to use skin/extension's base paths.
This was previously used to support $wgResourceModuleSkinStyles,
but only for 'skinStyles' - now ResourceLoaderFileModule needs
to also handle it for 'skinScripts', and ResourceLoaderImageModule
for 'images').
includes/resourceloader/ResourceLoaderFilePath.php
* Add getters for local/remote base paths, for when we need to
construct a new ResourceLoaderFilePath based on existing one.
includes/resourceloader/ResourceLoaderFileModule.php
includes/resourceloader/ResourceLoaderImageModule.php
includes/resourceloader/ResourceLoaderOOUIImageModule.php
* Add or improve handling of ResourceLoaderFilePaths:
* Replace `(array)` casts with explicit array wrapping, to avoid
casting objects into associative arrays.
* Use getLocalPath() instead of string concatenation.
tests/phpunit/includes/resourceloader/ResourceLoaderFileModuleTest.php
tests/phpunit/includes/resourceloader/ResourceLoaderImageModuleTest.php
* Some basic checks for the above.
Bug: T100896
Change-Id: I74362f0fc215b26f1f104ce7bdbbac1e106736ad
Being a raw module means that when it is requested from load.php with
"only=scripts" set, then the output is *not* wrapped in an
'mw.loader.implement' closure *and* there no 'mw.loader.state()' appendix.
Instead, it is served "raw".
Before 2018, the modules 'mediawiki' and 'jquery' were raw modules.
They were needed before the client could define 'mw.loader.implement', and
could never be valid dependencies. Module 'mediawiki' merged to 'startup',
and 'jquery' became a regular module (T192623). Based on the architecture
of modules being deliverable bundles, it doesn't make sense for there to
ever be raw modules again. Anything that 'startup' needs should be bundled
with it. Anything else is a regular module.
On top of that, we never actually needed this feature because specifying
the 'only=scripts' and 'raw=1' parameters does the same thing.
The only special bit about marking modules (not requests) as "raw" was that
it allowed the client to forget to specify "raw=1" and the server would
automatically omit the 'mw.loader.state()' appendix based on whether the
module is marked as raw. As of Ie4564ec8e26ad53f2, the two remaining use
cases for raw responses now specify the 'raw=1' request parameter, and we
can get rid of the "raw module" feature and all the complexity around it.
== Startup module
In the startup module there was an interesting use of isRaw() that has
little to do with the above. The "ATTENTION" warning there applies to the
startup module only, not raw modules in general. This is now fixed by
explicitly checking for StartupModule.
Above that warning, it talked about saving bytes, which was an optimisation
given that "raw" modules don't communicate with mw.loader, they also don't
need to be registered there because even if mw.loader would try to load
them, the server would never inform mw.loader about the module having
arrived. There are now no longer any such modules.
Bug: T201483
Change-Id: I8839036e7b2b76919b6cd3aa42ccfde4d1247899
Also, for the unit test, disable the two methods we use there
that can get called. The unintended side-effects of these two
methods was the only reason it used `@group Database`.
Removing that makes the test a bit faster as well.
Enforce this via MediaWikiServices for this suite to avoid an
untracked dependency slipping back in in the future.
Bug: T225730
Change-Id: I6c54466e9517d9899bc39f8f9bb946369c0a526d
The use cases we've seen for using computed (or virtual) package files,
involve expensive computations to expand and transform data for the client
that we don't want to evaluate in full just to compute the module's version
hash (e.g. in the StartupModule, where we need to do this for 1000s of
modules).
For such cases, the module can specify a 'versionCallback' of which the
return value will be used to seed the module's version hash. The default
remains the same as before, which is to use the full content to seed the
version hash (via getDefinitionSummary).
Bug: T223260
Change-Id: I76f573239e6bd429287e7adb33a92ffd5e260c20
Was introduced as a transitional measure in Ic566a1cd7efd075c3.
Depends-On: I717f03caf9ea8266e6a4d2b6daf4c543c0815931
Change-Id: I6ae615ea38572042f8ba705338067b393827153a
The module definition format for 'packageFiles', as initially designed,
mixes sequential and associative arrays. This works in PHP, but not in
JSON. To make the format JSON compatible, use a 'name' key instead of
using the key in the main array.
Leave backwards compatibility in place so that extensions using the old
format can be migrated. This will be removed in the next commit.
Before:
'packageFiles' => [
'script.js',
'script2.js',
'config.json' => [ 'config' => [ 'Foo', 'Bar' ] ],
'data.json' => [ 'callback' => function () { ... } ],
],
After:
'packageFiles' => [
'script.js',
'script2.js',
[ 'name' => 'config.json', 'config' => [ 'Foo', 'Bar' ] ],
[ 'name' => 'data.json', 'callback' => function () { ... } ],
],
This can then be written in extension.json as:
"packageFiles": [
"script.js",
"script2.js",
[ "name": "config.json", "config": [ "Foo", "Bar" ] ],
[ "name": "data.json", "callback: [ "MyExtHooks", "getData" ] ]
]
Change-Id: Ic566a1cd7efd075c380bc50ba0cc2c329a2041d7
Deprecated since MW 1.27.
Also update ResourcesTest to use TestingAccessWrapper instead of long-form
object reflection, and also apply it to its call for this method given
its meant to be private.
Change-Id: I9cc1af93730f632e4f8bf3a16d514a51ee73cb03
Package files are files that are part of a module, but are not
immediately executed when the module executes. Instead, they are
lazy-excecuted when require() is called on them. Package files can be
scripts (JS) or data (JSON), and can be real files on the file system,
or virtual files generated by a callback.
Using virtual data files, server-side data and config variables can be
bundled with a module. Support for file-based require() allows us to
import npm modules into ResourceLoader more easily.
The require function passed to each script execution context, which was
previously a reference to the global mw.loader.require() function, is
changed to one that is scoped to the module and the file being executed.
This is needed to support relative paths: require( '../foo.js' ) can
mean a different file depending on the path of the calling file.
The results of require()ing each file (i.e. the value of module.exports
after executing it) are stored, and calling require() on the same file a
second time won't execute it again, but will return the stored value.
Miscellaneous changes:
- Add XmlJsCode::encodeObject(), which combines an associative array of
XmlJsCode objects into one larger XmlJsCode object. This is needed for
encoding the packageFiles parameter in mw.loader.implement() calls.
Bug: T133462
Change-Id: I78cc86e626de0720397718cd2bed8ed279579112
