@Teknoid; subsequent to my earlier posting I did find your blog post
and changed from writing Configure::write('debug', 1) at the point of
calling cakeError to setting debug to 1 in the __construct() method of
app_error so many thanks for pointing out that this could be done.You asked what errors do you want to display; well the first main thing to note is that in my experience, users hate it when they do something and just get a white screen of death with no indication of what went wrong. So with that said, this is an example use from the new version of EventHQ (http://www.eventhq.co.uk) I am working on: Users can normally enter an event to look at (e.g. http://account-name.eventhq.co.uk/conference-name. If they mistype the conference name or copy/paste it incorrectly or whatever and EventHQ cannot find the event, use a custom app_error method to show a 404 page together with a dropdown list of all events available for that account that the user can choose from and navigate to. I accept that I could achieve exactly the same thing in other ways, but it seemed to me that encapsulating all error-related functionality (where I am lumping PHP/Cake/application errors into 'error-related') into a single app_error controller and views is a really good thing to do and a great piece of functionality to have. The CakePHP book also seems to suggest that cakeError is there for exactly this purpose and is intended to be extended with custom methods. So, the OPs question 'Is this really the desired behavior? It doesn't seem to be documented?' still stands, although this thread and your blog post have been exceptionally useful in showing how to workaround the issue. ianh On Feb 6, 6:30 pm, teknoid <[email protected]> wrote: > What errors do you want to display to the user, while running in > production mode? > > That being asked, you might take a look here on how to handle this > situation:http://teknoid.wordpress.com/2008/08/29/dealing-with-errors-in-cakephp/ > > On Feb 6, 11:54 am, maxmil <[email protected]> wrote: > > > I have found the same problem. > > > Is this really deliberate? > > > It takes quite a bit of power away from the cakephp errorHandling > > mechanism if it is and is very naughty not to mention it in the error > > handling pages of the manual! > > > My solution has been to use: > > > $this->render('/errors/custom_error'); > > > instead invoking $this->cakeError. > > > On Jan 16, 11:55 am, ianh <[email protected]> wrote: > > > > Hmm. Just found the same thing. Seems to be to do with lines 110 to > > > 117 in core error.php __construct method > > > if ($method !== 'error') { > > > if (Configure::read() == 0) { > > > $method = 'error404'; > > > if (isset($code) && $code == 500) { > > > $method = 'error500'; > > > } > > > } > > > > } > > > > So if you trigger cakeError with a method like 'test' then that works > > > fine unless Configure::read() (which seems to return debug by default) > > > is 0 then it gets reset. So you can create a custom method in > > > app_error called 'error' and that will work regardless of debug level, > > > but any custom errors will only work when debug is > 0. > > > > The code suggests this is intended but the book doesnt make any > > > reference to it. Also the tests dont shed any light as of course tests > > > cannot be run when debug is 0! Does anybody know what the intention > > > behind this is please? > > > > Anyway, as Mike says above, the solution Im now using is to include a > > > Configure::write('debug', 1); line wherever I call cakeError for a > > > custom method. > > > > Thx, ianh --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "CakePHP" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/cake-php?hl=en -~----------~----~----~----~------~----~------~--~---
