implode is documented as taking a string[], not mixed with int or null.
Explicitly cast or remove those instead of the implicit handling by PHP.
Change-Id: I0fac52c861bf85e09571b61a899b7a041aa77914
Since $wgSkipSkins is meant to only 'remove skin from preferences',
it should not affect parsing with them.
So these skins need to be allowed here.
To achive this, this patch adds getInstalledSkins() method to SkinFactory
to provide the complete. The method supersedes getSkinNames() which does
the same thing but with ambiguous name.
Description of getAllowedSkins() has been corrected as it was slightly incorrect.
Bug: T237856
Change-Id: I0889b823d27f1a2830cc0205f5a21ed4de744e08
Un-mark as @internal. It's a useful function for extensions that have
custom modules.
Example uses:
* Id8de16ab683948eae096b43462118ea837f53038
* Ia16dad8b6c450f4cb095a67af1c1c2b487e8536b
Change-Id: I03f0e7190fab62cd7e5c6a504a564142d0a9800d
The canonical way to enable debug mode is and will remain
through via 'debug=true'.
During the transition debug=2 will opt you in to the experimental
newer way. Anything that needs to be pinned to the old way for
compat can already start doing so by using debug=1 explicitly.
Once v2 is "ready", the default will flip and debug=1 will remain
for the foreseeable future to trigger the legacy behaviours.
Bug: T85805
Change-Id: Ieaf04e0c289646dd5d5b027b4f1f8278167b2d57
* 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
* 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