wiki.techinc.nl/includes/exception/MWException.php

267 lines
7 KiB
PHP
Raw Normal View History

<?php
/**
* This program is free software; you can redistribute it and/or modify
* it under the terms of the GNU General Public License as published by
* the Free Software Foundation; either version 2 of the License, or
* (at your option) any later version.
*
* This program is distributed in the hope that it will be useful,
* but WITHOUT ANY WARRANTY; without even the implied warranty of
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
* GNU General Public License for more details.
*
* You should have received a copy of the GNU General Public License along
* with this program; if not, write to the Free Software Foundation, Inc.,
* 51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA.
* http://www.gnu.org/copyleft/gpl.html
*
* @file
*/
/**
* MediaWiki exception
*
* @newable
* @stable to extend
*
* @ingroup Exception
*/
class MWException extends Exception {
/**
* Should the exception use $wgOut to output the error?
*
* @return bool
*/
public function useOutputPage() {
return $this->useMessageCache() &&
!empty( $GLOBALS['wgFullyInitialised'] ) &&
!empty( $GLOBALS['wgOut'] ) &&
!defined( 'MEDIAWIKI_INSTALL' ) &&
// Don't send a skinned HTTP 500 page to API clients.
!defined( 'MW_API' );
}
/**
* Whether to log this exception in the exception debug log.
*
* @stable to override
*
* @since 1.23
* @return bool
*/
public function isLoggable() {
return true;
}
/**
* Can the extension use the Message class/wfMessage to get i18n-ed messages?
*
* @stable to override
*
* @return bool
*/
public function useMessageCache() {
foreach ( $this->getTrace() as $frame ) {
if ( isset( $frame['class'] ) && $frame['class'] === LocalisationCache::class ) {
return false;
}
}
return true;
}
/**
* Get a message from i18n
*
* @param string $key Message name
* @param string $fallback Default message if the message cache can't be
* called by the exception
* @param mixed ...$params To pass to wfMessage()
* @return string Message with arguments replaced
*/
public function msg( $key, $fallback, ...$params ) {
// FIXME: Keep logic in sync with MWExceptionRenderer::msg.
$res = false;
if ( $this->useMessageCache() ) {
try {
$res = wfMessage( $key, ...$params )->text();
} catch ( Exception $e ) {
}
}
if ( $res === false ) {
exception: Simplify MWExceptionRenderer to reduce influence of config Remove use of two configuration globals. This follows-up to commit 47adb6d65a (I1a691f01cd82e60) which aimed to access all config via MediaWikiServices, but that isn't safe during error handling. These two were only used in the low-level "plain text" and "basic HTML" error pages, which already can't have any branding, skinning or localisation; and are not how most exceptions are rendered. in those edge cases, we can use the name of the software instead of (trying) to use the name of the site. == Remove use of $wgSitename == In msg() and reportHTML(), remove use of $wgSitename in favour of a generic fallback matching DefaulSettings.php. This does not affect the common case of runtime fatals and timeouts, as we're only changing the fallback after wfMessage() fails in msg(), or when OutputPage is unavailable, which is typically only if services, localisation or DB are also down (or not yet loaded). Most exceptions happen when and after those have initialised fine. Test case 1: (Clean state) Edit ViewAction::show() to add `throw new RuntimeException();` as its first statement, then try to view the main page. This error page is unchanged. It is skinned, localised, and still uses the configured sitename in the doc title. Test case 2: Edit index.php to call foo() instead of wfIndexMain(), then try to view the main page. Before, this "minimal HTML" error page would have a doc title of "Internal error - MyWiki", and now "Internal error - MediaWiki". Test case 3: (Clean state) Edit Message::text() to add `throw new RuntimeException();`, then try to view the main page. This results in a "plain text" error page that doesn't even have an HTML doc, and is also unchanged. == Remove use of $wgMimeType == In output(), remove use of $wgMimeType and remove the Content-Type header that it was used for. This was redundant because the next statements (reportHTML) already outputs Content-type. In reportHTML, we sometimes delegate to OutputPage (if safe) and that honours $wgMimeType already. In other cases, it is handled inline in with a basic HTML error page, and that branch also sets the Content-Type header already. In one case (reportOutageHTML) a header was not yet set. For that one, I've added the missing header call and made it explicitly text/html. This is technically a bugfix, because our basic HTML error page is HTML5, whereas $wgMimeType (which exists to allow enabling XHTML) can be XHTML which we weren't following. In OutputPage and Html::htmlHeader that would normally result in outputting `<?xml`. Test case: Edit ViewAction::show(), and add `throw new RuntimeException();` as its first statement, then try to view the main page. In devtools>network, there is still a proper Content-Type and charset on the error page document. Change-Id: I03cfa2b6155fb711582164852e7cab4c325a1b92
2022-01-12 23:05:34 +00:00
// Fallback to static message text and generic sitename.
// Avoid live config as this must work before Setup/MediaWikiServices finish.
$res = wfMsgReplaceArgs( $fallback, $params );
$res = strtr( $res, [
exception: Simplify MWExceptionRenderer to reduce influence of config Remove use of two configuration globals. This follows-up to commit 47adb6d65a (I1a691f01cd82e60) which aimed to access all config via MediaWikiServices, but that isn't safe during error handling. These two were only used in the low-level "plain text" and "basic HTML" error pages, which already can't have any branding, skinning or localisation; and are not how most exceptions are rendered. in those edge cases, we can use the name of the software instead of (trying) to use the name of the site. == Remove use of $wgSitename == In msg() and reportHTML(), remove use of $wgSitename in favour of a generic fallback matching DefaulSettings.php. This does not affect the common case of runtime fatals and timeouts, as we're only changing the fallback after wfMessage() fails in msg(), or when OutputPage is unavailable, which is typically only if services, localisation or DB are also down (or not yet loaded). Most exceptions happen when and after those have initialised fine. Test case 1: (Clean state) Edit ViewAction::show() to add `throw new RuntimeException();` as its first statement, then try to view the main page. This error page is unchanged. It is skinned, localised, and still uses the configured sitename in the doc title. Test case 2: Edit index.php to call foo() instead of wfIndexMain(), then try to view the main page. Before, this "minimal HTML" error page would have a doc title of "Internal error - MyWiki", and now "Internal error - MediaWiki". Test case 3: (Clean state) Edit Message::text() to add `throw new RuntimeException();`, then try to view the main page. This results in a "plain text" error page that doesn't even have an HTML doc, and is also unchanged. == Remove use of $wgMimeType == In output(), remove use of $wgMimeType and remove the Content-Type header that it was used for. This was redundant because the next statements (reportHTML) already outputs Content-type. In reportHTML, we sometimes delegate to OutputPage (if safe) and that honours $wgMimeType already. In other cases, it is handled inline in with a basic HTML error page, and that branch also sets the Content-Type header already. In one case (reportOutageHTML) a header was not yet set. For that one, I've added the missing header call and made it explicitly text/html. This is technically a bugfix, because our basic HTML error page is HTML5, whereas $wgMimeType (which exists to allow enabling XHTML) can be XHTML which we weren't following. In OutputPage and Html::htmlHeader that would normally result in outputting `<?xml`. Test case: Edit ViewAction::show(), and add `throw new RuntimeException();` as its first statement, then try to view the main page. In devtools>network, there is still a proper Content-Type and charset on the error page document. Change-Id: I03cfa2b6155fb711582164852e7cab4c325a1b92
2022-01-12 23:05:34 +00:00
'{{SITENAME}}' => 'MediaWiki',
] );
}
return $res;
}
/**
* If $wgShowExceptionDetails is true, return a HTML message with a
* backtrace to the error, otherwise show a message to ask to set it to true
* to show that information.
*
* @stable to override
*
* @return string Html to output
*/
public function getHTML() {
global $wgShowExceptionDetails;
if ( $wgShowExceptionDetails ) {
return '<p>' . nl2br( htmlspecialchars( MWExceptionHandler::getLogMessage( $this ) ) ) .
'</p><p>Backtrace:</p><p>' .
nl2br( htmlspecialchars( MWExceptionHandler::getRedactedTraceAsString( $this ) ) ) .
"</p>\n";
} else {
Provide a unique request identifier 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
2016-03-25 01:43:23 +00:00
$logId = WebRequest::getRequestId();
$type = static::class;
return Html::errorBox(
htmlspecialchars(
'[' . $logId . '] ' .
gmdate( 'Y-m-d H:i:s' ) . ": " .
$this->msg( "internalerror-fatal-exception",
"Fatal exception of type $1",
$type,
$logId,
MWExceptionHandler::getURL()
)
) ) .
"<!-- Set \$wgShowExceptionDetails = true; " .
"at the bottom of LocalSettings.php to show detailed " .
"debugging information. -->";
}
}
/**
* Get the text to display when reporting the error on the command line.
* If $wgShowExceptionDetails is true, return a text message with a
* backtrace to the error.
*
* @stable to override
*
* @return string
*/
public function getText() {
global $wgShowExceptionDetails;
if ( $wgShowExceptionDetails ) {
return MWExceptionHandler::getLogMessage( $this ) .
"\nBacktrace:\n" . MWExceptionHandler::getRedactedTraceAsString( $this ) . "\n";
} else {
return "Set \$wgShowExceptionDetails = true; " .
"in LocalSettings.php to show detailed debugging information.\n";
}
}
/**
* Return the title of the page when reporting this error in a HTTP response.
*
* @stable to override
*
* @return string
*/
public function getPageTitle() {
return $this->msg( 'internalerror', 'Internal error' );
}
/**
* Output the exception report using HTML.
* @stable to override
*/
public function reportHTML() {
exception: Simplify MWExceptionRenderer to reduce influence of config Remove use of two configuration globals. This follows-up to commit 47adb6d65a (I1a691f01cd82e60) which aimed to access all config via MediaWikiServices, but that isn't safe during error handling. These two were only used in the low-level "plain text" and "basic HTML" error pages, which already can't have any branding, skinning or localisation; and are not how most exceptions are rendered. in those edge cases, we can use the name of the software instead of (trying) to use the name of the site. == Remove use of $wgSitename == In msg() and reportHTML(), remove use of $wgSitename in favour of a generic fallback matching DefaulSettings.php. This does not affect the common case of runtime fatals and timeouts, as we're only changing the fallback after wfMessage() fails in msg(), or when OutputPage is unavailable, which is typically only if services, localisation or DB are also down (or not yet loaded). Most exceptions happen when and after those have initialised fine. Test case 1: (Clean state) Edit ViewAction::show() to add `throw new RuntimeException();` as its first statement, then try to view the main page. This error page is unchanged. It is skinned, localised, and still uses the configured sitename in the doc title. Test case 2: Edit index.php to call foo() instead of wfIndexMain(), then try to view the main page. Before, this "minimal HTML" error page would have a doc title of "Internal error - MyWiki", and now "Internal error - MediaWiki". Test case 3: (Clean state) Edit Message::text() to add `throw new RuntimeException();`, then try to view the main page. This results in a "plain text" error page that doesn't even have an HTML doc, and is also unchanged. == Remove use of $wgMimeType == In output(), remove use of $wgMimeType and remove the Content-Type header that it was used for. This was redundant because the next statements (reportHTML) already outputs Content-type. In reportHTML, we sometimes delegate to OutputPage (if safe) and that honours $wgMimeType already. In other cases, it is handled inline in with a basic HTML error page, and that branch also sets the Content-Type header already. In one case (reportOutageHTML) a header was not yet set. For that one, I've added the missing header call and made it explicitly text/html. This is technically a bugfix, because our basic HTML error page is HTML5, whereas $wgMimeType (which exists to allow enabling XHTML) can be XHTML which we weren't following. In OutputPage and Html::htmlHeader that would normally result in outputting `<?xml`. Test case: Edit ViewAction::show(), and add `throw new RuntimeException();` as its first statement, then try to view the main page. In devtools>network, there is still a proper Content-Type and charset on the error page document. Change-Id: I03cfa2b6155fb711582164852e7cab4c325a1b92
2022-01-12 23:05:34 +00:00
global $wgOut;
if ( $this->useOutputPage() ) {
$wgOut->prepareErrorPage( $this->getPageTitle() );
// Manually set the html title, since sometimes
// {{SITENAME}} does not get replaced for exceptions
// happening inside message rendering.
$wgOut->setHTMLTitle(
exception: Simplify MWExceptionRenderer to reduce influence of config Remove use of two configuration globals. This follows-up to commit 47adb6d65a (I1a691f01cd82e60) which aimed to access all config via MediaWikiServices, but that isn't safe during error handling. These two were only used in the low-level "plain text" and "basic HTML" error pages, which already can't have any branding, skinning or localisation; and are not how most exceptions are rendered. in those edge cases, we can use the name of the software instead of (trying) to use the name of the site. == Remove use of $wgSitename == In msg() and reportHTML(), remove use of $wgSitename in favour of a generic fallback matching DefaulSettings.php. This does not affect the common case of runtime fatals and timeouts, as we're only changing the fallback after wfMessage() fails in msg(), or when OutputPage is unavailable, which is typically only if services, localisation or DB are also down (or not yet loaded). Most exceptions happen when and after those have initialised fine. Test case 1: (Clean state) Edit ViewAction::show() to add `throw new RuntimeException();` as its first statement, then try to view the main page. This error page is unchanged. It is skinned, localised, and still uses the configured sitename in the doc title. Test case 2: Edit index.php to call foo() instead of wfIndexMain(), then try to view the main page. Before, this "minimal HTML" error page would have a doc title of "Internal error - MyWiki", and now "Internal error - MediaWiki". Test case 3: (Clean state) Edit Message::text() to add `throw new RuntimeException();`, then try to view the main page. This results in a "plain text" error page that doesn't even have an HTML doc, and is also unchanged. == Remove use of $wgMimeType == In output(), remove use of $wgMimeType and remove the Content-Type header that it was used for. This was redundant because the next statements (reportHTML) already outputs Content-type. In reportHTML, we sometimes delegate to OutputPage (if safe) and that honours $wgMimeType already. In other cases, it is handled inline in with a basic HTML error page, and that branch also sets the Content-Type header already. In one case (reportOutageHTML) a header was not yet set. For that one, I've added the missing header call and made it explicitly text/html. This is technically a bugfix, because our basic HTML error page is HTML5, whereas $wgMimeType (which exists to allow enabling XHTML) can be XHTML which we weren't following. In OutputPage and Html::htmlHeader that would normally result in outputting `<?xml`. Test case: Edit ViewAction::show(), and add `throw new RuntimeException();` as its first statement, then try to view the main page. In devtools>network, there is still a proper Content-Type and charset on the error page document. Change-Id: I03cfa2b6155fb711582164852e7cab4c325a1b92
2022-01-12 23:05:34 +00:00
$this->msg( 'pagetitle', '$1 - MediaWiki', $this->getPageTitle() )
);
$wgOut->addHTML( $this->getHTML() );
exception: Simplify MWExceptionRenderer to reduce influence of config Remove use of two configuration globals. This follows-up to commit 47adb6d65a (I1a691f01cd82e60) which aimed to access all config via MediaWikiServices, but that isn't safe during error handling. These two were only used in the low-level "plain text" and "basic HTML" error pages, which already can't have any branding, skinning or localisation; and are not how most exceptions are rendered. in those edge cases, we can use the name of the software instead of (trying) to use the name of the site. == Remove use of $wgSitename == In msg() and reportHTML(), remove use of $wgSitename in favour of a generic fallback matching DefaulSettings.php. This does not affect the common case of runtime fatals and timeouts, as we're only changing the fallback after wfMessage() fails in msg(), or when OutputPage is unavailable, which is typically only if services, localisation or DB are also down (or not yet loaded). Most exceptions happen when and after those have initialised fine. Test case 1: (Clean state) Edit ViewAction::show() to add `throw new RuntimeException();` as its first statement, then try to view the main page. This error page is unchanged. It is skinned, localised, and still uses the configured sitename in the doc title. Test case 2: Edit index.php to call foo() instead of wfIndexMain(), then try to view the main page. Before, this "minimal HTML" error page would have a doc title of "Internal error - MyWiki", and now "Internal error - MediaWiki". Test case 3: (Clean state) Edit Message::text() to add `throw new RuntimeException();`, then try to view the main page. This results in a "plain text" error page that doesn't even have an HTML doc, and is also unchanged. == Remove use of $wgMimeType == In output(), remove use of $wgMimeType and remove the Content-Type header that it was used for. This was redundant because the next statements (reportHTML) already outputs Content-type. In reportHTML, we sometimes delegate to OutputPage (if safe) and that honours $wgMimeType already. In other cases, it is handled inline in with a basic HTML error page, and that branch also sets the Content-Type header already. In one case (reportOutageHTML) a header was not yet set. For that one, I've added the missing header call and made it explicitly text/html. This is technically a bugfix, because our basic HTML error page is HTML5, whereas $wgMimeType (which exists to allow enabling XHTML) can be XHTML which we weren't following. In OutputPage and Html::htmlHeader that would normally result in outputting `<?xml`. Test case: Edit ViewAction::show(), and add `throw new RuntimeException();` as its first statement, then try to view the main page. In devtools>network, there is still a proper Content-Type and charset on the error page document. Change-Id: I03cfa2b6155fb711582164852e7cab4c325a1b92
2022-01-12 23:05:34 +00:00
// Content-Type is set by OutputPage::output
$wgOut->output();
} else {
exception: Simplify MWExceptionRenderer to reduce influence of config Remove use of two configuration globals. This follows-up to commit 47adb6d65a (I1a691f01cd82e60) which aimed to access all config via MediaWikiServices, but that isn't safe during error handling. These two were only used in the low-level "plain text" and "basic HTML" error pages, which already can't have any branding, skinning or localisation; and are not how most exceptions are rendered. in those edge cases, we can use the name of the software instead of (trying) to use the name of the site. == Remove use of $wgSitename == In msg() and reportHTML(), remove use of $wgSitename in favour of a generic fallback matching DefaulSettings.php. This does not affect the common case of runtime fatals and timeouts, as we're only changing the fallback after wfMessage() fails in msg(), or when OutputPage is unavailable, which is typically only if services, localisation or DB are also down (or not yet loaded). Most exceptions happen when and after those have initialised fine. Test case 1: (Clean state) Edit ViewAction::show() to add `throw new RuntimeException();` as its first statement, then try to view the main page. This error page is unchanged. It is skinned, localised, and still uses the configured sitename in the doc title. Test case 2: Edit index.php to call foo() instead of wfIndexMain(), then try to view the main page. Before, this "minimal HTML" error page would have a doc title of "Internal error - MyWiki", and now "Internal error - MediaWiki". Test case 3: (Clean state) Edit Message::text() to add `throw new RuntimeException();`, then try to view the main page. This results in a "plain text" error page that doesn't even have an HTML doc, and is also unchanged. == Remove use of $wgMimeType == In output(), remove use of $wgMimeType and remove the Content-Type header that it was used for. This was redundant because the next statements (reportHTML) already outputs Content-type. In reportHTML, we sometimes delegate to OutputPage (if safe) and that honours $wgMimeType already. In other cases, it is handled inline in with a basic HTML error page, and that branch also sets the Content-Type header already. In one case (reportOutageHTML) a header was not yet set. For that one, I've added the missing header call and made it explicitly text/html. This is technically a bugfix, because our basic HTML error page is HTML5, whereas $wgMimeType (which exists to allow enabling XHTML) can be XHTML which we weren't following. In OutputPage and Html::htmlHeader that would normally result in outputting `<?xml`. Test case: Edit ViewAction::show(), and add `throw new RuntimeException();` as its first statement, then try to view the main page. In devtools>network, there is still a proper Content-Type and charset on the error page document. Change-Id: I03cfa2b6155fb711582164852e7cab4c325a1b92
2022-01-12 23:05:34 +00:00
self::header( 'Content-Type: text/html; charset=UTF-8' );
echo "<!DOCTYPE html>\n" .
'<html><head>' .
// Mimic OutputPage::setPageTitle behaviour
'<title>' .
exception: Simplify MWExceptionRenderer to reduce influence of config Remove use of two configuration globals. This follows-up to commit 47adb6d65a (I1a691f01cd82e60) which aimed to access all config via MediaWikiServices, but that isn't safe during error handling. These two were only used in the low-level "plain text" and "basic HTML" error pages, which already can't have any branding, skinning or localisation; and are not how most exceptions are rendered. in those edge cases, we can use the name of the software instead of (trying) to use the name of the site. == Remove use of $wgSitename == In msg() and reportHTML(), remove use of $wgSitename in favour of a generic fallback matching DefaulSettings.php. This does not affect the common case of runtime fatals and timeouts, as we're only changing the fallback after wfMessage() fails in msg(), or when OutputPage is unavailable, which is typically only if services, localisation or DB are also down (or not yet loaded). Most exceptions happen when and after those have initialised fine. Test case 1: (Clean state) Edit ViewAction::show() to add `throw new RuntimeException();` as its first statement, then try to view the main page. This error page is unchanged. It is skinned, localised, and still uses the configured sitename in the doc title. Test case 2: Edit index.php to call foo() instead of wfIndexMain(), then try to view the main page. Before, this "minimal HTML" error page would have a doc title of "Internal error - MyWiki", and now "Internal error - MediaWiki". Test case 3: (Clean state) Edit Message::text() to add `throw new RuntimeException();`, then try to view the main page. This results in a "plain text" error page that doesn't even have an HTML doc, and is also unchanged. == Remove use of $wgMimeType == In output(), remove use of $wgMimeType and remove the Content-Type header that it was used for. This was redundant because the next statements (reportHTML) already outputs Content-type. In reportHTML, we sometimes delegate to OutputPage (if safe) and that honours $wgMimeType already. In other cases, it is handled inline in with a basic HTML error page, and that branch also sets the Content-Type header already. In one case (reportOutageHTML) a header was not yet set. For that one, I've added the missing header call and made it explicitly text/html. This is technically a bugfix, because our basic HTML error page is HTML5, whereas $wgMimeType (which exists to allow enabling XHTML) can be XHTML which we weren't following. In OutputPage and Html::htmlHeader that would normally result in outputting `<?xml`. Test case: Edit ViewAction::show(), and add `throw new RuntimeException();` as its first statement, then try to view the main page. In devtools>network, there is still a proper Content-Type and charset on the error page document. Change-Id: I03cfa2b6155fb711582164852e7cab4c325a1b92
2022-01-12 23:05:34 +00:00
htmlspecialchars( $this->msg( 'pagetitle', '$1 - MediaWiki', $this->getPageTitle() ) ) .
'</title>' .
'<style>body { font-family: sans-serif; margin: 0; padding: 0.5em 2em; }</style>' .
"</head><body>\n";
echo $this->getHTML();
echo "</body></html>\n";
}
}
/**
* Output a report about the exception and takes care of formatting.
* It will be either HTML or plain text based on isCommandLine().
*
* @stable to override
*/
public function report() {
if ( defined( 'MW_API' ) ) {
self::header( 'MediaWiki-API-Error: internal_api_error_' . static::class );
}
if ( self::isCommandLine() ) {
$message = $this->getText();
$this->writeToCommandLine( $message );
} else {
self::statusHeader( 500 );
$this->reportHTML();
}
}
/**
* Write a message to stderr falling back to stdout if stderr unavailable
*
* @param string $message
* @suppress SecurityCheck-XSS
*/
private function writeToCommandLine( $message ) {
// T17602: STDERR may not be available
if ( !defined( 'MW_PHPUNIT_TEST' ) && defined( 'STDERR' ) ) {
fwrite( STDERR, $message );
} else {
echo $message;
}
}
/**
* Check whether we are in command line mode or not to report the exception
* in the correct format.
*
* @return bool
*/
public static function isCommandLine() {
return !empty( $GLOBALS['wgCommandLineMode'] );
}
/**
* Send a header, if we haven't already sent them. We shouldn't,
* but sometimes we might in a weird case like Export
* @param string $header
*/
private static function header( $header ) {
if ( !headers_sent() ) {
header( $header );
}
}
private static function statusHeader( $code ) {
if ( !headers_sent() ) {
HttpStatus::header( $code );
}
}
}