This moves the preview logic that was part of
mediawiki.action.edit.preview.js into a dedicated module with a JS
entrypoint so it can be used by other systems such as the upcoming
Real Time Preview.
Bug: T294319
Change-Id: Ifbd57a74375c556bf09d5eee40c2d6396062d1a0
Application logic should use the BaseDirectory config variable.
Framework code should use MW_INSTALL_PATH to locate files should.
NOTE: Update https://www.mediawiki.org/wiki/Manual:$IP
Bug: T300301
Depends-On: I7142af16d692f26e90673b058029f572c1ea3991
Change-Id: Ib4caa80bb7007c4c7960a2fd370cf5da7d9ba344
* Use lower case without a full stop
* Use standard muted colour for secondary information. The
red warning colour is still used on the param page itself.
Change-Id: I734a2f31f9139b8415bd61dcbe0561232e2632ee
This way code like require( '@wikimedia/codex' ) will work both in
ResourceLoader and in Node.js (needed for local development setups and
unit tests).
Not adding a backwards compatibility alias for 'codex' because nothing
uses this module yet.
Bug: T299148
Change-Id: I50c62397ce61bdda66cdf39506baf19a225eec9c
Further unifies our message displaying system.
The 'postEdit.afterRemoval' hook is deprecated as it is of little
value, makes less sense when we aren't sure when the notification
will close, and is rarely used.
Bug: T58313
Change-Id: Iec031de7aa8c09091b811530a45758b53638372f
Creates a new RL module for polyfilling modern Web APIs (as opposed
to modern syntax support / language features).
Moves the recently-created Intersection Observer polyfill module into
a new module, "web2017-polyfills". The fetch polyfill has been retained
as a temporary alias, and can soon be removed in favor of the new
web-2017 module.
Bug: T301489
Change-Id: Ic8a7f4f892722b77252ad6db45c73598833a8c65
Previously they were only marked as such in the detailed descriptions
hidden behind the [Expand] buttons, which no one clicks. (Deprecated
modules were also marked with a line-through in the dropdown list.)
Now they're also marked in the dropdown lists (which you have to
click) and in the descriptions (which you have to see).
Change-Id: Id19f0804c6b2ddf8d507561b5dfa69b15f7fd90f
Adds the latest version of the W3C Intersection Observer polyfill from
NPM for usage within MediaWiki.
https://www.npmjs.com/package/intersection-observer
Bug: T300912
Change-Id: Ie11d06e977012fb5c3b0b1b6e7c7d3458bf0e409
The fields were using `box-sizing: border-box`, which meant that our
carefully calculated width was reduced by the browser-defined padding,
which caused the expected number of digits not to fit.
Also:
* Fix width calculations for digits to not apply the Internet Explorer
hack to other browsers.
* Fix width calculations for non-digits to make them slightly larger
(both the `if` and `else` branches were identical in 2 places out of
3, that was probably a copy-paste mistake).
Bug: T299618
Change-Id: I3aa15ba8ed2380d34051a27daaa4946c8abdf7c6
Provide backward compatibility in Vue.createMwApp() for the store
option. Vuex 4 expects Vue.createMwApp(...).use(store), but code written
for Vuex 3 will do Vue.createMwApp({..., store: store }) instead.
Unfortunately, it doesn't appear to be possible to provide backward
compatibiltiy for new Vue( { ..., store: store } ) . I can't find a way
to access the underlying app instance.
Bug: T289102
Change-Id: I21641827780f4a7d8a5196c7dab14fbc3e4f4175
* 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
Deprecated in 9e712c which shipped in MW 1.28.0. The last production use,
from the Collection extension, was removed in f3f4bb4; no non-production
use show in codesearch (except for a copy of the Collection extension).
Bug: T143034
Change-Id: I14cc197be5abcec41cd0905a85236abefc188a66
== 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
This way the RL module name matches the NPM module name, and code from
NPM that expects to be able to call require( '@vue/composition-api' )
will work.
Backwards compatibility is not needed because codesearch shows zero
instances of this module being used. Its only usage is in a patch in
MediaSearch that hasn't been merged yet.
Bug: T284707
Change-Id: I457dd97f00d3cbf1edb57cf61cf80afd57a1e2a7
Feature code that needs the composition API will need this as long as
we're still on Vue 2. This will also help migrate to Vue 3 more
seamlessly, as working around some breaking changes in Vue 3 requires
using the composition API.
Bug: T251974
Change-Id: I8e334ae5f447a8f9b64a7c910b2c1776cef118db
The message wgEditMessage can contain code for the extension
ParserFunctions which is not supported by mediawiki.jqueryMsg.
This change updates only the title in the firstHeading instead of
creating the whole message including the title again. The title gets
identified by a new HTML element with id="firstHeadingTitle".
The title in the HTML title gets not updated anymore. For a preview of
the display title the title in the firstHeading should be enough.
The 6 messages
'creating',
'editconflict',
'editing',
'editingcomment',
'editingsection',
'pagetitle'
are not needed anymore in JavaScript and removed from the module.
The global JavaScript variable 'wgEditMessage' is not needed anymore in
the live preview module. Other user scripts uses this variable and
therefor this variable is kept for compatibility.
Bug: T105214
Change-Id: I8d8dc79c6bf1a94a55f1d0f6b5611ca478fd9e18
This change fixes the following differences and bugs compared to the
normal diff:
* On an empty change the API response contains no `main` in
`response[ 0 ].compare.bodies`. Remove the previous diff and show a
'diff-empty' message in this case.
* The header with 'currentrev' and 'yourtext' is missing. Show this
message similar to the normal diff.
The HTML in the diff of the live preview is not exactly the same as in
the normal diff:
* The live preview has now <thead> and <tbody> elements.
* The live preview has always 4 columns.
Bug: T293307
Bug: T293597
Change-Id: Ibb4fccb74634094ffeabf6fe201257d747bb8a01
mw.widgets.datetime.DateTimeInputWidget() uses the "clear" OOUI icon but
the "interactions" OOUI icon module wasn't declared as a dependency,
leading to an invisible clear button unless the module was loaded
elsewhere.
Bug: T283129
Change-Id: I5aef30a7b5f4f3286e3f5b459b675204b1233fea
After the mediawiki.rcfilters.filters.(dm|ui) modules were merged,
mw.rcfilters.js was just `require`ing the old init script to run some
extra setup, no need for separate files.
Bug: T256836
Change-Id: I6462151152d075af0ef8bce3a5edf0a0ba48761a
The new module retains the name .ui name so that existing
skin style overrides continue to work. We can consider renaming it
to just "mediawiki.rcfilters.filters" in a future patch.
This does not handle file reorganization, since both of the
modules used package files - instead, in the main script we also
require() the old main script for the .dm module so that its
setup code runs. But, we did need to rename the virtual
config file from the .dm module to not clash with the
virtual config file from the .ui module, since the
latter uses a callback instead of retrieving configuration
variables directly. These can be merged later as well.
Bug: T256836
Change-Id: I5ec0af8b8e6bcdba6b7881f946f777b854a33739
Inject `wgForeignUploadTargets` and `wgEnableUploads` via a
virtual file instead of always adding them to mw.config.
Added a comment about them in the release notes since wgEnableUploads
was used by an (undeployed) extension, but we can make the
breaking change because their inclusion was marked as
@internal.
Bug: T292017
Change-Id: Ib1635b1864963c6c03c4a80e15048a898b8eaf90
