This change requires MediaWiki 1.32 which is already required in
extension.json.
Change-Id: I61856796d864c9493c1a7a875cb2415f11f081a9
Depends-On: I193f5b9a95430b0a05573c361715e053e5411e32
This cache was only used so that, if we're told to clear the newtalk
flag and we already know there are no edit-user-talk notifications, we
won't try to delete them. But that's not a good justification for such a
confusingly-written cache that would have been hard to convert to
getWithSetCallback(), and I'm concerned that using cached data to make
this decision could lead to inconsistencies.
Also remove the notifCountHasReachedMax() check, which made no sense: if
the user has >99 notifications, that is no justification for not marking
their user talk notifications as read when they visit their user talk
page. Whether the displayed notification count will change has no
bearing on whether these notifications should be marked as read (and now
that bundled notifications are counted individually, the displayed count
actually could change).
Bug: T164860
Change-Id: I3ff5c9b31307839b9336bd8856015db9baa52fad
* Move revision ids out of configuration and into MWEchoEventLogging
class. Because the EchoInteraction schema is used both server and
client, we have to duplicate the revision id.
* Use EventLoggingSchemas attribute to register client-side schema in
extension.json instead of a hook.
* Check if EventLogging is enabled in MWEchoEventLogging instead of
$wgExtensionFunctions.
* Pass only whether the EchoInteraction schema is enabled to the
client-side instead of all of $wgEchoEventLoggingSchemas.
Change-Id: I968294f96cedac19dc9d8f53df14fecfb666ceee
The only place that reads the config variable is in ext.echo.logger,
which uses OO.getProp() to do so. If that property doesn't exist,
`undefined` will be returned, which we can force to boolean false.
Bug: T118488
Change-Id: Iac352b133950f6f2e4b88950c1fcd0c893284fd9
This avoids needing any dependencies on EventLogging in the module
definition, as well as allowing the extra dependencies to be lazy-loaded
as necessary.
Change-Id: I49b5be4be4f55cd4e27064247463b2ddb8e81296
$wgExtensionFunctions are run on every MediaWiki request, and should be
avoided unless necessary. Default user options should be controlled by
the UserGetDefaultOptions hook instead.
Bug: T180192
Change-Id: I2a79e078753d289c3ea2f04b613ce72c59a9e59a
Makes so many things simpler and robust.
Bug: T198935
Change-Id: Ia836f8f497cae8599f85cf86a7f6b299cd012e81
Depends-On: Iff63da0d215585cfcf083e7f7ec8ed45d5b77301
Explaining that a variable named "$username" contains a "username" is
not helpful. One have to read this comment first to understand that it
does not add anything to what's already obvious from the variable name
and the type.
Change-Id: I9a43866498d0c94422caf16233f502320a8e36c9
See I2291c69d9df17c1a9e4ab1b7d4cbc73bc51d3ebb for the anticipated
hard-deprecation of this method in core.
Bug: T197492
Change-Id: I4687db09c27480147cfa7a648a886b1670812deb
We almost always call it with DB_MASTER, and I'm pretty sure that the
one call that uses DB_REPLICA introduces a race condition. I didn't want
to change that quite yet, though, so I left it in for now.
Change-Id: Ia5a59fdda357b799e327b8ed224f3ccb09509a8a
