The logging feature keep a record of on-wiki user actions. This includes the Special:Log user interface, the Logevents API, the code for reading/writing this data, and the logging database schema.
This component is part of the core MediaWiki software.
See also:
For tasks about MediaWiki software monitoring with log messages (LoggerFactory, wfDebugLog, etc), see MediaWiki-Debug-Logger.
Parent project: MediaWiki-General
Noting this still shows up in 1.43.0-wmf.9.
Change #936823 merged by Jack Phoenix:
[mediawiki/extensions/ArticleRatings@master] SpecialChangeRating: Use showLogExtract() instead of LogPager
Change #993146 merged by jenkins-bot:
[mediawiki/core@master] i18n: Change default label of Special:Log, and entry in drop-down to 'Main'
Closing as task was created by a WMF-banned user in violation of their ban.
Closing as task was created by a WMF-banned user in violation of their ban.
Closing as task was created by a WMF-banned user in violation of their ban.
Block log entries put the IP range in the title (so the block target will be something like User:118.165.114.0/24). Special:Log uses LogPager::limitTitle() to filter blocks. That will result in a simple log_title = '<range>' condition. There is no way to make that work, a whole new storage mechanism would have to be invented. Probably convert IPs to a pure numeric notation, put that to log_search, use a separate starting number and ending number for ranges, have a maintenance script add that for existing log entries. Then we could use queries like log_search `start` LEFT JOIN log_search `end` ON start.ls_log_id = end.ls_log_id AND end.ls_field = 'ip_end' WHERE start.ls_field = 'ip_start' AND start.ls_value > '<range_start>' AND ( end.ls_field IS NULL OR end.ls_value < `<range_end>` ) - no idea if that would be workable performance-wise.
Change #995186 merged by jenkins-bot:
[mediawiki/core@master] logging: Hard-deprecate instantiating core loggers without DI
Probably all done. Anyone can always file another task if something isn't quite right.
Anything left to do here?
@Umherirrender's alternative solution https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1007438 means that we don't have to update every extension to accept services as LogFormatter constructor parameters, since they get injected by the LogFormatterFactory using setter methods.
Change #995925 abandoned by Bartosz Dziewoński:
[mediawiki/extensions/OAuth@master] Update log formatter dependency injection
Reason:
No longer needed
Change #995682 abandoned by Bartosz Dziewoński:
[mediawiki/extensions/CentralAuth@master] Convert loggers to dependency injection
Reason:
No longer needed
Change #995843 abandoned by Bartosz Dziewoński:
[mediawiki/extensions/AbuseFilter@master] Convert loggers to dependency injection
Reason:
Superseded by https://gerrit.wikimedia.org/r/c/mediawiki/extensions/AbuseFilter/+/1015588
Change #995185 merged by jenkins-bot:
[mediawiki/core@master] logging: Add LogFormatterFactory
Change #995184 abandoned by Bartosz Dziewoński:
[mediawiki/core@master] logging: Convert to dependency injection
Reason:
Superseded by https://gerrit.wikimedia.org/r/c/mediawiki/core/+/1007438
Change #1015583 merged by jenkins-bot:
[mediawiki/extensions/MassMessage@master] logging: Use injected services in MassMessageSkipLogFormatter
Change #1015582 merged by jenkins-bot:
[mediawiki/extensions/IPInfo@master] logging: Inject services into IPInfoLogFormatter
Change #1015589 merged by jenkins-bot:
[mediawiki/extensions/CheckUser@master] logging: Inject services into LogFormatters
Change #1015591 merged by jenkins-bot:
[mediawiki/extensions/FlaggedRevs@master] logging: Inject services into FlaggedRevsReviewLogFormatter
Change #1015588 merged by jenkins-bot:
[mediawiki/extensions/AbuseFilter@master] logging: Inject services into AbuseLogHitFormatter