* Where possible and easy to figure out, change `array` to something like
`array<K,V>` or `V[]` for improved static analysis to catch/prevent
regressions in CI.
* Minor doc improvements:
- consistently use the imperative mood for method briefs,
- consistently use @internal instead of @private,
- explain in @throws why they happen to inform when they should be caught
(and remove if they are not meant to be caught/handled by any caller).
* Simplify addSources() implementation as a simple loop instead recursing
(not worth the complexity, only called once or twice at runtime).
* Use more granular exceptions to distinguish between errors that indicate
a mistake on the caller (logic/invalid arguments error), and runtime
errors (which are more circumstantial).
* Update register() unit test for bad 'moduleInfo' type to use
a nested value, given that the second-parameter level type is
now verified by the signature already.
Change-Id: Id98ba1f28cb7f1c72f0a3e82f4151bcbd0f3db77
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
Already in 1.34 release notes from when it was soft-deprecated, earlier
this release cycle.
Depends-On: I949b91daabb0cf16519ef02e718ad97c827c4eec
Depends-On: Icf1ead8829268505709c71f46dede5cdfc4471a8
Change-Id: I471088b322848a779d0dd58651dc1bd0d49067f1
This change also removes the defaults from the URL parameter:
* lang=qqx
* skin=fallback
* debug=false
Bug: T225899
Change-Id: I4cbc42e39ebc56c3d29f773a275afe2b1a44c913
The methods existed for two use cases.
1. Inside ResourceLoaderContext, usage was removed with I4e4ee758cd22.
2. In Module class methods that get $context, already have their own
Config and Logger instances injected from ResourceLoader::getModule(),
which should be used instead.
Deprecating these opens the paths for making ResourceLoaderContext
a purer value object with no ResourceLoader, Config, or Logger objects
needing to be passed (in the future).
Bug: T32956
Change-Id: I74a9535918ea43b2c00073c5d4469f864d1eeb41
This is never used by the mw.loader client code. For any
manually crafted requests or fringe usage where the load.php
might be used to fetch some raw JS code that doesn't vary by
language or skin, proceed with qqx/fallback.
In the future load.php might deny these requests and then we
could make this a constructor parameter to ResourceLoaderContext.
Bug: T32956
Change-Id: I4e4ee758cd22278cea9592d4745b4f7fc00e0add
This has always been an odd case, as indicicated by the cross-class
comment references, and the fact that its test cases are already
in ResourceLoaderTest.php, for convenience, as that's also where
the creation of 'module name strings' is done and tested.
Actually move it there instead of pretending it is there.
Change-Id: Ied9569436cc78704a5c1b75eeebb73f8631350f6
Reduce our reliance on static state and configuration, and
propagate more state in explicit ways, through context, and
request parameters.
OutputPage creates ResourceLoaderContext and ResourceLoaderClientHtml
based on the configuration (via ResourceLoader::inDebugMode).
Everything within those classes should not need to check it
again.
* ResourceLoaderClientHtml:
Already doesn't check MW config, but it's test was still
mocking it. Removed now, and confirmed that it passes both
with true and false. The individual test cases set
debug=true/false as needed already.
It's sets were previously relying on the accidental behaviour
that within a unit test, we don't serialise over HTTP, which
meant that a pure PHP boolean would survive. With the new
raw `=== 'true'` check, this no longer works. Set it as a
string explicitly instead, which is the only thing we support
outside unit tests as well.
* ResourceLoaderContext:
Remove fallback to MW config when 'debug' is unset.
This is never unset in practice given that all load.php
urls have it set by OutputPage based on ResourceLoader::inDebugMode.
This change means that manually constructed ad-hoc load.php
urls that are missing 'debug=' parameter, will now always be
read as debug=false. This was the default already, but could
previously be changed through wgResourceLoaderDebug.
When changing wgResourceLoaderDebug, everything will still have
debug=true as before. The only change is when constructing load.php
urls manually and explicitly not set it.
Bug: T32956
Change-Id: Ie3424be46e2b8311968f3068ca08ba6a1139224a
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
It also removes some code duplication which is nice.
This unlocks various future changes, including:
* Making the `$config` parameter mandatory for the ResourceLoader class
constructor, which currently falls back to global state.
This should be deprecated and removed.
* Making it possible to instantiate the ResourceLoader class
without all the default MW modules being registered from
global state. E.g. move MW module registration from main class
constructor to ServiceWiring, and remove the 'EmptyResourceLoader'
class hack from unit tests, and use regular 'new ResourceLoader'
instead.
* Making ResourceLoader a standalone library (some day),
e.g. allowing it to be instantiated from a basic PHP script,
in a way that is still useful and perhaps able to serve
(most) RL modules without MW itself.
Bug: T32956
Change-Id: I4939f296c705b268e9cf8de635e923a739410470
Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
In one occurrence, a simple conditional instead of trickery was much more readable.
This patch finishes all the easy stuf in the core, the remainder is either unobvious
or would result in smaller readability gains. It will be carefully dealt with in
further commits.
Change-Id: I79a16c48bfb98b75e5b99f2f6f4fa07b3ae02c5b
There has long been a hack for previewing edits to user JS/CSS, where
OutputPage would pass an 'excludepage' parameter to
ResourceLoaderUserModule to tell it not to load one particular page and
would instead embed that page statically. That's nice, but there are
other places where we could use the same thing.
This patch generalizes it:
* DerivativeResourceLoaderContext may now contain a callback for mapping
titles to replacement Content objects.
* ResourceLoaderWikiModule::getContent() uses the overrides, and
requests embedding when they're used. All subclasses in Gerrit should
pick it up automatically.
* OutputPage gains methods for callers to add to the override mapping,
which it passes on to RL. It loses a bunch of the special casing it
had for the 'user' and 'user.styles' modules.
* EditPage sets the overrides on OutputPage when doing the preview, as
does ApiParse for prop=headhtml. TemplateSandbox does too in I83fa0856.
* OutputPage::userCanPreview() gets less specific to editing user CSS
and JS, since RL now handles the embedding based on the actual
modules' dependencies and EditPage only requests it on preview.
ApiParse also gets a new hook to support TemplateSandbox's API
integration (used in I83fa0856).
Bug: T112474
Change-Id: Ib9d2ce42931c1de8372e231314a1f672d7e2ac0e
For the same reasons as in ResourceLoaderContext. The only valid values
here are known strings like "desktop" and "mobile". No Language/UTF
normalisation required.
Ensures that Language instance won't get initialised just for this.
Change-Id: If219463d80a66132786710184329388080fbe713
* Move buildModulesString() call from doRequest() to batchRequest()
This keeps all module string "packing" logic located to the same function,
which is batchRequest(). It also means that the moduleMap object will not
leave the function, which helps in maintenance given it's very internal.
* Add comments to all the methods referring to each other.
* Explain why buildModulesString() is only a partial port, and the rest is
inlined in batchRequest().
* Minor changes to the JS and PHP implementation to better match each other.
- '$groups' -> '$moduleMap'.
- Remove redundant '$str'.
Bug: T188076
Change-Id: I7b0790606c456e492ab682faeb80f7e7fce7d9f8
I spotted one of these in my debug log. Without context it is not
useful nor informative. Given it can actually come from three places,
it is useless.
Change-Id: Ic293d8944e9a1a8152c5a5e0b695c5ddc07ee6aa
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
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
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
Utility methods like getFuzzyBool already use getRawVal instead
of getVal (see 83df6d8). But there was still direct use of getVal
which meant we still pay for WebRequest normalisation in load.php.
ResourceLoaderContext::__construct's use of WebRequest::getVal
accounts for 0.12% of execution time according to a Xenon daily log
(2016-09-27.all.reversed.svgz). The total use of WebRequest::getVal
is 0.26% of execution time. So almost half of that comes from RL.
Change-Id: Id37619ceadb5c990abf83f7910104cbc95523d28
Ensure that messages created using ResourceLoaderContext::msg() have a
title set so they don't trigger the GlobalTitleFail log. We use a dummy
title since there is no real title we can use here, and the cache
doesn't vary on a title anyways. This particular title was picked
especially for Roan.
This patch should quiet the GlobalTitleFail logs for
MFResourceLoaderParsedMessageModule and VisualEditorDataModule.
Change-Id: I502faa22776e1cb34a6ef17be96567f121c80081
* Fix up one last use of global config vars in this class.
Other places in this class already used $rl->getConfig().
This way we don't inherit all of MediaWikiTestCase.
* Add unit tests covering all of ResourceLoaderContext
except expandModuleNames and getImageObj (tested in better
places already with the right @covers).
* Increase coverage for expandModuleNames(), add missing case
of when modules are not in alphabetical order.
Change-Id: Id19b084d37a6c3a77b36e03509adffb6b156fee1
HTML formatting of the queue was distributed over several OutputPage methods.
Each method demanding a snippet of HTML by calling makeResourceLoaderLink()
with a limited amount of information. As such, makeResourceLoaderLink() was
unable to provide the client with the proper state information.
Centralising it also allows it to better reduce duplication in HTML output
and maintain a more accurate state.
Problems fixed by centralising:
1. The 'user' module is special (due to per-user 'version' and 'user' params).
It is manually requested via script-src. To avoid a separate (and wrong)
request from something that requires it, we set state=loading directly.
However, because the module is in the bottom, the old HTML formatter could
only put state=loading in the bottom also. This sometimes caused a wrong
request to be fired for modules=user if something in the top queue
triggered a requirement for it.
2. Since a464d1d4 (T87871) we track states of page-style modules, with purpose
of allowing dependencies on style modules without risking duplicate loading
on pages where the styles are loaded already. This didn't work, because the
state information about page-style modules is output near the stylesheet,
which is after the script tag with mw.loader.load(). That runs first, and
mw.loader would still make a duplicate request before it learns the state.
Changes:
* Document reasons for style/script tag order in getHeadHtml (per 09537e83).
* Pass $type from getModuleStyles() to getAllowedModules(). This wasn't needed
before since a duplicate check in makeResourceLoaderLink() verified the
origin a second time.
* Declare explicit position 'top' on 'user.options' and 'user.tokens' module.
Previously, OutputPage hardcoded them in the top. The new formatter doesn't.
* Remove getHeadScripts().
* Remove getInlineHeadScripts().
* Remove getExternalHeadScripts().
* Remove buildCssLinks().
* Remove getScriptsForBottomQueue().
* Change where Skin::setupSkinUserCss() is called. This methods lets the skin
add modules to the queue. Previously it was called from buildCssLinks(),
via headElement(), via prepareQuickTemplate(), via OutputPage::output().
It's now in OutputPage::output() directly (slightly earlier). This is needed
because prepareQuickTemplate() calls bottomScripts() before headElement().
And bottomScript() would lazy-initialise the queue and lock it before
setupSkinUserCss() is called from headElement().
This makes execution order more predictable instead of being dependent on
the arbitrary order of data extraction in prepareQuickTemplate (which varies
from one skin to another).
* Compute isUserModulePreview() and isKnownEmpty() for the 'user' module early
on so. This avoids wrongful loading and fixes problem 1.
Effective changes in output:
* mw.loader.state() is now before mw.loader.load(). This fixes problem 2.
* mw.loader.state() now sets 'user.options' and 'user.tokens' to "loading".
* mw.loader.state() now sets 'user' (as "loading" or "ready"). Fixes problem 1.
* The <script async src> tag for 'startup' changed position (slightly).
Previously it was after all inline scripts and stylesheets. It's still after
all inline scripts and after most stylesheets, but before any user styles.
Since the queue is now formatted outside OutputPage, it can't inject the
meta-ResourceLoaderDynamicStyles tag and user-stylesheet hack in the middle
of existing output. This shouldn't have any noticable impact.
Bug: T87871
Change-Id: I605b8cd1e1fc009b4662a0edbc54d09dd65ee1df
Most code paths already wrongly assume this behaviour.
This patch removes the now-redundant check from the two modules
that did account for it.
Change-Id: Ic85258f184db8aa68e19d8e667e396d08ee5de0c
This makes it easier to fetch messages without having to manually
call inLanguage() on each wfMessage() call, which is currently
causing some code forget this and use plain wfMessage() which
defaults to MediaWiki user language from session.
I've considered setting $wgLang or RequestContext::getMain(),
but that's still bad since modules get passed a context in their
methods and shouldn't be using global context either.
The warnings provided by MW_NO_SESSION are exactly what we want.
Change-Id: I1288fa5622d9f82d21bb66c8eb6518b90e7cddb4
Remove optimization that avoids unstubbing $wgUser because $wgUser
is not a plain object for the current user name.
It's a stub with mFrom='session' until methods are called that need
the info, such as getName(), which then lazy loads the object based on
the session information.
We want to make load.php session-less.
Bug: T127233
Change-Id: Ica482e5d1892cb29456e6f2a91cd70017cf414c5
* Add logger to ResourceLoaderContext for convenient use within modules.
* Group related members within ResourceLoaderContext.
Change-Id: Ifbc3de1b6e0838386735f1573df328d9b331ac37
This parameter was introduced last year as a way to extract
bare scripts from modules without any 'mw.loader.state()' suffix.
When ResourceFileCache is used ($wgUseFileCache) this causes
cache pollution as it didn't include getRaw() in the hash.
Change-Id: I7b9f9b6a5756777462395b911abafb62468cbefa
