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
e8fefb931d