There are now 4 types of logos, only one of which is needed.
Update documentation in installer to reflect this.
Also make it possible to drag and drop files into the installer
and see live previews of what the logos will look like to aid
setup.
The 1x is no longer required.
Bug: T255913
Change-Id: I58226ae8fb02c32d2eeea65a50aaabbc193cb51c
* Explain the optimisation in this method.
* Improve overall docs.
* Bring the getTitleInfo() fetch closer to where it is needed,
which is also a micro optimisation in itself by not fetching
in case of the early return (though that's a rare case).
Bug: T299288
Change-Id: I104cf20ab5a944ec382c5807e8bf1bf18979d426
This adds support for the `exports` alias for `module.exports`, but only
to package modules, per the discussion on T284511. This makes it easier
to use external libraries that use UMD, since UMD tests whether
typeof exports === "object", and if not, it adds the library to the
global scope instead of exporting it.
This is a breaking change for package modules that were expecting
exports to be undefined; in practice, this means modules that were
expecting UMD wrappers to add to the global scope have to be updated to
expect it to export the library instead. However, most UMD wrappers in
MW core are in non-package files, which are not affected by this change.
The affected libraries are updated accordingly:
- Codex used the global scope. This library is very new and nothing uses
the global window.codex variable yet, so we don't need to provide
backwards compatibility for it.
- Pako was patched to have its UMD wrapper look at module instead of
exports; remove this patch since it's now unnecessary
Bug: T284511
Change-Id: Ie2e965cee001fb7f10b2b3e3f796d9511f6b63d2
Helps reduce the size of the user.options module by not adding options that are
unlikely to be of use in JavaScript.
Bug: T251994
Change-Id: I7701d094a3e905edeab7571dca34db5b20a13d68
Don't catch and discard exceptions from the RequestTimeout library,
except when the exception is properly handled and the code seems to be
trying to wrap things up.
In most cases the exception is rethrown. Ideally it should instead be
done by narrowing the catch, and this was feasible in a few cases. But
sometimes the exception being caught is an instance of the base class
(notably DateTime::__construct()). Often Exception is the root of the
hierarchy of exceptions being thrown and so is the obvious catch-all.
Notes on specific callers:
* In the case of ResourceLoader::respond(), exceptions were caught for API
correctness, but processing continued. I added an outer try block for
timeout handling so that termination would be more prompt.
* In LCStoreCDB the Exception being caught was Cdb\Exception not
\Exception. I added an alias to avoid confusion.
* In ImageGallery I added a special exception class.
* In Message::__toString() the rationale for catching disappears
in PHP 7.4.0+, so I added a PHP version check.
* In PoolCounterRedis, let the shutdown function do its thing, but
rethrow the exception for logging.
Change-Id: I4c3770b9efc76a1ce42ed9f59329c36de04d657c
This change exposes the requiresES6 flag to the public API,
specifically via getState() by not registering modules that
aren't available / can't be loaded in the context.
This actually simplifies the code a fair bit, and partially reverts
the added logic from I45670c910ff12.
Bug: T299677
Change-Id: I96a03796628a74ace93579d45a582711400c09c1
If a skin e.g. Minerva is using an opt-in policy then it has already
decided what features to load. It should not be subjected to features
it hasn't requested.
This was leading to content-external-links being loaded in Minerva
since 8c1afd97a3.
Bug: T298433
Change-Id: I621621bc2d30ee9ce00decbdee0f55c4db65abc1
* Enforce the ban on is_resource in phpcs
* In OrderedStreamingForkController, the comment was incorrect. I
confirmed using a small test script that if the child closes one end
of a socket pair, the other end will still be open, and is_resource()
will still return true, and fclose() will not fail. The issue was
introduced in c82d30d19c, it was not present in the
CirrusSearch copy of the class.
* Allow is_resource() for debug logging.
* Allow is_resource() for parameter validation where a stream may be
passed to a function, since there is no alternative.
Bug: T260735
Change-Id: I59a752f7bb4b043ddfb2434b52a02f9221bf54db
== What ==
Change debug mode 2 to behave more like production mode:
* use module scope (no longer global scope).
* load modules concurrently (no longer each module serially).
* bundle files (no longer each file separately).
What remains different in debug=2 from production mode:
* disable minification.
* disable batching (one module per request).
== How ==
* Limit the old logic (getScriptURLsForDebug) to just legacy debug.
* Set maxQueryLength=0 for non-legacy debug, to ensure each module
still gets its own dedicated request for easy debugging, and to
get concurrency to make more optimal use of server and browser
capacity.
This does not effect package file modules much, as those already
worked in this way. The only difference for package file modules
is that they now load faster (see below) by eliminating the
in-between request.
== Alternative approach ==
An alternative approach, which I considered, is to modify
Module::buildContent(), around where we currently call
getScriptURLsForDebug for DEBUG_LEGACY, and add a conditional branch
for DEBUG_MAIN which would always return an array with a single URL,
to `load.php?modules=:name`. Much like getScriptURLsForDebug does by
default, but without the legacy-specific overrides to that method from
e.g. FileModule.
I decided against this because the mw.loader client handles such
script-arrays in a global FIFO fashion, tailored for legacy debug mode
where it crucial to only serially queue>load>execute one script file
of one module at any given time (because the raw files can't have a
"mw.loader.implement" closure and thus execute immediately on arrival,
with no other coordination for file order and module dependency order).
This would make debug=2 slow, possibly slower than debug=1 since in
debug=1 at least we consolidate most PHP roundtrips in a single batch,
and most other scripts can be served quickly as static file by Apache.
By letting the client act like it does for production mode, and
proactively split its requests, we get a few benefits compared to
this alternative approach:
* Fewer requests and shorter request dependency chain.
There is no in-between request for the "page module batch" that fans
out to individual module reqs. Instead, the client makes those reqs
directly.
* All module requests are discovered and queued with the browser in
one go, letting the server handle them as quickly as it can.
In production, probably all in parallel. Locally, mediawiki-docker
seems to handle about 6 at time (this depite having 10 php-fpm
proccess). I suspect that maybe due to a poor interactions between
HTTP1 connection reuse and keep-alive timeouts, or perhaps unneeded
session locks with sqlite.
* The browser can spend time parsing/compiling other requests at the
same time as one of them executes.
* No additional client-side logic.
* No increase in client payload.
Bug: T85805
Change-Id: I232310eb624e0204484ec9f3d715d5b6b8532fe8
* Use the int result of `ResourceLoader::inDebugMode()` directly in
SpecialJavaScriptTest so that debug=2 is passed on to the next
request, like it does on regular page views.
This is likely temporary, because
part of T85805 is to make debug=true default to debug=2, and
part of T250045 is to hardcode debug=2 for JavaScriptTest.
* Add a few line breaks to improve HTML output readability in debug
mode. This is a no-op for prod as they get minified away.
Today I learned: PHP string heredoc and nowdoc syntax strip not
only the shared common indentation (which I knew), it also strips
the first and last newline. Hence, switching ClientHtml to use
double quotes.
* Document the order in which lang/skin/debugScripts execute.
Bug: T85805
Bug: T250045
Change-Id: I2ad179401cee6cf6ba30c0b462f0d48a8529ba74
The docs for wgResourceLoaderMaxage still described the "server"
and "client" subkeys, which have not existed since MW 1.35. This
was essentially a new configuration structure, add the `@since`
annotation to reflect this.
Clean up the ResourceLoader class and group together related class
members in a more logical way. Currently going for what I see various
other core components do:
* Constants: public, then private.
* Static: public, then private.
* Members: public (none), then ctor-assigned/injected stuff, then
those with defaults that start as-is.
Make most protected members private, except for those intentionally
made protected for use in tests. This class is not meant to be
extended, is not marked as stable for that purpose, and Codesearch
shows no extensions that do so.
Remove unused internal '$testModuleNames' field. This was removed in
5f47d994bc and accidentally reintroduced (unused) with 440dfcf6d8,
presumably due to a bad rebase.
Bug: T32956
Change-Id: I041a320d05c9e5f30ac9cc9270ce82c4d19a957f
Packaged modules don't support URL-loading. It leads to two mw.loader.implement() calls with the same module name, giving an exception.
A similar override of supportsURLLoading() is already being done in ResourceLoaderFileModule.
Bug: T198758
Change-Id: Id4589a597ccfc4266b3e63d10f75b146aa7a287a
We upgraded to version 2.2.6 of wikimedia/minify a few weeks ago, but
broken minifications from that version have lingered in the minification
cache. Bump the cache version to fix this.
Bug: T296058
Follows-Up: I6bceffda0c7ff4f4d92e15e85ae8719426ff4c3f
Change-Id: I7560c8ae54f3132cb33e8823dbfb467fef0cfc31
* Magnify clip isn't present in print styling
* Print and screen thumbborder are different
* Print thumbinner and thumbimage borders are absent
Bug: T287965
Change-Id: Ie1dac57412da7da3e73eb39ef20a6077923860d6
* Upgrade Vue to @vue/compat version 3.2.23
* Migrate Vue.createMwApp to Vue 3 API
* Add backwards-compatible wrapper emulating Vue 2 behavior for
new Vue( { el: '#foo', ... } ) and
new Vue( ... ).$mount( '#foo' )
* Make @vue/composition-api an alias for vue, for b/c
* Convert resources/src/vue/ to ES6
* Ignore resource/src/vue/ for jsduck, since it doesn't support ES6
* VueComponentParser: Remove check for only one root node
Bug: T251974
Co-Authored-By: Lucas Werkmeister <lucas.werkmeister@wikimedia.de>
Depends-On: Ica0c0d0d6247383796d39199e50a9aff917f5b53
Change-Id: Ibd618765f962f57984994604c61b1aff9e6a778d
Follow up to I076fddda07dd734f76277376ba6361bff68b7c36
Also, adds a comment about -legacy being frozen.
Change-Id: Iced54fb31c967975248bfc9908d904fa41824307
This allows the backend to do whatever it can to ensure atomicity, and
is also easier to read, since the intent is obvious.
Change-Id: Ibbfecd92a2c6d9a5997ca37ea101e068bd1e8202
== Background ==
The `user.options` module is private, and thus has to be embedded in
the page HTML. This data is quite large. For example, on enwiki the
finalized mw.user.options object is about 3KB serialized/compressed
(7KB uncompressed).
The `user.defaults` module is an implementation detail of
`user.options`, and was created to accomplish mainly two things:
* Save significant data transfers by allowing it to be cached
client-side without being part of the article.
* Ensure consistency between articles and allow faster deployment of
changes, by not being part of the cacheable article HTML.
All our pageviews already load `user.defaults`, as a dependency of
the popular `mediawiki.api` and `mediawiki.user` modules. These are
used by `mediawiki.page.ready` (queued on all pages), and on Wikipedia
these are also loaded on all pages by ULS, VisualEditor, EventLogging,
and more.
As such, in practice, bundling "user.defaults" with "mediawiki.base"
will not cause the data to be loaded more often than before.
== What ==
* Add virtual "user.json" package file with the same data that
was previously exported by ResourceLoaderUserDefaultsModule,
and pass it to mw.user.options.set() from base module's entry point.
An alternative way would be to use a "user.js" file, which would
return a generated "mw.user.options.set()" expression. I went
for exporting it as JSON for improved maintainability (reducing
the amount of JS code written in PHP), and because it performs
slightly better. The JS file would implicitly come with a file
closure (tiny bit more bytes), and would then be lazy executed
(tiny bit more time).
The chosen approach allows the browser to compile the JSON
off-the-main-thread ahead of time while the module response downloads.
Then when the module executes, we can reference the JSON object
and use it directly.
* Update internal dependency from `user.options`.
* Remove `user.defaults` module without deprecation. It is an internal
module with no direct use anywhere in Git (Codeseach), and no use
anywhere on-wiki (Global Search).
Change-Id: Id3916f94f75078808951863dea2b3a9c71b0e30c
The null check for the class property packageFiles needs change to
check the return value of the function instead, because Phan would
report an issue that a null value is used in the foreach.
Phan does not understand the relation between the return value and the
class property.
When using a local variable then Phan can check
that the value is never null when used.
Change-Id: I48ac8a8fe55ae7b4e13bc94d2f2d2ede01fbc68b
This private method checked for debug mode, and generated the wrapping
code in either spacious form or condensed form.
The important thing to note is that $scripts being wrapped here are
always in original form, and thus the returned string still needs to
be minified before we transfer it to the client.
The only caller is makeModuleResponse(), which passes the result
to filter() for minification as-needed. Hence we don't need the extra
complication here of manually minifying it for production, we can let
the minifier take care of that instead.
Bug: T32956
Change-Id: I80559c0c257bf5c08c015373d845a6c992dc9e0b
== Why and what ==
It is important that we don't cache the result of minifying the
`user.options` blob, because it varies on every page (details below).
But, it is okay to minify it.
Today, we don't minify it because the only content of this blob is
one line of JSON, and that JSON is already generated without spaces.
I would like to start minifying it so that:
1. The "mw.loader.implement" wrapper will get minified. Right now
we maintain a copy of the wrapper that is minified by hand. In the
next patch, I will remove this, which will introduce whitespace
for "user.options" unless we enable the minifier.
2. We can remove more complexity and state internally without worrying
about whether it will still be minified.
3. We can make the output even smaller by not having to preserve the
`/*nomin*/` instruction behind. This instruction is used today
mainly for cases where minification might break the output, so it
is important to preserve in case it is concatenated and passed to
the minifier a second time later. But, for user options we don't
need this protection, and so we can save a few bytes by removing
this instruction at the same time.
== Background ==
Act 1
In 2014, with task T84960, we determined that caching of `user.tokens`
minification is problematic for system stability and also not useful.
* This module contains security tokens that are different for every
pageview and for every user. This means every time we generate a
web response, we have different tokens, and thus generate different
<script> content, and thus there is no use of caching the result,
because we would never use it. The next time we get a different
script, and will have to minify it again. That's okay, it's small
and takes no time at all to minify.
* If we stored it in the cache, it would not only be useless, it would
also compromise the effectiveness of the php-apcu cache for all other
parts of MediaWiki, because when APCu is full, it will have to delete
unrelated caches to make space, thus causing more calculations to
be repeated in other places.
In commit 6fa48939 (I6016e4b0) we simply changed the script generation
to disable caching when minifying the private 'user.tokens'
module, which solved the task.
Act 2
In 2015, with commit b7eb243d92 (Id6f514206), the minification logic
was changed from "per response" to "per module within response",
and as part of that the logic was also generalised from being just
for `user.tokens` to be for "private modules", which is essentially
the same (since user.tokens is the most common private module), but
was preparation for a few other things:
* Some extensions (like AdvancedSearch) also create their own private
modules and thus benefit from this automatically.
* In later years we would add support for previewing user scripts
and gadgets, which turns a public module temporarily into a private
one to be able to execute it with the previewed script content.
These also don't need to be cached, and this correctly disabled
caching for those.
* We have "user.options", which is similar to "user.tokens", but does
not change on every page view. It does not need to be cached
because it is so small that is about as fast to just minify it
than to go through the cost of hashing, keying and querying the
cache.
* We have merged `user.tokens` into `user.options`.
Act 3
Then, with commit ca30efa30 (Ic1d802ee20) this was automation was
removed in favour of the FILTER_NOMIN instruction which disabled both
caching *and* minification. The was accepted because we realized that
we don't need minification for the "user.options" blob because it is
just one line of JSON, and the JSON is already generated without
whitespace.
Change-Id: I6d125fc89d8964325ec068a0746b00810e155858
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
Do it self to avoid the global state of the Timing class within the
resourceloader.
Replaced the deferred update with a scoped callback to send stats on all
possible return path for the called function, but directly when needed
and not deferred, which can make wrong times.
The old code was using a fix mark set be
MediaWiki::doPostOutputShutdown, where a defered send does not has
impact of the send stats
Change-Id: I5fec6a73db3e7c3ac6a6ac33bb293727ae3a38ca
User::isRegistered is part of the UserIdentity interface,
which makes moving from heavy User class to UserIdentity easier.
Change-Id: If44bfd398694c509272b3f89c93473b2e3c05759
Since T192623 the startup code has used its own function,
domEval, instead of relying on the jQuery globalEval method.
Follow-up: Icdd5d76546a6c265a8e941c4e9b28f73bf9dd028
Change-Id: Ic1d0e02597c3e335acb7e0407e077dd4e62f3982
No longer used from there by the mediawiki.cookie module
No deployed javascript tries to use these, but a few undeployed
extensions do, so added to release notes.
Bug: T291760
Follow-up: I600332cdb738f0b443549948b9f070f3ccfa12aa
Change-Id: Ia02048137f191b950ae789a9d206c1d9afbce83a
