The Special:BlockList page will be updated to show details from the Partial
Block within the "Block parameters" column. The format of the column will
change to make the details more readable.
Bug: T197143
Change-Id: Ibd79b049d93e427c2d541f8ef93005847482ef59
Enforce partial blocks and display a slightly different block
notice depending on if the block is sitewide or not
Bug: T197117
Depends-On: I675316dddf272fd0d6172ecad3882160752bf780
Change-Id: I8a3635a4a04a33912eb139b7b13c4bd874183d31
Block information needs to be more detailed if a block is not
sitewide. With this change, page restrictions will be visible
as part of the block information in Special:Contributions,
Special:Block, and Special:Log and via API
Bug: T197108
Change-Id: I5d2ef606f709bdd60bf52e2a048890b0f6360fca
Make the necessary UI changes to Special:Block in order to set/update
partial blocks.
Bug: T197109
Change-Id: Ib3067824b5dcbdd893ab1f165d169a35d0716cb2
Add the widget in both PHP and JS for OOUI, and into HTMLForm
definitions.
In JS, the widget uses the engine from mw.widgets.TitleWidget
with the async support from OO.ui.mixin.RequestManager.
The PHP version provides a textarea, like UsersMultiselectWidget.php
which is then infused if JS is available.
Also, add highlightSearchQuery option for TitleWidget to allow for
not highlighting the partial search query the user typed in, if the
UI requires it. This option (highlighting partial result) is already
optional in the TitleOptionWidget, so this config exposes that
optionality in the TitleWidget widget for its menu children.
Notes:
HTMLTitlesMultiselectField is a duplication of HTMLUsersMultiselectField
except for:
- The configuration variable changed to 'titles' (from 'users')
- OOUI modules were adjusted for the TitlesMultiselectWidget
- The PHP version instantiates a MediaWiki\Widget\TitlesMultiselectWidget
TitlesMultiselectWidget is a duplication of UsersMultiselectWidget
except for:
- $usersArray was renamed to $titlesArray
- getJavascriptClassName returns the correct js class for
mw.widgets.TitlesMultiselectWidget for infusion.
Bug: T197109
Depends-On: I675316dddf272fd0d6172ecad3882160752bf780
Change-Id: Ie96947a35f70b76731e16ae5b85de815dfa4a8ce
In d59f27aeab we made
LanguageConverter::validateVariant() try harder to convert a variant
into an acceptable MediaWiki-internal form, looking at deprecated
codes and BCP 47 aliases. However, this misled Language::hasVariant()
into thinking that bogus names (like all-uppercase strings) were
acceptable variant names, which then led exceptions when they were
passed to the various conversion methods.
This is a belt-and-suspenders patch for T207433 -- in that case we
shouldn't have created a Language object with code 'sr-cyrl' in the
first place, but once one was created we shouldn't have tried to
ask LanguageSr to convert texts to 'sr-cyrl'. The latter problem
is fixed by this patch.
Bug: T207433
Change-Id: Id993bc7989144b5031a551662e8e492bd23f698a
These were introduced in MW 1.17 and are always true in production.
They were useful to allow folks to defer title conversion, but it's
been a long time now. We don't need to make this optional any more.
Change-Id: I65dcfe80dc3e1dfeb4d63924a8928655e012a20c
This is meant to protect against malicious people while avoiding
annoying good users as much as possible. We may want to restrict
this further in the future, but that's something that can be discussed
in the normal way.
Bug: T194204
Bug: T113042
Bug: T112937
Change-Id: I27e049bae78b5c0f63b10f454b740cb1dc394813
Add BCP 47 codes to $wgDummyLanguageCodes to ensure that
Language::factory() will return a valid MediaWiki-internal code if
given a BCP 47 alias. We will want to make $wgDummyLanguageCodes a
private property of LanguageCode eventually, but let's start with
removing it from user configuration.
Setting $wgDummyLanguageCodes in LocalSettings.php has been deprecated
since 1.29. Hard deprecate adding entries to $wgDummyLanguageCodes so
that we can eventually remove manual overrides from user
configuration.
This is a follow-up to 48ab87d0a3,
which described the various categories of codes, and
21ead7a98d, which added the correct
BCP 47 mappings.
Bug: T207433
Change-Id: I9f6dda3360f79ab65f6392f44c98926588d851c8
"Strip" is a very jargony term for removing something.
Translations of this message to the languages I can vaguely understand
all use the equivalents of "hide", "remove", or "display without".
Several translations to small languages I don't understand include the
word "strip" verbatim, which is almost certainly a mistake.
Bug: T76972
Change-Id: I6bf690773bfb2e5c6c35b3101733d1cd3e936e70
Special:RedirectExternal is an unlisted special page that accepts a URL as
the first argument, and redirects the user to that page.
Example: Special:RedirectExternal/https://mediawiki.org
At the moment, this is intended to be used by the GrowthExperiments project in
order to track outbound visits to certain external links. But it could be
extended in the future to provide parameters for showing a message to the user
before redirecting, or explicitly requiring a user to click on the link, which
could help improve security when users follow on-wiki links to off-wiki sites.
Bug: T207115
Change-Id: I822af14a84569aab22249e2f16a662a60e60f76a
With this change, MediaWiki will no longer have a 'JavaScript-powered'
wikitext toolbar, and instead sysadmins will be required to choose one
(or more) of the several extensions available for this purpose if they
need the functionality. For over half a decade MediaWiki's tarball has
included the 2010-era replacement for this feature, WikiEditor. We are
now working on replacing even that, with the 2013-era visual editor, a
mode of which is the forthcoming 2017-era wikitext editor, and several
more specialised editors like CodeEditor.
Beyond this, the core editor toolbar is ancient, un-loved, and is used
only exceptionally rarely, mostly by accident. It is unhelpful to give
implicitly this as the primary editor for MediaWiki just because we've
not removed it from core when it is not a very good experience for any
kind of user, and has not received the attention that users deserve to
be worth retaining in core.
The old core preference, which was intended to govern whether this old
toolbar should be shown, has since mutated into whether the to run the
EditPageBeforeEditToolbar hook. The hook is used by several extensions
to provide toolbars in lieu of the core one. This preference has been,
in practice, a very confusing preference for MediaWiki users, who have
to interact with quite similar preferences to toggle their real editor
which sit next to this one on the preferences page. Consequently, this
preference is also removed.
The code could be made into an extension for those (very few) users of
MediaWiki who might want to keep on using it. However, the author will
offer their services but not their encouragement in said undertaking.
Bug: T30856
Bug: T32795
Change-Id: I2b05f0ca25873ad8e0b33a5e4938bef52c4e9347
