Error pages in XP - how to set them up?

Enonic version: XP (6.1.1)

Couldn’t see this implemented in any of your example applications on GitHub, nor in your documentation.

How do you set up custom error pages? I.e. when our users get 403 Forbidden, 404 Not Found or - God forbid - 500 Internal Server error - we’d like to provide them with a custom error page (preferably one for each).

Kristofer Selbekk

Nice timing for your question - solution is part of the 6.2 release (almost ready to go live)…
It works like this:

Create a controller: /site/error/error.js

Inside error.js you may do an exports.handleError, or optionally handle404, handle500 etc if you want to be more specific - it acts like any other controller. An example can be seen here:

Hope this hepls…


1 Like

This looks great - when will 6.2 be released?

Also, will the handleXXX pattern work for every status code >= 400, or just for the predefined ones?

ETA before tuesday… if nothing goes wrong.
You should be able to handle any http status code - naturally, only the onces that are actually produced by the system. Currently this is limited to 404, 401,403 and 500 (I believe)

When creating error pages, we recommend making them as simple as possible - simply to avoid errors on your error page :slight_smile: - i.e. simply serve assets and static info, avoid requesting services etc…

Perfect then!

Yep, will make sure to make error pages quite simple :smile:

How will this work when we have several apps installed? If there is one error.js in each app, will they work only for their own page templates/parts, or will one override the others?

If you have multiple apps installed on a single site, it will scan the apps in sorted order. (Apps can be sorted when added to sites). First one that catches the error wins.

1 Like

Seems to be working well in 6.2.0_RC3.

1 Like

There is now an example in the Superhero master branch. But my automatic 403 redirect to the login page doesn’t seem to work yet. I could probably manage a workaround early next week.

@mla - your specific problem has been fixed - however, redirecting to a login page is not optimal (unless the errorpage is located in a remote app/site), rather just return a login form directly in the error response, this is optimal for http clients of any kind.

How can I test the various http status code error pages?

This for instance gives me the 404, but what if I wanted to test say 505?

I guess the answer should also be documented here:

Hi ComLock,

You can test this from any page controller by modifying the controllers response object, here’s the documentation for what can be sent:

Sending a statuscode that has a corresponding errorHandler should trigger the error handling controller code.

Testing status code this way from a page controller is meant to work, but we can confirm that this is a bug in XP and we will fix it for the next release - 6.5. Thanks for the heads up!