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
These comments do not add anything. I argue they are worse than having
no comments, because I have to read them first to understand they
actually don't explain anything. Removing them makes room for actual
improvements in the future (if needed).
Change-Id: Iee70aad681b3385e9af282d5581c10addbb91ac4
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
Sort by the internal name, so that the ordering is the same for each
display language, especially if some skin names are translated to use
a different alphabet and some are not.
Bug: T181112
Change-Id: I763150cc578e9aa70990a53895c032f17d96e97a
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
* Each has a hidden preference to override the preferences value
* Each value is different between Watchlist and RecentChanges
* rcfilters-limit is updated when rclimit is changed
* Not conditionally hiding the rcdays, watchlistdays and wllimit yet
because hide-if's behavior is annoying
Bonus:
* Add a static method to check whether RCFilters UI is enabled
and enabled by default. Adjust the call for Watchlist which
checks a slightly different configuration setup.
Bug: T174415
Change-Id: Ib933de3a3f9e876924386e80f315506f60f8af54
Also make both the PasswordReset and ResetTokens forms appropriately
flag their action buttons as destructive.
Bug: T180710
Change-Id: I26649900f9360e5175fa93b87dc7840a7c1d4f93
The result of this function depends on the $user and $context
parameters (e.g. it includes the username from the user, and
localisation messages the language from the context). However,
both of them would be ignored if the result was cached, even
if calling with a different $user or $context.
Rather than make this more complicated just remove the caching.
This is not a hot code path: this function is not called at all
on normal page views, it's called just once when viewing
preferences, and at most twice when saving them.
Change-Id: I92390120a16448383a25e9ba2dd35a434a2f21bf
* 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 will allow us to load them in the backend, and to keep
consistency between RecentChanges and Watchlist if needed.
Added also a 'backup' preference to keep the previous version
before the conversion, in case of mangling of the queries.
Bug: T166908
Change-Id: I8e26b66e43bd16282b7bdb52abc152f92a9c877d
- Add a new section to preference page with the following title:
"Opt out of improvements".
- Move the opt-out option and explanatory text to this new section.
Bug: T175765
Change-Id: Iaf77df2eec714777f54b95b58eb617b5e35bef75
For reasons beyond human fathoming, the button had the id set
to 'prefsubmit' in PHP code and then changed to 'prefcontrol'
in JS code. This functionality has been carefully preserved
across multiple rewrites of this code since 2004, when it was
added in 30d0ccd0 (rSVN3618). Let's just set the id in PHP.
Change-Id: Ib23bd0e481e73a51ff0a16731f47a2df11b2c1b8
Users can now specify a blacklist of users who are prevented from sending them a direct email.
Bug: T138166
Change-Id: Ifa26153f593b0ca3a9121e1e29961911c616c9e4
Currently this is disabled by default. On wikis with the BetaFeatures and
WikimediaMessages extensions installed, this preference is set (if the
$wgEnableRcFiltersBetaFeature flag is set) via BetaFeatures. This change
lets users on normal wikis use these too, and lets BetaFeatures-capable
wikis "graduate" the feature to be provided to all users by default.
Bug: T168376
Change-Id: I3c75f9f2f6287414bf330f116d959d078250392d
This fixes the restore-prefs link by switching to use whatever
the current title of the PreferencesForm is.
Bug: T173682
Change-Id: I67a13269a63f719a011a2d59a07493d9eb6b653b
* Add classes prefixed with cl (for ChangesList)
to both RC and WL so that the JS app can locate
similar elements using the same selectors
* Make saved queries preference name configurable
so that RC and WL use different preferences
* Move some code from SpecialRecentchanges.php to
its base class so it's accessible to SpecialWatchlist.php
To use the RCFilters app on WL, append ?rcfilters=1 to the URL
Bug: T171132
Bug: T171218
Change-Id: If7c63284224df24fa02022b4ea74bef116f28ca6
When the 'watchlistunwatchlinks' preference option is enabled, this
adds a '×' link to each entry of the watchlist that unwatches the page
of that entry. When clicked, it changes into a '+' which can be used to
re-watch the page (effectively undoing the earlier unwatch).
When a page is unwatched, its entries and the entries of its associated
talk page (or vice versa) become translucent and are struck through.
Without JS, '×'/'+' link to action=(un)watch for the relevant page.
In addition, ChangesList classes have been modified to allow a prefixer
that adds a prefix to each line (used in this case to put the unwatch
link) and to add HTML data attributes to reliably determine the target
page of each entry. Unit tests have been updated accordingly.
Bug: T2424
Change-Id: I450b2901413d7e75c11de2a446829fdbb22d31e1
- Add sticky preference for groups and the operation behind
it.
- Allow normalization from the UriProcessor
- Backwards-compatibility for saved queries
- Allow saved queries to load regardless of sticky params
and to be compared correctly without the sticky params.
- Add days/limit preferences and update those on change
- Update the preference even if we received a new value
from the URL.
Bug: T171514
Bug: T171368
Change-Id: I5232f3372f0e5c981332d152faf0ab47cc470b56
And auto-fix all errors.
The `<exclude-pattern>` stanzas are now included in the default ruleset
and don't need to be repeated.
Change-Id: I928af549dc88ac2c6cb82058f64c7c7f3111598a
Also change the user preference order to put the default first and the
least-good option last.
Bug: T171201
Change-Id: Ib4c6cd7f2d98824313c2bfcdf3f71d89fc48c929
Changes:
- added one argument to PreferencesFormPreSave hook,
a $oldUserOptions array which contains set of all user
options before save
- updated documentation
Bug: T169365
Change-Id: I28003c5898d64031e1efb212cb0bec58ff44b958
It's unreasonable to expect newbies to know that "bug 12345" means "Task T14345"
except where it doesn't, so let's just standardise on the real numbers.
Change-Id: I6f59febaf8fc96e80f8cfc11f4356283f461142a
This patch adds an ug_expiry column to the user_groups table, a timestamp
giving a date when the user group expires. A new UserGroupMembership class,
based on the Block class, manages entries in this table.
When the expiry date passes, the row in user_groups is ignored, and will
eventually be purged from the DB when UserGroupMembership::insert is next
called. Old, expired user group memberships are not kept; instead, the log
entries are available to find the history of these memberships, similar
to the way it has always worked for blocks and protections.
Anyone getting user group info through the User object will get correct
information. However, code that reads the user_groups table directly will
now need to skip over rows with ug_expiry < wfTimestampNow(). See
UsersPager for an example of how to do this.
NULL is used to represent infinite (no) expiry, rather than a string
'infinity' or similar (except in the API). This allows existing user group
assignments and log entries, which are all infinite in duration, to be
treated the same as new, infinite-length memberships, without special
casing everything.
The whole thing is behind the temporary feature flag
$wgDisableUserGroupExpiry, in accordance with the WMF schema change policy.
The opportunity has been taken to refactor some static user-group-related
functions out of User into UserGroupMembership, and also to add a primary
key (ug_user, ug_group) to the user_groups table.
There are a few breaking changes:
- UserRightsProxy-like objects are now required to have a
getGroupMemberships() function.
- $user->mGroups (on a User object) is no longer present.
- Some protected functions in UsersPager are altered or removed.
- The UsersPagerDoBatchLookups hook (unused in any Wikimedia Git-hosted
extension) has a change of parameter.
Bug: T12493
Depends-On: Ia9616e1e35184fed9058d2d39afbe1038f56d7fa
Depends-On: I86eb1d5619347ce54a5f33a591417742ebe5d6f8
Change-Id: I93c955dc7a970f78e32aa503c01c67da30971d1a
In https://gerrit.wikimedia.org/r/80061/, Chad was convinced this
preference is barely used and mostly set to weird values by people
who don't understand what they're doing.
He made some quick stats: http://p.defau.lt/?fgGU0StB4J9l0LC5GZq8AA
Used defaults of 80 columns and 25 rows in places that still
were asking for it. The old default values are left in
$wgDefaultUserOptions for now, since various extensions are
using them.
The 'rows' and 'columns' messages don't appear to be in use in
any extensions in Git, so I killed those as well.
(This is the same as I642188c74d929a586b1882a1cf8656056c4fcf5a.)
Bug: T26430
Change-Id: I6c9802bc4f9cf32fb75c3dd7b9e2dc18f271eedf
Searched for /([^\d\w\s\)\]]\s*)- \d/ to find potential issues.
It seems there's no PHPCS check for this, huh.
Also fixed typo in a comment in LoginSignupSpecialPage.
Change-Id: Iaab1a1f5a9f234971e550e7909aa5c3e0c02a983
Currently, a user who has an invalid time zone stored in the database is
effectively locked out of their account on HHVM sites. This patch addresses
this by (1) preventing users from setting invalid time zones, and (2) not
throwing an unhandled exception if a user's TZ is unknown.
When the user saves their preferences, the code silently rewrites invalid
time zones to UTC. I think this is OK, since to cause this to happen you
have to manually muck around with the Preferences page DOM or submit the
form from a script.
Bug: T137182
Change-Id: I28c5e2ac9f2e681718c6080fb49b3b01e4af46dd
