In the case that there is a request data type parser raises an
exception, or startup() otherwise fails the error page should be created
correctly. While I'm not able to write a test case for this, manual
testing confirmed the fix.
Refs #5311
Not sure why this was here, but constructors shouldn't return a value. Nothing in the docs says that a controller's implementation of appError should return a value either. So I figure this was a mistake.
This statement does not serve a purpose anymore.
In a long forgotten world it indicated the main version number of PHP which the code in the file was compatible to.
http://pear.php.net/manual/en/standards.sample.php
But since PHP 5.1 and later this is only marginally true.
Thus I propose to remove it from CakePHP.
When Router::parseExtensions() is enabled for a file extension
that does not map to a view an infinite loop of attempting to render
View/$ext/error500.ctp will be entered. When catching
a MissingViewException check if we were trying to render an
error500. If we were, revert to safe rendering as we might enter a loop.
If an exception was raised in the AppController::beforeFilter(),
requests for content-type responses would render as HTML. Extracting the
startupProcess() allows us to keep a reference to the error controller,
which can be used to force startup RequestHandlerComponent if its
enabled.
Fixes#3389
Commit 7416c53 shows error message from last exception instead of first one
and also displays framework specific error messages instead of generic ones with debug off.
We don't want either.
This reverts commit 7416c530a2.
Since many exceptions do not have its own 'template' file, customized
APP/Controller/CakeErrorController with its own list of helpers could be
ignored.
This happens becase ExceptionRenderer is forced to to use _outputMessageSafe
when a template is missing. This causes Controller::$helpers to be reset with
default values.
