When I was testing for caching in RL, I realized file cache is
completely broken and mostly useless, specially for not taking into
account new query parameters and thinking basically all RL modules are
uncachable.
Let's just remove this.
Bug: T330576
Change-Id: I5b17bfc4c5543bd0e96e1099c87341ddf8fd6572
This is an intermediate step towards the linked bug, to help untangle
the performance impacts.
Bug: T343407
Change-Id: I086f173f811fb44683f4a67bf6bc415d7e27f593
The "nonce" CSP feature has been never been properly tested and is not
on track to be enabled at WMF or in MW by default. The use of
nonce-protected eval is not particularly meaningful. It is trivially
bypassed by mw.loader.implement, mw.loader.store, or importScript();
all of which allow any code to be executed directly, or to be stored
and loaded from a first-party origin.
The "nonce" feature is not required for the T208188 roadmap, and with
change I51b8535b2b21a3 there is now also a (small) performance reason
to keep this disabled long-term.
Until and unless there is a plan for enabling this particular aspect
of CSP, we might as well remove it so that we don't waste time our
time building abstraction layers and satisfying dependency injection
through many years for something that might never be used.
Note that this does not remove CSP support from ResourceLoader, and
does not take away from the future of enabling CSP in MediaWiki to
e.g. strictly block third-party scripts, or to require domains to
opt-in by site config or user pref (T208188).
Change-Id: I5a176c41a06a484a11e64bdacdc42b40811fe72e
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
The only remaining references to the Xml:: versions of those methods are
in doc comments and in HISTORY.
Bug: T341779
Change-Id: I004a925f80ae23eff2c078c95b8caa8ccf64ffd2
These methods really belong in the Html class, not Xml. Leave behind
soft-deprecated Xml methods that forward to the Html ones, as well as a
class alias for HtmlJsCode (renamed from XmlJsCode).
Bug: T341779
Change-Id: I99a5f9de1411d4eb5ee30226b4e8ace3ea8b2c3b
Reuse the existing loop over modules to trim each module definition
Also remove a by-ref which is not used (was added in c0c221bf)
Change-Id: Ia3560694ccee4ce95607809d51097b3fd10d79aa
The conditional here was handling two different cases, exceptions
thrown with $errors, and versions out of sync.
Bug: T321394
Change-Id: I0b861dbac4d497c974244da7e9f444e3683e9032
The Hooks class contains deprecated functions and the whole class is
going to get removed, so remove the convenience function and inline the
code.
Bug: T335536
Change-Id: I8ef3468a64a0199996f26ef293543fcacdf2797f
Send a message to Logstash when this condition is reached.
It is expected that this happens for a portion of clients during the
5min after a deployment, such such use an informational message,
not a warning.
This level is already enabled in wmf-config for channel=resourceloader.
I'm adding this now as I'd like to rule out or confirm whether the
our own CDN caching plays a rule in the corruptions reported at
T321394. If so, we can dig deeper there. If not, then we're likely
looking at a problem relating to browser extensions, Wikipedia mirrors,
or user scripts; rather than something under our own control.
Bug: T321394
Change-Id: Iad2f5189da33551b59653c2a6783419d6ad955d0
Follows-up I992ccde79a59ad51c.
* Soften the test to only asserting that an exception is thrown,
the type isn't part of the API.
* Throw RuntimeException instead of MWException per T86704.
Bug: T86704
Bug: T328602
Change-Id: Ifaa5d659941d60789ca14f771648e5830bbef317
Confirm that load.php can respond for all registered modules without
errors (except private modules, which can't we don't serve there).
Bug: T47514
Change-Id: I44655b2c05529ae719d71622f57bfed8d632550e
* Document `$scripts` types in a list for clarity, and make the
end-to-end connection to what these are for in practice (especially
for debug mode, and for site/user scripts).
* Fix outdated `$styles` docs. This has changed long ago.
* Remove support for $messages array. This existed solely to pass
an empty value for cases where messages are not needed.
Change that to null instead.
Change-Id: I0c0ef94d830171a3dd8588de8c4a1f3d67607d41
Importing Less files from @wikimedia/codex-design-tokens/ doesn't work,
on purpose. Instead of letting these imports fail with a nondescript
"file not found" error that doesn't help the developer understand why it
didn't work, provide a descriptive error message that points them in the
right direction.
Bug: T328602
Change-Id: I992ccde79a59ad51c7ebfe3ac7548a6e531f4a59
This replaces the hacky wrapper files in
resources/src/mediawiki.less/mediawiki.skin.codex-design-tokens/ and
resources/src/medawiki.less/@wikimedia/codex-icons/dist/ with real
import path aliasing/remapping.
Bug: T328602
Change-Id: I2df266cde90d1b8dad8d1d1367b67001e2b2984d
* Unnecessary regex modifier. I agree with this inspection which flags
/s modifiers on regexes that don't use a dot.
* Property declared dynamically.
* Unused local variable. But it's acceptable for an unused local
variable to take the return value of a method under test, when it is
being tested for its side-effects. And it's acceptable for an unused
local variable to document unused list expansion elements, or the
nature of array keys in a foreach.
Change-Id: I067b5b45dd1138c00e7269b66d3d1385f202fe7f
The $modules param is user controlled. We already catch invalid UTF-8
in server configurations. If something like that makes it here, the
only place it can come from is the client doing it intentionally,
such as the result of scanning tools.
Follows-up I89832142b, which silenced $modules formatting in a CSS
response. This patch also covers the case of a JS response, and adds a
test for both.
Bug: T331641
Change-Id: I03a0ec262203509f069654e7fa6fd8d8debd25d5
Use this class to track the entry point and handler used for requests,
making it available for use in profiling, stats, and logging code.
This makes it possible for periodic and/or shutdown profiling callbacks
to know the basic action handler that applies to the request (if any).
Metric names can easily include this string along with MW_ENTRY_POINT
to create per-action profiling dashboards.
This info cannot otherwise be acquired from things like excimer stack
traces since the router and handler classes do not appear in the stack
during PRESEND deferred updates and variations like ApiMain/SpecialPage
"inclusion mode" would have to be detected somehow.
Bug: T330810
Change-Id: Icca5a7a343faeeb18652994c96752acb61a61fd1
Follows-up I89832142b55ec0f for T329330. encodeJson() is almost always
called with data that a core component or extension was responsible
for processing or generating. There is one exception that I know of,
namely within ResourceLoader itself, where we report back the name of
a load.php?modules parameter value if it doesn't exist or is invalid.
In that case, silence the newly added warning from encodeJson() since
the audience for that error is not the developers working on the code,
but the user making a badly formed URL. And the warning was coming
from the exact code formulating that same error message.
Bug: T331641
Change-Id: Idcccb979c89ef837546892ab786d803d429ecda5
Has been marked `@internal` since initial commit, with no references
outside this class in Codesearch Everywhere. The method relies on global
state in the form of $wgRequest, via ::inDebugMode.
New code can (and does) uses RL\Context::encodeJson() instead.
Bug: T32956
Change-Id: Ia5f3da26f4ee6dd5f49eb1869653fa7c3ce90e3a
This was originally an internal method for ResourceLoader to create
the load.php?only=messages response. This was removed in 2015 with
change Ia6c87d687c6 (9b6ee1da59) in MW 1.26. After that it was
briefly used by RCFilters until change I2d58f55701 (2dd6342b64)
in 2018.
It has no known use in Codesearch Everywhere, no test coverage,
and relies on global state (including $wgRequest, via ::inDebugMode).
Bug: T32956
Change-Id: I49d71aa319c571cfefc9bcb459cd97047eb6d839
so that extensions (i.e. CheckUser) can implement their own comment
store without having a lot of code duplication
basically the comment store version of I3a6486532f2ef36
Bug: T233004
Change-Id: Ib40f99e00a514d41776ce521baf113e46d37e9cd
Patch Ifa7a9bc replaced some longer `=== null` constructs with the
new ??= operator we have since PHP 7.4. However, some of these can be
simplified even more with the ?? operator we have since PHP 7.0.
Follow-Up: Ifa7a9bc7b2ec415ad7ecb23f4c1776f51f58fd6b
Change-Id: I7b05e723810558bb5437adc97eab54ca04d38c06
None are used in WMF-deployed extensions and have been hard deprecated
for multiple releases as well.
Change-Id: I62cfa22291f81295b4908192de8657a750c6716d
Remove workarounds for the lack of proper autoloading for aliased
parameter type declarations which was fixed in PHP 7.4.
Change-Id: Ic4485d06e7ad8d02859dc3e5c67867c4b084386f
Only enable it if maxage is above 1 minute in the first place, e.g.
not for debug/error responses or when otherwise having configured
things during development with a very low maxage.
This gives blocking resources like the startup manifest and stylesheets
a chance to never block page rendering other than during the first
view of a browsing session. Once a browsing session reaches the 5min
mark, instead of blocking the next page load, it could then be renewed
in the background if the pageview starts during the 6th minute.
CDNs and web proxies known to support the stale-while-revalidate
directive:
* Varnish 4.1.0
* NGINX 1.11.10
* Squid 2.7
Browsers known to support it:
* Firefox 68 (2019)
* Chrome 75 (2019)
Bug: T132418
Change-Id: Ifae1f09722be4abf1c4dfe895122a3503010a422
The getCombinedVersion() method itself already catches errors
in its loop. There are no known exception that we know can happen
and would want to tolerate within the loop logic itself.
Empirically, there are indeed zero messages in WMF Logstash for the
past 30 days that contain "Calculating version hash failed". Other
diagnostic messages in channel:resourceloader do show up from time
to time, e.g. once a week or so, indicating that the other
conditions and this log method generally do work and are enabled.
Bug: T312806
Change-Id: I2fe5ad104a6404c53c1b73b259468a6ed1071936
Follows-up I4c3770b9ef. While timeouts in load.php are extremely
rare (one in 90 days?), we did find one in the perf-team Logstash
dashboard and it coincided with this runtime error as result of the
added try-catch:
> PHP Notice: Undefined variable: etag
Remove the try-catch and let these fatal the same way as other very
early or very late errors with HTTP 500 instead.
Bug: T312806
Change-Id: Iffb238de2243d0885dcf1d78fcce7827b09cb84d
