These features were ideas in the Usability Initiative but were never
finished to the level that they would be deployed on Wikimedia wikis
and have been marked as "going to be removed" for years. Now is time
to act on that promise.
Change-Id: Ia1eb91d2dfb1979518d97badc1477146b4606f7c
This avoids the exclusion of the rule
MediaWiki.Files.ClassMatchesFilename.NotMatch in .phpcs.xml.
Change-Id: Ia6fdbe9e9ba726d8a6b4d8168d298820e3efc1d2
This was present right from the start of this repo (in WikiEditor.php back
then) and I can't quite see where it stopped being a thing, except that it
pre-dates the conversion to en.json.
Change-Id: Ifeebb7dcf511f73f74934ee88a7a007dfdbcc803
No idea where these came from; they weren't present in I76e2a685 and yet
appeared in Id90e104 despite that being an apparent script-conversion of
the former.
Bug: T118541
Change-Id: Iac18c3c7ef8b1552313c2bd9f5b8fdc4cb8789b6
These were moved to core in Ifd0ed24 as special-characters-* but were not
removed from here, leading to a lot of failed message loads.
Bug: T118541
Change-Id: I8ccbbbf98177656284712134f3238a9e4482d32d
Move the HTML for the dialogs to separate template files,
using the template mechanism from core.
It is still possible to specify the HTML directly as before,
to be used in gadgets etc.
Change-Id: Ia7ad5aaa9cac429d1c9d706bdf6760e3eda358bc
Per T42972, the current hidesig implementation is broken, and only
hides the signature button in namespace 0 regardless of the value of
$wgContentNamespaces.
Seeing as the old implementation of hidesig was broken, I don't really
think backward compatibility with old configurations is a useful
concern here. In particular, hiding of the signature button is no longer
able to be configured in Special:Preferences (why such a trivial pref was
ever able to be exposed to users, I don't know).
Bug: T59727
Change-Id: I596fd435bc9be8c37da43177c1bea90ebff0b2fe
* Internal links: Show simple example first
* References: Show use of unnamed references
* Discussion: Use --~~~~ for consistency with what the toolbar button inserts
Bug: T26128
Change-Id: I08de0ad416727447eccad914c2ade3a93e5a8ae2
Replace $.escapeRE from 'jquery.mwExtension' by
mw.RegExp.escape from 'mediawiki.RegExp'.
This change requires MediaWiki 1.26+
Bug: T103993
Change-Id: I5fc19e1313fc6a06726981e0365cea6d00abb5f3
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
Style modules currently added through addModuleStyles default
to being in the head ("top" position). This is an unhealthy default,
since only critical styles that are needed at pageload should be
in the head. In order to be able to switch the default to "bottom",
existing module positions have to be defined explicitly.
Bug: T97410
Change-Id: I8dbee3e4edf673341e7eb49f360e83e4dac54b17
Extension registration currently doesn't support merging 2d arrays
(T99257), so set it as an explicit global for now in a callback.
Change-Id: If7604a7ed8ec0f940c4a4d2988fcecc383303e1d
* 3cb4714e15 "Bump version to 0.5.0 to reflect massive updates in
last year"
* c9c189fd9d "Add dependency on mw.user"
Change-Id: Ic17a7f6a1bf97c955b79c6500ddbec38201aa650
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
Follows-up 74da530f2, which introduced a separate HTTP request
on all pages just for the 665 bytes (compressed) of ext.wikiEditor.init.
Have it join the main load queue instead.
Change-Id: I9e0ce994e632c64f3c781f45ea44582c0a943c65
