/**
* Overload this protected method because it’s called by all the
* built-in error methods (error404, missingAction, etc) and
* we need to fix a sneaky little bug caused by the fact that the
* CakeErrorController — while a subclass of AppController and designed
* to function like any other page controller — is not instantiated by the
* normal Dispatch process and instead has this parallel bootstrap
* in the ErrorHandler::__construct class. Somehow this was bunged a
* little and some of the normal dispatch steps aren’t executed.
* At a minimum, I know it’s not calling AppController::beforeFilter().
* In our lil app here we use that HEAVILY so this became a big problem for us.
*
* @see http://www.bradezone.com/2009/05/21/cakephp-beforefilter-and-the-error-error/
* @see ErrorHandler::_outputMessage()
*/
function _outputMessage($template)
{
static $virgin = true;

if ($virgin) {

$virgin = false;
$this->controller->beforeFilter();
}
parent::_outputMessage($template);

}

The real reason I’m posting again tho is to share one more missing step in this cake parallel-dispatch farce.. In the CakeErrorController::_construct() they call constructClasses() (to build models) and ->Component->initialize() BUT in normal dispatching, ->Component->startup($controller) is called AFTER the beforeFilter call.

Now, from what I saw, not having this on my app didn’t cause any ill effects. But that could just be a function of the Components i’m using not using that event.

So my complete workaround now is this:
// file /app/app_error.php

/**
* Overload this protected method because it’s called by all the built-in error methods (error404, missingAction, etc) and
* we need to fix a sneaky little bug caused by the fact that the CakeErrorController — while a subclass of AppController and designed
* to function like any other page controller — is not instantiated by the normal Dispatch process and instead has this parallel bootstrap
* in the ErrorHandler::__construct class. Somehow this was bunged a little and some of the normal dispatch steps aren’t executed.
* At a minimum, I know it’s not calling AppController::beforeFilter(). In our lil app here we use that HEAVILY so this became a big problem for us.
*
* @see A little discussion I participated in on the subject here: http://www.bradezone.com/2009/05/21/cakephp-beforefilter-and-the-error-error/
* @see ErrorHandler::_outputMessage()
*/
function _outputMessage($template)
{
static $virgin = true;

if ($virgin) {

// $controller->beforeFilter();

$virgin = false;

// The commented-out methods make-up the sequence of events that occurs during normal dispatch.
// I know for certain that we need to call beforeFilter. But as of writing this, there’s no benefit of me calling the others.
// And I have seen at least the constructClasses call done ele
$this->controller->beforeFilter();
$this->controller->Component->startup($this->controller);
}
parent::_outputMessage($template);

}

Before i saw your post I just assumed maybe the error controller was maybe clearing the output buffer before it was flushed and then including itself and never re-calling my controller methods. Nope. I was barking up the wrong tree.

Looking at the code again (in both the latest 1.2 and 1.3), I see that you’re correct that _outputMessage is always called. And what’s interesting is that _outputMessage includes a call to afterFilter but NOT beforeFilter. So now I’m more convinced than ever that this is simply an oversight by the CakePHP developers. By merely including a call to beforeFilter at the top of this function, our problems would be solved.

Therefore we don’t even need to bother with constructClasses since that is called in the CakeErrorController object created by the ErrorHandler. And I also believe we don’t need the static variable check, since we’re merely adding a beforeFilter call to match the afterFilter call that’s already there, so I ended up with the following code in my app_error.php file:

class AppError extends ErrorHandler {
    function _outputMessage($template) {
        $this->controller->beforeFilter();
        parent::_outputMessage($template);
    }
}

I see also that this is pretty close to what Georg had, only moving it into the private method that all the error methods use, so hooray for teamwork, everyone!

Specifically, by calling beforeFilter (and beforeRender if it’s needed) in the AppController constructor means that it’s going to run earlier than it normally would. You’re taking a very conventional event schedule and flipping it.

Now this isn’t horrible, of course. Sometimes hacks are part of life. But if you’ve got a superclass (AppController in this case) and you’ve got a conditional to execute code only when that class is being inherited by a specific subclass — that’s a pretty awful code smell. I mean, that rubs against the grain of OO design.

Still, I for one appreciate your solution and it helped my find my own solution. Which is pretty simple, actually:

Every one of the built-in error methods call the _outputMessage() function.

So I overloaded that:

function _outputMessage($template)
{
static $virgin = true;

if ($virgin) {

$virgin = false;
$this->controller->constructClasses();
$this->controller->beforeFilter();

}
parent::_outputMessage($template);

}

Done.

class AppError extends ErrorHandler
{
function myError($params)
{
$this->controller->beforeFilter();
$this->_outputMessage(‘my_error’);
}
}

controller->beforeFilter();
$this->_outputMessage(‘my_error’);
}
}
?>