Umbraco is built upon Microsoft's .NET Framework and is using ASP.NET. This provides a number of options when setting up custom error pages on your website.
Custom error handling might make your site look more on-brand and minimize the impact of errors on user experience. An example, a custom 404 with some helpful links (or a search function) could bring some value to the site.
This article contains guides on how to create custom error pages for the following types of errors:
One way is to watch for error events and serve corresponding pages via C# code.
In this method, we will use a 404 page created via the backoffice.
First, create a new Document Type (though you could also use a more generic Document Type if you already have one) called Page404. Make sure the permissions are set to create it under Content. Properties on this Document Type are optional - in most cases, the 404 not found page would be static. Make sure to assign (and fill out) the template for your error page, and then create it in Content.
Once all of that is done, grab your published error page's ID, GUID or path and head on over to the appsettings.json
.
The value for error pages can be:
A content item's GUID ID (example: 26C1D84F-C900-4D53-B167-E25CC489DAC8)
An XPath statement (example: //errorPages[@nodeName='My cool error']
A content item's integer ID (example: 1234)
The current implementation of XPath is suboptimal, marked as obsolete, and scheduled for removal in Umbraco 14. The replacement for ContentXPath is IContentLastChanceFinder.
If you have implemented XPath in previous versions and upgraded to v13 you might encounter issues with XPath. This article will be updated when we have more details on how the article should be updated.
That is where the value you grabbed earlier comes in. Fill it out like so:
The above sample uses a GUID value.
With this approach, you can set different 404 pages for different languages (cultures) - such as en-us
, it
etc.
If you are hosting your site on Umbraco Cloud, using an XPath statement is the best approach. This is because content IDs might differ across Cloud environments.
XPath example:
In the above XPath example //errorPages
is the DocTypeAlias
Id example:
The above example uses an integer Id value.
Sometimes you might experience issues with booting up your Umbraco project. This could be a brand new project, or it could be an existing project after an upgrade.
When there is an error during boot you will be presented with a generic error page.
In order to customize this error page it is recommend that you create a new HTML file using the name BootFailed.html
. The file must be in a folder config/errors
in the wwwroot
on the Physical file system.
The BootFailed.html
page will only be shown if debugging is disabled in the appsettings.json
file i.e.
The full error can always be found in the log file.
The following steps guides you through setting up a page for internal server errors (500 errors).
Create a ~/controllers
folder in your Umbraco web project.
Create a file in this folder, called ErrorController.cs
.
Add the following code to the file:
Namespace replace [YOUR_PROJECT_NAME] by the actual project name. In Visual Studio you can use Sync Namespaces from the project context menu (in Solution Explorer View).
Add an entry in appSettings.json
for the new route "Error" like so
Create the redirect pages from 1. step as regular content nodes in the backoffice. They should neither appear in navigation menus or sitemaps. In this example you would create under root node Statuscodes
with a subnode 500
.
Update Program.cs
To test this locally, in Visual Studio replace app.UseDeveloperExceptionPage();
by app.UseExceptionHandler("/error");
. Otherwise you will get the default error page with stack trace etc.
You can trigger a 500 error on your frontend by changing a Model.Value property in your template. For example, on a Document Type with a property called test
. The way to render it in the frontend would be Model.Value("test");
To trigger a 500 error page you can add anything after Value such as Model.ValueTest("test");
While upgrading Umbraco in the past it would redirect visitors of the website to the upgrading page.
To prevent this we have added a maintenance page
that will be shown when visiting the website while Umbraco is in Upgrade runtime mode.
It is possible to disable the maintenance page as most upgrades can be done without the website having to restart or go down.
To disable the maintenance page, add the following configuration in the appSettings.json
file:
To customize the Maintenance page, in the Umbraco folder create a new folder called: UmbracoWebsite
.
in this folder create a new file called maintenance.cshtml
.
Once the file has been created you can style it so it looks the way you want it to.
It is not recommended to let Umbraco be in Upgrade mode for longer periods. Most migrations can be executed while the website continues to work. Consider using this feature, if you know what you are doing.
If you set up everything correctly and the error pages are not showing correctly, make sure that you are not using
Custom ContentFinders in your solution,
Any packages that allow you to customize redirects, or
Rewrite rules in web.config that might interfere with custom error handling.
If your code or any packages configures a custom IContentLastChanceFinder
, the settings in appSettings.json
will not be used.
For common approaches to handling errors in ASP.NET Core web apps, see the Handle errors in ASP.NET Core article in the Microsoft Documentation.