get_debug_type() does the same thing but better (spelling type names
in the same way as in type declarations, and including names of
object classes and resource types). It was added in PHP 8, but the
symfony/polyfill-php80 package provides it while we still support 7.4.
Also remove uses of get_class() where the new method already provides
the same information.
For reference:
https://www.php.net/manual/en/function.get-debug-type.phphttps://www.php.net/manual/en/function.gettype.php
Change-Id: I54c2bf287b185e2526b0a8556166fd62182b2235
@private usually means "cannot be used outside of this class". But
this is used. I assume it's meant to be @internal as in "internal to
this codebase".
Change-Id: I9326e17f706af336ea0d4b7c0af95330ed575810
Before this patch, middle-clicking notifications would still mark them
as read, but the user would only find out upon closing and re-opening
the notification tray or reloading the page.
Bug: T340179
Change-Id: Ic29af0c70354087cf5f783b5a7370241a86b4bf3
The current code uses deprecated TitleLinksTable::getTitleArray and that
is also using Title::newFromPageReference to get Title objects,
so performance issues or more memory usage are not expected.
Change-Id: I25d047ceb707837009e0a703693ebc2f49fc0ba9
`groupItems[ i ].id` is of type number, and using the spread operator
on it results in a type error. This prevented users from marking
multiple cross-wiki notifications as read, with the associated button.
Bug: T368643
Change-Id: I53d404445956de288aeda8fbfe1bdd1256214839
This was a mistake in I53c0283, sorry. There are two users involved:
The "agent" is the user (typically an administrator) that made the
user group change, while the "viewing user" is the user for which the
user group was changed. When the "agent" moves the "viewing user"
into a new user group, the "viewing user" is the one that's now
a member of that group. They are what dictates the gender for the
"group-…-member" message.
Is this mistake bad enough for a backport?
Bug: T368249
Change-Id: I4916de2fb171873b625e51ee8823811e0296d323
This affects primarily the message
"notification-header-user-rights-add-only" which is very priminently
seen by every new editor that made their first few edits and gets
promoted to the next user group a few days later. Turns out the code
was just incomplete. All the information about the user and their
gender is already there, it was just not forwarded correctly.
Notice there are two messages:
* "group-…" messages don't have gender support. This is the (ideally)
gender neutral name of the group. Meant to be used as e.g. section
heading for a list of users.
* "group-…-member" is the same with gender support. To be used in all
contexts that are about a single, specific user with known gender.
Which is exactly what's happening here.
Turns out we can even use a neat convenience function from the
Language class that does exactly what we need.
I can't tell why but the array_values is apparently critical.
Originally added via I49b5fe5. It can't hurt so I keep it.
Bug: T368249
Change-Id: I53c028375d77c93f399538fd38aa8f8af30934b0
