Custom error pages

[friep]

new issue: website crashes if person (e.g. content creator) has no image (which is not a required field in direcuts)

[KonradUdoHannes]

@friep @jstet Custom error pages where introduced in particular we currently have 5 pages for

• general routing errors
• invalid blog posts
• invalid events
• invalid projects
• invalid local chapters

Error messages are provided depending on the current language. Please check out the functionality. I think (and changed issue tags accordingly) having some sort of error page functionality should definitely be priority, whereas fine tuning the design at some point should not. Please have a look at the current functionality and lets then discuss what we should still do pre-launch. Feel free to also comment on other design issues suited for a backlog task.

Also note a couple of site notes regarding the error pages.

• The current pages are the same for the dynamic and the static build
• Processing of errors works differently for dynamic and static build, which limits a bit the processing options if the resulting pages should look the same. This means
  • It would be good if both builds are checked wrt to custom error pages (I triggered both CDs)
  • We might not be able to accommodate every design request technically.
• The error routing for the static pages required the build to disable strict mode. This means that the build will no longer fail if we forget to prerender a route. This means that we potentially have more runtime errors instead of build time errors when it comes to future routing/prerendering bugs.

[KonradUdoHannes]

Actually the static build on cloudflare does not seem to work currently (now that it is finished), so there seems to be a difference between npm run build && npm run preview and the static build an cloudflare.

[KonradUdoHannes]

A second attempt at this implemented service workers in #322. This was expected to be a robust solution for static builds, where the service worker (client side) catches all 404 errors from the webserver and reroutes them to the custom error page. Unfortunately this does not work for cloudflare at the moment as cloudflare does not actually throw 404 errors for non-existing routes.

This complicates this task significantly as not only the approaches so far don't work, but also progress requires researching/reverse engineering how cloudflare renders the static page. Afterwards one could build a solution with the disadvantage that it might be cloudflare specific.

[friep]

is this something cloudflare specific? i don't want to reopen the hosting provider bucket but with #334 limitations...

[KonradUdoHannes]

Well its not the expected behavior for static hosting, but since that is actually such a standard service I'm still wondering whether there is something that can be done one the configuration side. Either we have an issue in our configuration or we can use the configuration to work around the non-standard behavior. So far I still have a few ideas/things to try.

[KonradUdoHannes]

With the vercel migration the error pages now work in production and currently render a very simple general purpose "not found" page in both English and German.

@friep @jstet are there any immediate wishes for design improvements, otherwise I would close this issue.

[friep]

closing is fine by me :)