Uses new PHP 5.6 syntax like ...parameter unpacking and
calling anything looking like a callback to make the code more readable.
There are much more occurrences but this commit is intentionally limited
to an easily reviewable size.
Change-Id: Idcec077ef3fdf029b632cceafd0150851ad723e3
Find: /isset\(\s*([^()]+?)\s*\)\s*\?\s*\1\s*:\s*/
Replace with: '\1 ?? '
(Everywhere except includes/PHPVersionCheck.php)
(Then, manually fix some line length and indentation issues)
Then manually reviewed the replacements for cases where confusing
operator precedence would result in incorrect results
(fixing those in I478db046a1cc162c6767003ce45c9b56270f3372).
Change-Id: I33b421c8cb11cdd4ce896488c9ff5313f03a38cf
Deprecate the unnamespaced version and move it to includes/compat.
Bug: T147167
Depends-On: I39c805bfb98b32f32f3d0dc1eee9e823afe1c21a
Change-Id: I3780c7adf51683f3f7adb35a88f9a25a0a2e2530
phpdbg is a gdb-style debugger for PHP that is run from the command
line. However, it has a different PHP_SAPI value, so it was impossible
to run maintenance scripts with it (until now).
To avoid having to check both PHP_SAPI values in a bunch of places,
introduce wfIsCLI() to easily check whether running from the
command-line or not.
We're (CI team) interested in generating code coverage with phpdbg
instead of xdebug, hence this patch.
Bug: T184043
Change-Id: Id1f994ca146d7858cd8bb6ab6cdbb7718ff524fb
Follows investigation from T172559, where we found that there is no explicit
way to find what script triggered particular error messages when the script
was run from the command-line (as opposed to a web request, where the
built-in WebProcessor adds fields like http_method and url).
Change-Id: Ia9641274a164137dcc30324578d750cc662976ee
In phpcs.xml rename renamed sniffs and add the failing sniffs,
because now the whole sniff is no longer excluded.
Change-Id: If5b0bd16028761abc2c47ace9e97d37ad14bb36f
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>
eval.php previously set $wgDebugLogFile to /dev/stdout. This had the
following problems:
* It doesn't work if the maintenance script is executed via sudo, since
/dev/stdout is typically owned by the original user, so MW can't open
it. Using php://stdout worked on HHVM but not PHP.
* Setting $wgDebugLogFile has no effect if the wiki uses MonologSpi.
* Setting $wgDebugLogFile has no effect on channels configured with
$wgDebugLogGroups.
* stderr is a more appropriate place to send logging output.
* Writing to configuration variables is discouraged.
So, add ConsoleSpi, which is a very simple logging service provider
which sends all messages to stderr. This should be suitable for
debugging with eval.php or shell.php in WMF production or beta.
Change-Id: Ib0d6ce45e0cbecd58263fc4e360c63d4149acb3a
I was bored. What? Don't look at me that way.
I mostly targetted mixed tabs and spaces, but others were not spared.
Note that some of the whitespace changes are inside HTML output,
extended regexps or SQL snippets.
Change-Id: Ie206cc946459f6befcfc2d520e35ad3ea3c0f1e0
Fix the following error on PHP 7.
> MediaWiki\Logger\Monolog\AvroFormatterTest::testDoesSomethingWhenSchemaAvailable
> Only variables should be passed by reference
> includes/debug/logger/monolog/AvroFormatter.php:143
Per https://github.com/researchgate/avro-php/blob/1.8.0/lib/avro/schema.php#L311-L314
the default for &$schemata is null, which is filled with a plain AvroNamedSchemata
instance. So this parameter is obsolete.
Either it needs to be assigned here and then passed. But since we don't use
it anywhere and don't pass it any constructor arguments, the default
should suffice.
Bug: T75176
Bug: T141588
Change-Id: I144bed8a78eb267a97e41f379b89c5faaae30625
Most of these are simply changing annotations to reflect
reality. If a function can return false to indicate failure
the @return should indicate it.
Some are fixing preg_match calls, preg match returns 1, 0 or false,
but the functions all claim to return booleans.
This is far from all the incorrect return types in mediawiki, there
are around 250 detected by phan, but have to start somewhere.
Change-Id: I1bbdfee6190747bde460f8a7084212ccafe169ef
* do not warn if something is overwritten with an identical value
(happens a lot with 'ip')
* move to LogstashFormatter so we can check for the value
* instead of spamming errors, just add a flag to the logstash data
Bug: T145133
Change-Id: I31caee865cd60c785126478ac75c9aefce78eaaf
This fixes the outstanding mis-spaced cast operators to bring them
into line with the coding standards on mediawiki.org (and with the
more common usage within this codebase).
Bug: T149545
Change-Id: Ib7bcf95bbee83d20c05f6d621ce7b4e1fb58a347
Normalize $level arguments to integers early to avoid confusion later
about what type the argument is.
Change-Id: I7305c0514f4383ec552afea2deb0e3fc6ba3fe8a
This class is in /libs and cannot depend on all of MediaWiki.
Replace the call with a simple debug() call instead.
Also, make the legacy logger route/format errors from the two
new DB log types (DBConnection, DBQuery) to the old wfLogDBError
locations, including MWDebug::debugMsg().
Change-Id: I64895d3f5b9a000d8186ab6a6ffb4b76a7e9ff40
By default the kafka implementation we use doesn't require any kind of
acknowledgment, it just throws messages into the wind and lets them sit
where they may. Implement an option for KafkaHandler to specify the
number of acks (number of replicas that must record the message) and
some error handling to throw exceptions as necessary when there is a
problem.
Bug: T135159
Change-Id: I859dc791072db407f908b2f36be0d6704f1a6256
When MediaWiki encounters an unhandled exception, the error message it produces
includes a randomly-generated token, which allows the exception details to be
looked up in the error logs. This is useful but narrow: would it not be useful
to have the ability to retrieve all log records associated with a particular
request, rather than just exception details? (Hint: yes.)
So: introduce the notion of a request-global unique ID, retrievable via
WebRequest::getRequestId(). When MediaWiki is behind Apache + mod_unique_id
(which provides the same facility) or some other software which sets a
UNIQUE_ID envvar, the value of that envvar is used as the request ID.
Otherwise, it is a randomly-generated 24-character string.
The request ID supplants exception-specific IDs; MWExceptionHandler::getLogId()
is deprecated, accordingly. The request ID is also added as an annotation to
all Monolog-processed log records, and is exposed client-side as 'wgRequestId'.
This allows developers to associate a page view with log records even when the
page view does not result in an unhandled exception. (For the WMF, I also
intend to add it as an annotation to profiling data).
The request ID is not a tracking token; it does not persist, and it is
associated with a backend request, not with a particular user or a particular
session. Like the data in the NewPP report, the request ID is designed to be
cacheable, so that if, for example, a developer notices something weird in the
HTML, s/he can associate the output with a backend request regardless of
whether the response was served from the cache or directly from the backend.
Some prior art:
* https://httpd.apache.org/docs/2.4/mod/mod_unique_id.html
* http://api.rubyonrails.org/classes/ActionDispatch/RequestId.html
* https://github.com/dabapps/django-log-request-id
* https://packagist.org/packages/php-middleware/request-id
* https://github.com/rhyselsmore/flask-request-id
Change-Id: Iaf90c20c330e0470b9b98627a0228cadefd301d1
Add a 'mwversion' value to log events processed by WikiProcessor to help
with classifying log events emitted by a wiki farm running mixed
versions of MediaWiki.
Bug: T125707
Change-Id: I5f5dfd051ebf251bec0d6e6a83a15e81f59540f3
Respect the "private" context variable for debug log events when passing
events from MediaWiki\Logger\LegacyLogger to MWDebug::debugMsg. Passing
debug log events marked as private to MWDebug was a regression
introduced by the PSR-3 logging system.
Restore handling of $dest argument to wfDebug which was removed in 1.25
with the PSR-3 logging conversion. The documentation for $dest = 'log'
has also been removed. This third debug log event handling option was
not implemented in the PSR-3 logging conversion in 1.25. A follow up
change will remove known usage of $dest = 'log' in core.
Bug: T122644
Change-Id: Ib1d999b8b54e584e3944b46e9163a700f11c2e72
Deployed usages of avro now use the new format, allowing
this old style will only cause pain to those that attempt
to use it in the future.
Change-Id: Id27ed7b529153ef7983b9fc3c1250b19dc4a516f
This ensures that, in case "composer install" has not been run,
the user will see the error message about setting up dependencies
(as opposed a plain "Class not found" error because some other
dependency was used first).
Change-Id: Ib6026123770d21cc9f8960a1de361c8178b1b044
Proposed upstream changes to Monolog\Logger will require an ability to
call setter methods on newly created Logger instances to tune them for
use in high volume logging situations. Adding support for making these
types of adjustments to MediaWiki's Monolog integration will benefit
users of the updated library when they land upstream.
Arbitrary setters are called by adding a 'calls' array to the logger
specification. This array uses method names as keys and method arguments
as values. This syntax mirrors the setter invocation behavior of
ObjectFactory with the notable omission of Closure expansion in the
argument list before calling the Logger's setter method.
Bug: T116550
Change-Id: I990c7f00f57451f14954542f5404491b2660a0b7
LoggerFactory::getInstance() will be called many times during the course
of handling a typical MediaWiki request. The interface_exists() guard
condition it uses is an attempt to provide an informative error message
when Composer managed libraries are not installed. This check is only
needed on the first invocation of getInstance() to be effective. Using
an additional boolean to guard the interface_exists() call will allow
the PHP runtime to avoid a potentially expensive (at least compared to
a static boolean comparison) function call.
This is the sort of thing that smells of premature optimization, but its
addition is in fact informed by examination of performance reports from
the Wikimedia production environment.
Bug: T115729
Change-Id: I437bcb5326b06145081f2b86f6c4d0c8dc1a318c
