This covers only directly used services by this special page and pager
Services used by the base class are not part of this patch set
Bug: T259960
Depends-On: I62855be191ea87bdc5157b6ab879c47815644156
Change-Id: I730ce17548fad3e35e8d8b6730eb3aafd734eac9
This covers only directly used services by this special page
Services used by the base class are not part of this patch set
Bug: T259960
Change-Id: Ia4a022719f572952dcb62953c8819feb3326eccd
For example, documenting the method getUser() with "get the User
object" does not add any information that's not already there.
But I have to read the text first to understand that it doesn't
document anything that's not already obvious from the code.
Some of this is from a time when we had a PHPCS sniff that was
complaining when a line like `@param User $user` doesn't end
with some descriptive text. Some users started adding text like
`@param User $user The User` back then. Let's please remove
this.
Change-Id: I0ea8d051bc732466c73940de9259f87ffb86ce7a
This method was recently added and was to result in the deprecation
of a few places where User objects were being passed to the factory.
This has now been reconsidered and this patch reverts to the
previous behaviour. It is largely a revert of Ie1bed9e9537cabc836992ccfa7fb127885ea3e11
Bug: T238466
Depends-On: Idc9f33fd5ab55bde88cc306ca63adead286380a8
Change-Id: I3653559704ccfd9bca0946f5a865be93bdf5ceb6
Add a new setUser() method to PreferencesFactory so that a User
object doesn't have to be passed around so much. This is how
GlobalPreferencesFactory has done it, and so after this change
that code can be removed from GlobalPreferences.
Bug: T238466
Change-Id: Ie1bed9e9537cabc836992ccfa7fb127885ea3e11
TitlesMultiselectWidget and UsersMultiselectWidget share
a lot of functionality, so implement a common base class.
This also adds some things to UsersMultiselectWidget:
* shows a pending element to users with JavaScript
* makes the input configurable
Change-Id: Ie6649b476c64e795254f457e3863fa7f14aa05ac
They shouldn't intentionally contain HTML (except by abuse of
PreferencesGetLegend hook), and other than trivial formatting,
it wouldn't display correctly because they are styled as links.
It is already being escaped in OOUI form.
Change-Id: I303afe92fcb0208d1a2b040321866c0c95f27aa9
Though it's "nice" to show this as a big red button to users, sadly
(a) vform is deprecated and shouldn't be used, and (b) the format's
restriction on button width intereferes with the length of the sole
control on this form, even without the prolix override expansion of
for which wikis' communities are wont to do.
Bug: T195977
Change-Id: Icc294bde1d3ed72837e7152003a2fbd522c9067d
In change 4633f4d46a it was changed
to an interface implemented by both PreferencesFormLegacy and
PreferencesFormOOUI so that existing typehints for some functions
parameter would accept them both. Replace those typehints to use
HTMLForm instead. There was really no guarantee in the past that
they would only be given PreferencesForm or its subclasses, either.
Because the typehint change affects some hooks, note it as a
deprecation in MW 1.31 and a breaking change in MW 1.32.
Also add @since tags and correct some typos in code comments.
Follow-up to 4633f4d46a.
Change-Id: I61749f1d864cf68afe90cd9e15ba2d7a74252501
This deprecates the Preferences class and replaces it with
a PreferencesFactory service. Basically, all code from Preferences
is moved into DefaultPreferencesFactory. All Prefereces methods
are now either shims calling DefaultPreferencesFactory or just
throw exceptions.
Bug: T178449
Change-Id: Id0b2db0c2de0890f6e1609a9a0dca207c4600f99
The number of issues with the new interface is unacceptable and we
will not be able to fix them reasonably quickly. See subtasks of
T180538 for the list of issues, raised both by the Wikimedia community
and by WMF employees.
I should have pushed back harder against the merging of this half-baked
change with the promise that we'll fix it later. I convinced myself
that the regressions were not so noticeable and that the issues that
were pointed out will in fact be fixed by someone. Predictably,
however, regressions were bad and the only person fixing the issues
was me.
I am not going to work nights to make this page decent again within a
reasonable timeframe; I'm not sure if I'd even be able to since many
issues are problems with the design rather than the implementation. No
one else seems to be working on improving it, therefore I am reverting
the change.
On the bright side, this work has resulted in a number of improvements
to HTMLForm and Preferences code, which are not being reverted here:
<https://gerrit.wikimedia.org/r/#/q/topic:T117781>.
If anyone reattempts this, I recommend gating the new interface behind
a configuration variable and URL parameter, like we did with
$wgOOUIEditPage in the past, and testing thoroughly in production
before enabling it for everyone.
* Revert "Special:Preferences: Use OOjs UI"
This reverts commit 486e566cfe.
* Revert "Preferences: Show preview of edit fonts in edit font selector"
This reverts commit 6634ff729d.
* Revert "Follow-Up Iae63b6994: Add missing editfont dependency"
This reverts commit ce42fdf151.
* Revert "Preferences: Improve visual appearance by “unboxing” sections"
This reverts commit c9415bb005.
* Revert "Remove box-shadow from preference panels for ooui-apex"
This reverts commit a934b82ca2.
* Revert "Preferences: Don't show the watchlist token; just link to ResetTokens"
This reverts commit e8c9102fc7.
* Revert "mw.special.preferences: Make the "Basic information" section more compact"
This reverts commit d48b7260f3.
* Revert "mw.special.preferences: Widen the dropdown of the "Time zone" field"
This reverts commit afd5f1417e.
Bug: T117781
Bug: T180538
Change-Id: I44b5daea1828f71881b5bd35218f5ecb7ab7f36e
* Change the form to OOUI mode. Tweak some formatting to look better
with this mode. Change various random links to be OOUI buttons.
* Rewrite custom tabs to use OO.ui.IndexLayout instead.
* Update styles and JS enhancements for OOUI widgets.
* Rename ResourceLoader modules so that old skin-specific styles
(from $wgResourceModuleSkinStyles) no longer apply. They tend
to make no sense with the OOUI styling.
Bug: T117781
Change-Id: Ie9396f0146f5020e52710c41e55ec86151ae0095
'Mediawiki\Widget\SelectWithInputWidget' is the only one that shows up
in the logs, but I tidied up a few others I came across.
Change-Id: I700dec858007a8013e6d7b9e37ddf518f223d8b7
This makes it possible for subclasses of SpecialPreferences to
specify a different HtmlForm to use for the preferences' form.
Bug: T68869
Change-Id: I9d6bbc6383a3d5b5c6839394de49ce9ca81efec9
Directly redirecting based on a url paramter might potentially
be used in a phishing attack to confuse users.
Bug: T109140
Bug: T122209
Change-Id: I6c604439320fa876719933cc7f3a3ff04fb1a6ad
Split out Special:Preferences handling of successbox into it's own
mediawiki.notification.convertmessagebox module and make it reuseable.
Use this module on Special:UserRights.
Bug: T115463
Change-Id: I87054b55053d209835d6fdea1f6e3e67f10e3ac8
The session data gets set in the POST and gets deleted in the GET.
This change avoids changing the URL for the success message.
A reload of the page does not show the success message again.
The URL manipulation in mediawiki.special.preferences.js is superfluous.
Bug: T26700
Change-Id: I1c2b011e7a66b2b9379dd4a3fdcc6f978dd43b52
* This does the same thing ApiOptions does to avoid these errors.
A new getInstanceForUpdate() method is now in the User class to
simplify this pattern.
* Avoid overriding $user in ApiOptions for code readability.
* Fixed IDEA errors around Preferences::getFormObject() return type.
Bug: T95839
Change-Id: If2385b7486c043bd70d7031ff35e37dfb079a4d2
New styles modules that is always added, so that all JS specific styling
is guaranteed to load before first paint. Reworked the HTML to generate
the preftoc (hidden when user has no JS).
Set htmlform nolabel class to use !important, so that it doesn't get
overriden by the 20% width rule of labels.
Also requires changes to the skinstyles of Vector preferences, which
is an a separate patch (I59f0f45), and other skins.
Bug: T115692
Change-Id: I24d9b16ed6729fdf0d59adcc2f0ba16f4f621b44
* Use .mw-preferences-messagebox instead of .successbox to
avoid conflicts with other Special pages using '.successbox'
as a class and so that the new class can be used to check
for messages to replace with notifications
* Add logic to check for messages to replace using the new
aforementioned class
* Use Html::rawElement and Html::element instead of Xml::tags
to add the non-JS successbox
* Re-added <p> tags around non-JS successbox message that were
accidentally ommitted in the original patch
Bug: T19496
Change-Id: I990667aa114d8201516bee6cb2ad22994de53c6c
"Now 98.6% leaner!"
* Use Xml::tags() for cleaner (old) successbox generation.
* Use #mw-preferences-success for the old successbox
to make its removal more specific.
* Use the mw.notify box for saved prefs message.
* Remove box on keydown or mousedown in #preftoc or
.prefsection.
* Remove success=1 querystring on load to prevent
unnecessary reappearance of notification on reload.
Bug: T19496
Change-Id: Ibecbe21aa52ddc061d4bb27815f6fa5161a96735
Method similar to SpecialPage::outputHeader() to avoid registering
tons of system messages and to have -summary and -helppage tidily
listed together in Special:AllMessages by default.
Bug: T45591
Change-Id: Ic849dde00be7379c1909a8486cf20f48c5aea5cf
* Specialpages is a useful hub, but not so visited. The help
page is currently not that good, but is not controversial either.
* Preferences should obviously be better, but may be better than
nothing. Some explanations and links there are definitely useful.
* Categories don't worry much and there's no doubt they require more
education to be really understandable and useful for users. They
are however sort of content pages, if users start thinking they can
get help about the contents of the categories of specific wikis
we'll need to remove the link.
Bug: T45591
Change-Id: I7445419864e85685b3ca0cf8333f38b284c71111
* Apply mw-ui-destructive to Special:Preferences/Reset
when $wgUseMediaWikiUIEverywhere is enabled
Introduces HTMLForm->setSubmitDestructive()
Bug: 65317
Change-Id: I1d6691dce3e7dab662bda9a718e16c5caee6c041
Callers should use SpecialPage::getPageTitle, which is
exactly identical.
This is so that in the future we can turn SpecialPage
into a ContextSource, which requires getTitle to return
getContext()->getTitle.
Change-Id: Icdcf5d5295ef5e7f08b1d403e0c123f78738fd40
There is no reason why the default can't be used instead.
No other special pages requiring login have special messages for the
title, as far as I know.
Left one use of 'watchnologin' in WatchAction alone, since it also uses
another special message there. This message is also currently used by
the MobileFrontend extension.
Change-Id: I7878ed3692358cee1f5785b34ab48a0cc83c05bc
Added new helper function SpecialPage#requireLogin() to check if the
current user is logged in and, if not, format an error message linking
to Special:Userlogin and throw UserNotLoggedIn exception, to be
handled by OutputPage later.
Reused old error messages. Not all use the new parameter and they're
very inconsistent, but this is a matter for another patch.
Used it on 7 special pages. I don't think there are any other ones
which specifically require having an account, instead of just some
rights usually associated with logged-in users.
* SpecialChangeEmail
* SpecialChangePassword: It allows anonymous users under specific
circumstances, but is logged-in-only in general.
* SpecialConfirmemail
* SpecialEditWatchlist
* SpecialPreferences
* SpecialResetTokens: It was missing the check, added it.
* SpecialWatchlist
Change-Id: I43ceaddb370d09784021b3fc2d5d1ff6616fef1f
They're obviously prettier and non-intrusive enough to fit old
interfaces. The colors are changed to more pastel ones and the general
size of the boxes is reduced.
Also remove unnecessary bolds on the informations on
Special:Preferences and Special:ChangePassword.
Change-Id: Ieae62db1a124261ae7f5bf67aced8b84cfbadd3d
