This project is read-only.

Custome errors page not displaying after upgrade

Topics: Troubleshooting
Jun 26, 2012 at 11:58 PM
Edited Jun 27, 2012 at 6:32 PM

We recently upgraded to Orchard 1.4.2 and now when our app throws an exception instead of the custom error page we get the something went wrong sorry message.

<input name="content" type="hidden" />

Our web config looks like this:

		<customErrors mode="On" redirectMode="ResponseRedirect" defaultRedirect="~/CustomError/HttpError500">
			<error redirect="~/CustomError/HttpError404" statusCode="404" />
			<error redirect="~/CustomError/HttpError500" statusCode="500" />

Is this behavior intended? Because it seems like it should respect the web.config when an unhandled exception is thrown.


EDIT: The forums aren't letting me submit a reply. 

I don't want orchard to handle my exceptions. Is there some way to turn this feature off?

Jun 27, 2012 at 1:57 AM

yes, that's the intended behavior. That's not an unhandled exception: it's been handled.

Jun 27, 2012 at 7:18 PM

Let us assume that we do not want an error message to be rendered within an area of the page, but would rather use the 'classic' ASP.NET behavior of redirecting to a different page.  This is particularly useful if we are implementing custom modules where an exception that bubbes up to the controller action ought to result in presenting a special error page.

How could we provide our own error handling?

Jun 27, 2012 at 11:53 PM

You can't handle an exception that is already handled locally, but if the scenario is to handle specific exceptions in your own specific controller action, then try/catch still works. So does RedirectResult.

Jul 26, 2012 at 12:14 AM

What do you mean handled locally? If you mean orchard is now handling exceptions then is there some way to turn that feature off because the way orchard is handling the exceptions is breaking our site.

Jul 26, 2012 at 2:17 PM

I mean if it's caught and not rethrown. How can this possibly be breaking your site?

Jul 26, 2012 at 8:14 PM

We have widgets that need to display on the error page. So we have the 404 error page under a specific URL. We also have logging on that page so that we know what URLs happen. Orchard is intercepting the 404 and not changing the URL but (evidently?) returning a view with some orchard error text. It's the wrong text. It doesn't look right without the widgets. And it's not hitting the actions that log the errors for us so that we have a record.

Jul 27, 2012 at 1:42 PM

Isn't it bad practice to change the URL on a 404?

Jul 31, 2012 at 10:52 PM

Although we can prevent the 404 redirection, it's a side issue.

The main issue we're facing is that, pre-Orchard-1.4-upgrade, we were able to use the ASP.NET customErrors behavior defined in web.config to specify that certain errors (500, for example) would redirect to a custom page having its own layer, widgets, etc.  

After the upgrade, this behavior stopped working, so when Orchard displays errors, they don't match the desired appearance.

Aug 2, 2012 at 4:37 PM

I don't understand why you're not just adding a notfound.cshtml and errorpage.cshtml in your theme.

Nov 8, 2012 at 1:22 PM

It is easy to understand, if .Net developers want to use standard <customErrors mode="On"  then they should have the option to

Nov 8, 2012 at 1:33 PM

Hello all,

Sorry to resurrect this thread. I can make a new one if necessary but we need some advice on this issue.

Firstly, we have recently upgraded to Orchard 1.4, and so far we are loving it, so thank you for that!

However, this custom errors change poses a problem because up until now we were using the standard ASP.NET custom error pages. These had two key advantages for us:

  1. They are outside the Orchard context, and therefore can handle exceptions which Orchard itself throws, for example, during application initialization. I suppose that we could duplicate our custom error page content into ErrorPage.cshtml and NotFound.cshtml, and our ASP.NET custom error pages would still handle critical failures, but this seems wasteful.
  2. We use some custom logging logic in our custom error pages to push exception data to a centralised database. This is very helpful as we use a load balancer and it is tiresome to have to log onto each server and access App_Data/Logs to find which server has run the request which errored. I can't see a way to shoehorn this code into a simple view (NotFound/ErrorPage).

I have got around this problem for now by commenting out the UnhandledExceptionFilter in Orchard.Framework (can this be overridden using an extensibility point?)  but would prefer not to do this each time we upgrade.

Any feedback or suggestions on this problem would be great.

Many Thanks

Nov 8, 2012 at 9:26 PM

@chillibug: web.config is a shared resource. Things have to be done more collaboratively in Orchard. Just use what it's providing.

@bathspa: wasteful how?

It is not proper for a view to log errors. Orchard uses Log4Net, which can be configured to log exceptions in a different place than app_data\logs.