These methods aren't identical, so consolidation isn't
immediately obvious, and creating dependencies is problematic
in error handling code given there is a lot of pressure on this
code to not by itself cause additional errors.
This means that maybe it's best to keep these inlined without
duplication, but at the very least we then need to remember
to keep these in sync. This duplication has been around for
a while now, but documentation can never come too late...
Change-Id: I60160f61c13c8e115d839acce222f110e30bc2f2
Previously an ugly {{SITENAME}} would show up for exceptions
that happened in the middle of processing a message
Change-Id: I4e3b675673dc3b74f89e4325f6a0a8b44162f478
It's annoying and pointless. Instead, have MWException write them to
standard output where we can catch them with ob_start().
Bug: T170028
Bug: T170029
Change-Id: Icd99c1c39d4a30d78c511d33948ef639e1b92455
This message contains the request url, which is semi-user controlled.
Most browsers percent escape < and > so its probably not exploitable
(curl is an exception here), but nonetheless its not good.
Bug: T178451
Change-Id: I19358471ddf1b28377aad8e0fb54797c817bb6f6
This will help us consolidate the various uses into one single
method which will help us drive standardisation of these defacto
widgets.
Hopefully, by being a method of the Html class, which has a very
low barrier for use will drive down the inconsistent display of
warning/error boxes across MediaWiki's products
Various usages of warningbox and errorbox have been ported over.
I've retained some more complicated usages which make use of the
parser (wrapWikiMsg) and any where id and class are medled with
- we'll probably want to consider whether we want to encourage
those going forward as they encourage adjusting the styling.
Bug: T166915
Change-Id: I2757e1f4ff2599e93a7257fc644cab69063896d2
Skip deprecation period because it is very unlikely that anyone used this:
it does not appear anywhere on gerrit/git, no nontrivial google hits,
the documentation has been flat out wrong for 9 years and no one
noticed it, and the whole feature is fairly useless as you need to declare
it separately for every single exception class you expect.
Change-Id: I85844a238d3135d05eeba10331149624b04bafe2
Partially revert 00bee02 by restoring the prior MWException::report()
logic. MWExceptionRenderer does not handle all of the MWException
subclasses that somehow modify the default render() behavior. Notable
among these is Flow\Exception\FlowException and its subclasses which
modify the `$wgOut` global to divert HTML output to alternate locations.
Bug: T147122
Change-Id: Ibe3cadca229ce21ed0a3a2482433e3a22b5f5646
* This handles the work of showing exceptions so that
MWException does not have too.
* Simplify the DBError classes to regular Exception
classes. Lots of pointless prettification has been
removed, but DBConnectionError still gets the usual
special treatment of a fallback page and Google form.
* Remove hacky file cache fallback code that probably
did not work.
* Make MWExceptionHandler::report() wrap
MWExceptionExposer::output().
* Make MWException::runHooks() wrap
MWExceptionExposer::runHooks().
Change-Id: I5dfdc84e94ddac65417226cf7c84513ebb9f9faa
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
Also:
* Update wfHttpError() to use uppercase DOCTYPE, to match other code
such as Html.php, wfThumbError(), HttpError.php, etc.
Change-Id: I4027e7fe1a138b03f78797b6d1bfe7bd1064d360
This is the only case in the MediaWiki code base where a custom
message is used. Supporting in the standard HttpStatus library
would require a $customMessage parameter which seems unnecessary.
Additional information should be communicated using additional
HTTP response headers or inside the body content.
Besides, in current PHP versions and in Apache 2.4, the message is
already being ignored and replaced with the standard message (see T100984).
Bug: T100984
Change-Id: I11b58a2f3ce22568479d36027d15e5c6f428ff15
These errors usually need to be reported, so it's better for the user
to understand them as much as possible.
Bug: T40095
Change-Id: Ibd2f984b66acb9150400126f21acf7cc5fc85acd
* Remove use of 'error' where it's redundant.
* Remove call to logException from responsibility of MWException.
Call from exception handler instead.
Change-Id: I8764cf5df87b226813c9b9cf99f9b4f3fa4b7c92
The replace of $n params can also be done using the Message class. In
case there are no message keys, the RawMessage class is used.
Deprecated wfMsgReplaceArgs, but added no warning, because it is used in
some extensions and from deprecated functions
Change-Id: I62091b09e4490e59ed7258566e0ddf2f8ee799d2
Ideally we wouldn't have sent headers yet, but in some weird
code paths where we output stuff raw (like Export) we might
have already sent them.
All depends on when the failure happened.
Should silence all of the "headers already sent" being seen
from exports.
Change-Id: I12e0532e93d30b2255f73a9d0e017c73e30c3e28
These files have all had treatment before, and these occurrences have either
been missed or have been introduced after.
Change-Id: I06cdab4616b5bff47c85152df28f18c861730a23
Swapped some "$var type" to "type $var" or added missing types
before the $var. Changed some other types to match the more common
spelling. Makes beginning of some text in captial.
Change-Id: I8c9f30128b46086064326708a4878228ba459447
The MWException::getPageTitle method is wrapping the page title
in the 'pagetitle' ($1 - sitename) message, but OutputPage does
this as well when outputing <title>.
OutputPage::prepareErrorPage takes the first parameter as page
title (unwrapped, appears in <h1>,) and the second optional one
is for <title>, which (if omitted, like before) results in
pagetitle being applied by OutputPage.
Now that we specify them separately, this also removes the
sitename from the <h1> on the page, which always looked weird.
It also fixes DBQueryError (extends MWException) where previously
no sitename was added, it just returns 'databaseerror' from
its DBQueryError::getPageTitle() method.
Change-Id: I85d65d89e72b4497a050f440524ff6f959518b88
