For some varargs a variable name is added with suffix ,... as seen for
many other varargs
Some @param are swapped, because there are in the wrong order
Enable Sniff MediaWiki.Commenting.FunctionComment.ParamNameNoMatch
Change-Id: I60fec6025bce824d5c67563ab7b65ad6cd628ad8
Since this subclasses ResourceLoaderFileModule, in debug mode
it was loaded by embedding the .js files directly, which caused
the 'wgFragmentMode' config variable to not be set (since the
code to do it was not sent to the client). Disallow this.
Bug: T172512
Change-Id: I1af944e4f4946023519e3453295b04a6cbca9fa3
ResourceLoaderModule objects gain a new method getPreloadLinks() which
returns an array with the meta data required to build a Link rel=preload
header according to the current draft for W3C Preload.
<https://w3c.github.io/preload/>
Another implementation of this is already in use in OutputPage for
preloading the logo image.
This array is formatted by the ResourceLoaderModule::getHeaders method,
which is implemented as "final" at this time, thus restricting use to
the Link rel=preload header.
Headers are exposed and process-cached, like all other content
(scripts, styles, etc.), through ResourceLoaderModule::getModuleContent,
and aggregated by ResoureLoader::makeModuleResponse.
I had hoped for the getPreloadLinks to be stateless (not vary on $context).
Whether something should be preloaded and what, should not vary on the
skin or language. However, while that conceptually holds true, the exact
url for any given resource may still vary. Even the main use case for this
feature (T164299, preloading base modules request) require $context to pass
down skin and lang to the load.php url.
Add full test coverage and example documentation.
Bug: T164299
Change-Id: I2bfe0796ceaa0c82579c501f5b10e931f2175681
It adds the ability to replace the current section ID escaping
schema (.C0.DE) with a HTML5-compliant escaping schema that is
displayed as Unicode in many modern browsers.
See the linked bug for discussion of various options that were
considered before the implementation. A few remarks:
* Because Sanitizer::escapeId() is used in a bunch of places without
escaping, I'm deprecating it without altering its behavior.
* The bug described in comments for Parser::guessLegacySectionNameFromWikiText()
is still there in some Edge versions that display mojibake.
Bug: T152540
Change-Id: Id304010a0342efbb7ef2d56c5b8b244f2e4fb2c5
This already worked as expected for any module that uses the new
enableModuleContentVersion model, but for the majority of file modules
this is not yet the case for performance reasons. As such, make
sure lessVars are included in our manual tracking.
Include it conditionally to avoid changing the array for other modules,
which would needlessly invalidate their cache.
Bug: T171809
Change-Id: Ib250068e0ecfc29a09ca33c23bef901ee0482bf2
And auto-fix all errors.
The `<exclude-pattern>` stanzas are now included in the default ruleset
and don't need to be repeated.
Change-Id: I928af549dc88ac2c6cb82058f64c7c7f3111598a
Rather than only the 'private' group triggering embedding, allow modules
to explicitly specify if they should be embedded.
The default is still to only embed when the group is 'private', and the
'private' group is still special in that ResourceLoader::respond() will
still refuse to serve it from load.php.
Change-Id: Ib9a043c566822e278baecc15e87f9c5cebc2eb98
If any of the styles given in its module definition (in the
'styles' or 'skinStyles' properties) used the same media queries
as the module's own CSS (e.g. 'all'), the module would fail with
"PHP Fatal error: [] operator not supported for strings" because
FileModule defaults to merging all the stylesheets into a single
string.
Fix this by ensuring they are arrays before trying to extend them.
This previously made it impossible to use $wgResourceModuleSkinStyles
for modules that use SkinModule (instead of plain FileModule), such as
the 'mediawiki.skinning.interface' module.
Bug: T168088
Change-Id: I3effcaa4982728e707fbf9efeec4e5e78fc8aab6
If a skin is using this class, it's likely to be pretty new.
The targets system was mostly created for older code.
Let's make this the default so skins don't need to do anything
additional to work on mobile.
This simple change makes the Timeless skin work on mobile
when MobileFrontend is installed: ?useformat=mobile&useskin=timeless
It looks beautiful :)
Change-Id: I2ab8a1a634bdc0b5b2084d227c7388b5382e93e8
If a type=general module is enqueued, don't try to load it as a
stylesheet.
* Per a464d1d41d, state tracking is already disabled for
these loads (as otherwise we wrongly claim state=ready, when in
fact only the styles and not the scripts were loaded).
* The warning was added in a464d1d41d.
* Default install (tested in Vagrant), Wikimedia Beta cluster, and
Wikimedia production have seen zero violations of this warning
in the past 7 days.
Raise severity to ERROR and add the 'continue' statement so that
these are now not loaded at all.
Bug: T92459
Change-Id: I211d56ac2df479ebf5b98667c613ecf81489539b
This fixes two bugs:
* 1) When two modules are requested, and the first one ends with ";"
inside a comment, the second module might become part of
that comment.
* 2) A request with script=only where the requested module content
ends in a statement without ";", but has a comment after it
that does ends with a semicolon, then in debug=false, mw.loader.state()
would be appended directly after the semicolon-less statement because
the check is performed before minification.
Previously:
script> foo()
script> // bar();
states> mw.loader.state( {} );
Became (minified separately):
script> foo()
states> mw.loader.state({});
Became (concatenated)
> foo()mw.loader.state();
Which is invalid code.
Both of these are now fixed.
Bug: T162719
Change-Id: Ic8114c46ce232f5869400eaa40d3027003550533
Undo traces of a practice we carried over from past projects and
existing examples that is neither universal nor actively encouraged in
the MediaWiki codebase.
Bug: T139301
Change-Id: I5c9c89b72a45a44aa4264a5e57b003c1a86cdf6e
Co-Authored-By: Brad Jorsch <bjorsch@wikimedia.org>
All ResourceLoaderFileModule subclasses are now required to support
the 'skinStyles' property in their module definition, and ideally
make use of it (but at least they must not fail violently).
Follow-up to 51eede0283.
Bug: T167478
Bug: T168088
Change-Id: I35a12a451bf2695818702df1bbd1708173a3f9ce
Note: calling msg() with no parameter was never supported,
doing this on a RequestContext for example would result in:
PHP Warning: Missing argument 1 for wfMessage() ...followed
by a bunch of fallout.
So this patch only formally declares what was already a
requirement in reality.
Change-Id: I1864afb8bcc641698689828914949a06506d8f3a
In c8ad83310f, 'oojs-ui-core.styles'
was changed to use ResourceLoaderOOUIFileModule instead of plain
ResourceLoaderFileModule. This had the unintended consequence that
ResourceLoader::isFileModule() no longer returned true for it, and
this $wgResourceModuleSkinStyles no longer worked, breaking styling
in Vector.
Additionally, the new ResourceLoaderOOUIFileModule did not respect
the skinScripts/skinStyles options passed in the module definition
(therefore also those from $wgResourceModuleSkinStyles). Merging
them turns out to be a major pain, but it can be done.
Bug: T167042
Change-Id: I7547bbe996467745c1f0b168b40f27eb95c6238d
includes/resourceloader/ResourceLoaderOOUIModule.php
* New trait centralizing some logic for dealing with OOjs UI themes,
previously duplicated in OutputPage, ResourcesOOUI.php and
ResourceLoaderOOUIImageModule.
* Follow-up change I74362f0fc215b26f1f104ce7bdbbac1e106736ad uses this
as a base to allow skins/extensions to define new OOjs UI themes.
resources/Resources.php
resources/ResourcesOOUI.php
includes/resourceloader/ResourceLoader.php
* OOjs UI resource module definitions are moved back to their rightly
place in Resources.php. They are again (almost) normal and static.
* Theme-specific logic is now handled by the module code, definitions
only specify 'themeScripts'/'themeStyles'/'themeImages'.
* ResourcesOOUI.php is deleted and no longer loaded by ResourceLoader.
includes/resourceloader/ResourceLoaderOOUIFileModule.php
includes/resourceloader/ResourceLoaderOOUIImageModule.php
* Glue code previously existing in ResourcesOOUI.php now lives here.
* Use the ResourceLoaderOOUIModule trait to avoid code duplication.
Change-Id: I39cc2a735d9625c87bf4ede6f5fb0ec441d47dcc
This should work the same way as registering API modules via a factory callback.
Point in case: Ifb8611473a971 could avoid global state using this mechanism.
Change-Id: Ifbf29006141ce2a2dff42efa352f406502a06bc6
* Add fileName to cache key to fix T52919. The cached parsed error
message contains the filename, this should be part of the cache
key as otherwise two identical user scripts may report the same
error message, including " on line X of page Y" where Y is whichever
of the two pages first created the cache entry.
* Make the cache key global instead of per-wiki. There is no need
for this to be per-wiki.
Bug: T52919
Change-Id: I6c2718c53be7f6384a6486a4a8718ae7f423d216
* Simplify by using early return and getWithSetCallback.
* Add TTL (previously indefinite, now 1 week).
Bug: T52919
Change-Id: Ic95ba392cdb3bcc8081c77d2c2a3240548bed366
Previously it was only in debug logs (which are enabled in Jenkins,
MediaWiki-Vagrant, Beta, and for mwdebug hosts in wmf-production).
Turning it into a warning() will log it for regular requests as well
which is the last step before we can consider hard enforcement.
Bug: T92459
Change-Id: I87c7794c5cfe35521bf76cc42f94907001e9d24b
Follows-up 5f55e9c9c2.
If the logo url is from within /w, then ResourceLoaderSkinModule
will (as it should) apply a file hash query to it.
The preloader didn't do that, so it specified the wrong url.
Refactored SkinModule to make this logic re-usable.
Bug: T100999
Change-Id: I1ba11f7c70d1a725ad72754fee4a3f33c2a4c1be
This greatly increases the priority of loading
the logo on browsers that support rel="preload".
Bug: T100999
Change-Id: I0738fcc0a575153dab65016fa87faaa9b8b97a9d
Follows-up 0ac4f998 (restore "blocking" legacy modules).
After d790562, legacy modules in the top queue were no longer consistently
loaded before the bottom queue due to the top queue being async.
The implied dependency was made explicit by 0ac4f998 by forcing all modules
to wait for legacy modules before executing.
This had the negative side-effect of putting an extra HTTP request between
the startup module request, base modules request, and actual execution
of page modules.
(Indentation aligns with when a request is triggered.)
Before:
1. Request: Startup module.
2. Request: Base modules
3. Request: Legacy modules
4. Page module request (or local store hit) and execution
After:
1. Request: Startup module.
2. Request: Base+legacy modules
3. Page module request (or local store hit) and execution
This could alternatively be fixed by moving the top queue to be before
the embedded modules and enforcing the embed in a different way.
It could also be fixed by debouncing module load calls so they naturally
end up in the same request as page modules.
However for now I'm addressing this by adding legacy modules to the
list of modules in the initial load request from the startup module.
This was not possible before because the legacy wikibits had dependencies
and base modules cannot have dependencies. Fixed in I7f9f61ea81ad1ef.
Bug: T159911
Change-Id: I54f087655e1cde1b8ff1ca5fe56e82f7f7d80965
preloadTitleInfo:
* Add missing case for empty $moduleNames.
* Add missing case for invalid page names.
getContent:
* Add missing case for bad title
* Add missing case for dead redirect.
* Add missing case for no content found.
Change-Id: I44dde13cb0db19d91c4ff15a5abefd17353cad90
It turns out that 'resources/lib/oojs-ui/themes/mediawiki/Moved since v0.20.1, use from the 'interactions' pack instead.'
is not usually an existing file, and doesn't have the extension '.svg'.
Not sure why this didn't break earlier.
Bonus: Add module name to exceptions to make these errors easier
to track down.
Bonus #2: Use the post-expansion, not pre-expansion, definition everywhere
to avoid confusion when debugging.
Change-Id: I0325d4dab5658fd29c3c33fd3e762834b53d1b5d
Use getDefinitionSummary instead, which uses a single serialisation
pass instead of requiring every stage to be a string. This way
we don't need to call json_encode and md5() multiple times.
getModifiedHash() was deprecated in MediaWiki 1.26.
Change-Id: If9e9caa3d12976c99543ad53ab280355b70acb17
