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
@matej_suchanek thank you very much! I didn't realize that and that does seem to be a very big part of the puzzle.
Could it be accounts created by email? I.e. log_action = 'byemail'. Or log_action = 'create2', too.
In these cases, the actor is the user who creates the account, not the account created.
Try query for log_namespace = 2 AND log_title = REPLACE(user_name, ' ', '_') instead.
It's possible this is expected behavior, but I couldn't find any documentation saying so.
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.