Some of Echo's subscription user preferences are mapped to existing
user preferences defined in core MediaWiki. However, this special page
was checking the Echo preference names, returning incorrect values.
This affected the edit-user-talk preference and watchlist preferences
(not available with the default configuration).
Change-Id: I2de7553f82434505c000c30a71b9f90c4490482b
On some systems, when they are disabled, checked and unchecked
checkboxes are not that easy to distinguish. They're really bad
for me on Windows (apparently a bit less bad on macOS).
https://phabricator.wikimedia.org/F34567120
OOUI checkboxes are clearer (since they're bigger and the
check icon has higher contrast against the background).
https://phabricator.wikimedia.org/F34567121
Change-Id: I124c7e1874d50d5f3883ffcc5264da46ae012e0a
User::setOption() is deprecated and should be replaced with UserOptionsManager::setOption()
Bug: T277818
Change-Id: I001301fb95635c421a0bbb921fd909c5312dc896
This partially reverts commit 83a181ce9c
and fully reverts 82896eff62
To avoid regressing to the errors from T139665, check if the user
retrieved from RequestContext::getMain()->getUser() is safe to load
instead of $wgUser, still in addition to the other checks that
EchoForeignWikiRequest::$user is safe to load.
Bug: T243732
Change-Id: I22c4918fc7e8b3d1364a95de3958c055059971b8
https://bugs.php.net/bug.php?id=50688 was closed as fixed
in 2017 when PHP 7.0 was only supported upstream.
We already require PHP 7.2.
Change-Id: Ie9801e38915da634e31c91ebdcb61226e0ae5712
Update to 7880cc18, restores ".mw-echo-alert" class on "class" property
instead of on "link-class" property.
Bug: T284496
Change-Id: I11a04fa5a7e9d0b34e62733ee537a43549d13477
Note: This change would potentially affect all skins including modern
and legacy Vector and others.
The status quo when a talk notification is present is to transform the
talk link into an orange notification message. One option is to leave
the talk link and **add** a notification instead of transforming it.
This will result in two elements #pt-mytalk and #pt-talk-alert
This will interfere with styles targeting #pt-mytalk .mw-echo-alert
This impacts user styles but not anything in production.
Bug: T283811
Change-Id: I3e4be1381f9a2e9986b94b3b13df5ed64d09a59d
Before this commit, setting:
```
$wgVectorConsolidateUserLinks = [
'logged_in' => true
];
```
would result in an orange talk notification that had missing or
incorrect attributes (`#ca-mytalk` instead of `#pt-mytalk` and missing
the `title` and `accesskey` attributes) when visiting modern Vector
with a talk notification visible. The notification's html looked like:
```
<li id="ca-mytalk" class="mw-echo-alert">
<a href="/wiki/User_talk:Newuser5">You have a new Talk page message</a>
</li>
```
The `pt-mytalk` id is important for echo to remove the notification [1].
The title and accesskey are important for accessibility reasons.
This commit corrects that by setting a `link-class`, setting an explicit
`id`, and NOT setting a `class` key. This results in html that is
correct in both modern and legacy Vector:
```
<li id="pt-mytalk">
<a href="/wiki/User_talk:Newuser5" class="mw-echo-alert" title="Your talk page [ctrl-option-n]" accesskey="n">You have a new Talk page message</a>
</li>
```
[1] 67bf58a489/modules/ext.echo.init.js (L172)
Bug: T274428
Change-Id: I5afc74992ad3153ac32df65ccf5fd03b469f05fb
**Note**: This change will affect the order of the yellow talk page
message notification on legacy Vector/other skins by moving it from
after the `#pt-notifications-notice` element to before the
`#pt-notifications-alert` element. This was done because the
notification is related to the list of messages that appear when the
bell icon is clicked so having it in close proximity to that icon is
hopefully more intuitive than having it next to the unrelated inbox
icon. [1]
Per T274428, we need this notification to be inside the `notifications`
array instead of inside the `user-menu` array.
Additionally:
* Per T274428, update the notifications message copy to "You have a new
Talk page message"
* Remove the `onPersonalUrls` hook method inside EchoHooks,
unregister its use as a hook in extension.json, and update its
references in Echo.
[1] T274428#7113896
Bug: T274428
Change-Id: I5ae0ec089bcf0eec1ec7ac13f60e811f54e1d8e1
Thanks to the changes from T254074, the EditResult object passed to
the 'PageSaveComplete' hook now knows whether the edit being saved
is a rollback. We don't need to pass this information from the
'RollbackComplete' hook via globals.
Bug: T277649
Change-Id: Ieef7941e4665204b1a9b2356a58216626ed1f54b
ContentHandler::getContentText() is deprecated and should be
replaced with Content::getText() for TextContent instances.
Change-Id: Ia92c5a41954b1d21deb39dcafabbdff60a414f55
I think the problem the GROUP BY was trying to solve was the potential
for there to be multiple rows with the same (etp_page,etp_event) pair.
There's no unique index to prevent that, and it would cause the event to
be duplicated in the result set. DISTINCT fixes that without generating
an error with sql_mode='ONLY_FULL_GROUP_BY'.
Per https://dev.mysql.com/doc/refman/8.0/en/distinct-optimization.html
DISTINCT is effectively shorthand for a GROUP BY with all the fields.
Bug: T281329
Change-Id: I6a0d578d729c33241a5c5fbd3f4e83f0e5fab83f
