VisualEditor is usually not enabled in talk namespaces... but
sometimes it is. And when users see the button to edit with VE,
they're going to click it and expect to be able to sign their posts.
This tool is only loaded on talk pages and pages in additional
namespaces defined in $wgExtraSignatureNamespaces.
Code adapted with small tweaks from my own gadget
<https://meta.wikimedia.org/wiki/User:Matma_Rex/visualeditor-signature.js?oldid=13461327>,
which is already available under the MIT license.
Changes include:
* The tool is now always visible if the wiki allows signatures in any
VE namespaces, but disabled when not allowed in the current namespace.
* Register '~~~~' sequence to insert the signature.
* Code style tweaks for stricter lint checks in this repository.
* Documentation corrections.
Swedish translation provided by André Costa (already credited
as a translator as Lokal_Profil).
Depends on changes in VisualEditor core:
* I89fe53890ab59d12260ea6b41de802c38c24e8b9
* I14cd7efac521687ea38580341ae08ddc522edeeb
Bug: T53154
Change-Id: I6be5fb2118cf3eef5098d4c5320228aa81411ccb
Follows-up 28f3a02e56.
* Use mw.loader#getState() instead of private 'moduleRegistry'.
This property is not a supported API and may change at any time.
* Use plain push() instead of splice(). The order of modules
is insignificant as dependencies are enforced by module registry
only. Besides, the order is additionally normalised both
client-side and server-side by ResourceLoader.
Change-Id: Id9291c97c3bfc01c4cf203aa7b15629fb8412f5b
It's just as usable as the alien extension inspector which
is currently shown, and has better messages.
Change-Id: Ifbce9df4aff77cf76a8445158987be716ba45302
No retry right now, but we should at least stop failing silently. Doing this
in a window.alert() for now, as OOUI isn't available at this part of the
page load just yet (that will be coming soon).
Bug: T97041
Change-Id: Iacb195667215ee69d3991e4c41651ab6042243c5
This module is required in order to alienate all extension blocks
by default. Otherwise they are interpreted as plain divs which
allow content editable.
Bug: T103455
Change-Id: I08f6b9a516ba6bee6ed18256222108116eceee1e
We need it for the strip-if-empty logic in MWHeading,
and for consistency with desktop in general.
Bug: T96395
Change-Id: I9e70df896417811df087f58f3107919ba704f7c4
If70ff601 didn't really fix anything. The only reason you'd want this data is
to distinguish between mobile and desktop data, but it just set the value to
the desktop version always...
Bug: T95432
Change-Id: I76722e3ad8b7dbe644374b24093bec696f27f48c
Stripped out X-Parsoid Performance Headers, previously used to gather and
forward Parsoid's performance information, from ApiVisualEditor.php,
ve.init.mw.Target.js and ve.init.mw.TargetLoader.js. Change I936ada7b1 strips
out the corresponding X-Parsoid Performance Headers from Parsoid. Parsoid's
current performance instrumentation is achieved using Graphite and txstatsd.
Change-Id: I57d6f866a7d8287a5115e6236b0fb25bc4d0eabd
Also introduces paction=metadata in ApiVisualEditor which
doesn't hit Parsoid but gets all the other information we need.
Bug: T90374
Change-Id: I71edbc0f8dc15a6f8d3672c10ca3c641cc172be7
Move requestPageData from mw.Target to TargetLoader, call it
in init init, and pass the promise it returns into load()
via activate().
Bug: T90372
Change-Id: I828b8474e5a76b3d0d7d08735b4d865c29d2f820
This introduces TargetLoader, which manages plugins and RL modules
in a slightly more generic fashion so that Targets themselves don't
have to. This allows us to load all RL modules in one load.php
request, rather than first loading ViewPageTarget which then
loads the other modules.
TargetLoader loads in the bottom queue, so it will be loaded
as part of the main load.php request, but in VPT.init.js we
still have to wait for it with using() because it might not
have arrived yet. This also degrades gracefully on cached pages
where TargetLoader isn't in the bottom queue: it'll be loaded
as a separate request instead, which is suboptimal but no
worse that what we were doing before.
Right now TargetLoader is small enough that it could also be in
the top queue, but in the future we want to add things like
the action=visualeditor API request to it, and mw.Api is
relatively big.
Note: this also makes a breaking change to the plugin API:
plugin callbacks no longer receive the target instance
as a parameter, as they're now executed before the target
has been constructed rather than after. In the long term,
if we want to give plugins access to the target instance,
we could give them the target promise somehow. For now,
I've killed this feature because nothing used it and
the change from a direct object reference to a promise
would have been a breaking change anyway.
Also fixed incorrect documentation index for ve.init.mw.ViewPageTarget.init.
Bug: T53569
Change-Id: Ibfa6abbeaf872ae2aadc6ed9d5beba7473ea441a
