::doUserEditContent() is available since 1.36 as a replacement
for ::doEditContent(), which has been deprecated. Extension
already requires MediaWiki 1.37+, so the method is always
available.
Bug: T255507
Change-Id: Iee5de356dbccd453a3083e0a58859b4cd83a946b
In Vector, these rules result in the anchor pointing to the wrong
place. They seem to be improve things in Minerva, so these are restricted
to that skin.
Bug: T276566
Change-Id: If871ab59fea519b48568781ffd9ddf6640006385
Update to 7880cc18, restores ".mw-echo-alert" class on "class" property
instead of on "link-class" property.
Bug: T284496
Change-Id: I11a04fa5a7e9d0b34e62733ee537a43549d13477
If there's exactly one new user talk message, then link directly to it
from the orange banner.
I'm using EchoEventPresentationModel to get the link target, instead
of some more direct way, because this approach allows us to override
the link in DiscussionTools. Together with the changes proposed in
T281590, this would allow linking directly to individual messages (and
highlighting them), rather than just the section.
Bug: T58475
Change-Id: I1fd0e22f4ee0f0dfacaf420d3fd890dce0820cbd
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
