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
