The var 'module' got renamed to 'm' in
I57b11c6b4c6e67bb38bb67a93b06d6d1d3009933. This patch fixes the
call to it.
Bug: T284716
Change-Id: I57b7a5fd4a8f2fe2fa98ab5fc41c5bd2500f3a67
We were already using it for almost all interactions with the editing
area, except for this code which restores the selection after closing
a dialog.
Bug: T254612
Change-Id: I26d22d9c5d64fe8c861405e65cd4464c349aeac9
Remove use of mw.loader.getVersion, which I'm planning to remove
from the public API. The only valid use case I found of it (not
in WMF repos) is to check if a module exists, for which one can
use mw.loader.getState() already.
The code path here handles with the 'icon' property of a
WikiEditor "toolbar group tool". In other words, the buttons
you can click in the toolbar to open a dialog or insert markup.
I found two ways to reach this code path:
* For the built-in tools and icons that are part of WikiEditor.
These are all based on OOUI now and no longer use inline styles
with background-image etc., they are class-based instead, with
the URLs and language variants handled server-side by RL.
* For user scripts that register a custom tool and icon.
To try this, copy snippets to the console on an edit page from
<https://meta.wikimedia.org/wiki/User:Krinkle/Scripts/InsertWikiEditorButton>
These pass urls as the 'icon' property and thus don't satisfy
the hasOwn condition in this code. And even if they did, there'd
be no reason for the module version to be helpful to the thumbnail
url the user would have passed.
This line of code has existed with the mw.loader.getVersion() call
since the repository's very first commit in 2010 (9d278e8dee).
The worst that can happen is if there are stil some internal icons
hitting this path, they'll be cached for 1 hour instead of 7 days
(per /w/static.php rules in production). For third parties, there
would be no difference and such static paths have no caching by
default either way (outside WMF).
Change-Id: I6ec29abde0085d04b662b56b5ebcc2bd7fa267f8
An <a href="#"> element
* shows a status line with a URL on hover and
* opens a new tab on middle click.
For still supporting keyboard navigation the replacement uses
* tabindex="0" to have the normal tab order and
* .on( 'keydown' ) to catch the Enter key.
The image example in the help does not need a link or a keyboard
navigation.
Change-Id: I6d75f75871bb29bdd878451f282f2055ed3f4f5c
This allows us to bundle the wgWikiEditorMagicWords and
mw.msg.wikiEditor(?!) config vars that were previously exported globally
in the startup module.
This code is old and crufty, so this is a somewhat minimal conversion:
* Use require() for jquery.wikiEditor.{dialogs,toolbar}.config.js,
and for jquery.wikiEditor.{dialogs,toolbar}.js
* Don't attempt to convert jquery.wikiEditor.js to something
require-based, instead just run it and let it set the $.wikiEditor and
$.fn.wikiEditor globals
* Consolidate ext.wikiEditor.{dialogs,toolbars}.js into
ext.wikiEditor.js
Bug: T222828
Change-Id: Ia75d685cbde786e8fceb6db36f2436b2beea1499
The only use of raw HTML messages is in the help panel, which is the only user
of `layout: 'table'`, so we can replace all other callers.
Bug: T154891
Change-Id: I2df3ec8c05d4daaa094378354566356a822c081f
Replaces the insert and advanced-insert groups, which
are currently multi-colour icons.
Drops the button-sprite + offset mode, according to
mwgrep there are no other users of this.
Bug: T191031
Bug: T143508
Change-Id: I7032f98908a591ea5c9d3dbbb7616e2c10bbfc80
* Follows-up 6a73d06 by removing the hardcoded SITENAME regex.
* Follows-up 1b797b7f6a which introduced this regression in the first
place. This is exactly the reason why mw.msg() defaults to format
'text' instead of 'plain' without transformations.
Change-Id: I7f1b877710fb6baa45b83054d1e30a24979b37b4
Use mw.language.getFallbackLanguageChain() to get the
fallback language chain. This chain currently always contains 'en'
as last element. Remove the last element to prevent a fallback to 'en'.
Reimplement autoIconOrOffset to correctly prefer sprite before icon.
Bug: T87247
Change-Id: I452dd45d20ea4dd542d63274b7aad0272e20ea12
Some very weird issues going on involving multiple wikiEditor instances being
set up on the same textarea element. It's probably a race condition of some
sort and I'm hoping that restoring the modules like this will fix it.
Bug: T93384
Change-Id: I44c9c013993220ab709893d239614552d7b25d46
Seems to be causing errors on view (!) on plwiki, and I would not expect this
to work on non-wikitext pages.
Bug: T93242
Change-Id: I0336a85a2ab4bef1d20086382012047688ffa909
* Fix errors and warnings from phpcs.
* Add commas at end of lines for arrays in PHP.
* Add space between // and comment.
* Add space between ) and {.
* Use tabs instead of spaces for indenting.
* Break lines in PHP with more than 100 characters.
* Remove double spaces and spaces at end of line.
* Remove spaces before comma.
* Fix some typos.
Change-Id: I9c014bdfa9832fa6a20d0190fe2fc668983d0fb9
An early version of WikiEditor added a workaround for a reported
bug with IE 8 where textarea scroll and selection state was lost
when the contents were modified.
This doesn't seem to be needed on modern versions of IE such as 11
and above and the newer 'Edge' HTML engine mode in Windows 10.
Actually, I can't reproduce it in Windows 7 or XP with IE 8 either
from the original bugs, but just in case it's needed on some particular
version that we don't know about I've only added a check for modern
IEs, which is already in use on other old-IE workarounds in the
module.
Bug: T88875
Change-Id: I25b667a8d8378c417441adee5d97571c71a1c8c7
