For compliance with the new version of the table interface policy
(T255803).
This patch was created by an automated search & replace operation
on the includes/ directory.
Bug: T257789
Change-Id: I17e5e92e24c708ffc846945a136347670a3a20c7
Per the Stable Interface Policy, PHP interfaces should not be
directly implemented by extensions, unless they are marked to be safe
for that purpose.
Bug: T247862
Change-Id: Idd5783b70fc00c03d57f5b1a887f0e47c4d7b146
Undo traces of a practice we carried over from past projects and
existing examples that is neither universal nor actively encouraged in
the MediaWiki codebase.
Bug: T139301
Change-Id: I5c9c89b72a45a44aa4264a5e57b003c1a86cdf6e
Co-Authored-By: Brad Jorsch <bjorsch@wikimedia.org>
Move the MWLogger PSR-3 logging related classes into the
MediaWiki\Logger namespace. Create shim classes to ease migration of
existing MWLoggerFactory usage to the namespaced classes.
Bug: T93406
Change-Id: I359cc81fbd2dcf8937742311dcc7d3dee08747b0
Time wounds all heels. During the code review for the PSR-3 logging
introduction, several people asked me why we needed a wrapper
for Psr\Log\LoggerInterface if the point was to use the standard. At the
time I was convinced that it would be better to introduce the dependency
via a wrapper class so that we could use the wrapper to patch over any
deficiencies that we might find in the PSR-3 API. After going on to work
on a project to disentangle other MediaWiki components from internal
project dependencies I have suddenly and clearly seen the error of my
ways.
We still need a logger factory as PSR-3 does not specify
a standard mechanism for creating Psr\Log\LoggerInterface instances. My
solution is to convert MWLogger into MWLoggerFactory to retain a static
factory interface for creating PSR-3 loggers but remove the MWLogger
wrapper class itself in favor of direct exposure of
Psr\Log\LoggerInterface to the MediaWiki consumer classes.
Change-Id: Ie47467657dcf341991ada00827dca5e8eff95438
This was used in 2 special classes, the logger classes and spread
to a few other random classes.
Afaik this has no meaning. Is for something we don't use, and
goes against the meaning of '@section' in Doxygen, which we do
use.
In Doxygen output, all LICENSE references became links to
ProfilerXhprof (the one Doxygen encoutered first).
Bug: T72328
Change-Id: Icc7c443245c70bc0f549bee7d105eef5691c864d
The MWLogger class is actually a thin wrapper around any PSR-3
LoggerInterface implementation. Named MWLogger instances can be obtained
from the MWLogger::getInstance() static method. MWLogger expects a class
implementing the MWLoggerSpi interface to act as a factory for new
MWLogger instances. A concrete MWLoggerSpi implementation using the
Monolog library is also provided.
New classes introduced:
; MWLogger
: PSR-3 compatible logger that wraps any \Psr\Log\LoggerInterface
implementation
; MWLoggerSpi
: Service provider interface for MWLogger factories
; MWLoggerNullSpi
: MWLoggerSpi for creating instances that discard all log events
; MWLoggerMonologSpi
: MWLoggerSpi for creating instances backed by the monolog logging library
; MWLoggerMonologHandler
: Monolog handler that replicates the udp2log and file logging
functionality of wfErrorLog()
; MWLoggerMonologProcessor
: Monolog log processer that adds host:wfHostname() and wiki:wfWikiID()
to all records
New globals introduced:
; $wgMWLoggerDefaultSpi
: Default service provider interface to use with MWLogger
; $wgMWLoggerMonologSpiConfig
: Configuration for MWLoggerMonologSpi describing how to configure the
Monolog logger instances.
This change relies on the Composer managed Psr\Log and Monolog libraries
introduced in Ie667944.
Change-Id: I5c822995a181a38c844f4a13cb172297827e0031
