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
I don't recall why I added this. Possibly in a confused effort
to match /tests/phpunit, except /tests/phpunit/suites is not
where test cases live, they live under /tests/phpunit/* directly,
mostly /tests/phpunit/includes named after the source directory.
The correct equivalent to that is /tests/qunit/resources for JS.
While at it, also remove mention of this concept from various other
places where it doesn't add value. It's one more word/concept to
learn, process, understand, or translate mentally. They're just tests,
or for the one or two places where we care about how they are
internally transmitted, a "test module".
Bug: T250045
Change-Id: I5ea22e4965d190357aa69883f29f9049ee8ebf13
== Background
When file dependency information is lost, the startup module computes
a hash that is based on an incomplete summary of bundled resources.
This means it arrives at a "wrong" hash. Once a browser actually asks
for that version of the module, though, we rediscover the dependency
information, and subsequent startup responses will include arrive once
again at the same correct hash. These 5-minute windows of time where
the browser cache of anyone visiting is churned over are not great,
and so we try to avoid them.
The status quo is the dedicated module_deps table in core with no
expiry. This means a potential concern is building up gargage over
time for modules and extensions that no longer exist or are no longer
deployed on that wiki. In practice this has not been much of an issue,
we haven't run the cleanupRemovedModules.php or purgeModuleDeps.php
scripts in years. Once in 2017 to fix corrupt rows (T158105), and
once in 2020 to estimate needed space if we had expiries
<https://phabricator.wikimedia.org/T113916#6142457>.
Hence we're moving to mainstash via KeyValueDepStore, and not to
memcached. But for that we might as well start using experies.
To not compromise on losing dep info regularly and causing avoidable
browser cache for modules that are hot and very much still existing,
we adopted `renew()` in 5282a0296 when drafting KeyValueDepStore, so that
we keep moving the TTL of active rows forward and let the rest naturally
expire.
== Problem
The changeTTL writes are so heavy and undebounced, that it fully
saturates the hardware disk, unable to keep up simply with the amount
of streaming append-only writes to disk.
https://phabricator.wikimedia.org/T312902
== Future
Perhaps we can make this work if SqlBagOStuff in "MainStash" mode
was more efficient and lenient around changeTTL. E.g. rather than
simultanously ensure presence of the row itself for perfect eventual
consistency, maybe it could just be a light "touch" to ensure the
TTL of any such row has a given minimum TTL.
Alternatively, if we don't make it part of the generalised
SqlBag/MainStash interface but something speciifc to KeyValueDepStore,
we could also do something several orders of magnitudes more efficient,
such as only touching it once a day or once a week, instead of several
hundred times a second after every read performing a write that
amplifies the read back into a full row write, with thus a very large
and repetative binlog.
== This change
As interim measure, I propose we remove renew() and instead increase
the TTL from 1 week to 1 year. This is still shorter than "indefinite"
which is what the module_deps table does in the status quo, and that
was never an issue in practice in terms of space. This is because
the list of modules modules is quite stable. It's limited to modules
that are both file-backed (so no gadgets) and also have non-trivial
file dependencies (such as styles.less -> foo.css -> bar.svg).
== Impact
The installer and update.php (DatabaseUpdater) already clear
`module_deps` and `objectcache` so this is a non-issue for third
parties.
For WMF, it means that the maintenance script we never ran, can
be removed as it will now automatically clean up this stuff after
a year of inactivity, with a small cache churn cost to pay at that
time.
Bug: T113916
Bug: T312902
Change-Id: Ie11bdfdcf5e6724bc19ac24e4353aaea316029fd
