Global user help page

I’m trying to make the 500 error page work better. Its hard to put different country emails on there. What about to have a page on openfoodnetwork.org that lists all the groups and their contact details for help? e.g.

http://openfoodnetwork.org/help

cc @serenity @danielle @RohanM @lin_d_hop

Why not @pmackay, fine with me if easier and people find easily their local support!

Sounds like a good idea to have contact details, though the site was set up to have local site pages where this information could live.

There’s a ‘Local OFN’ section on the site (), and the launched sites have their own page (AU: ). Would it be possible to direct them to the relevant local information on the 500 error page? If the error page can’t be localised (@RohanM, do you think it could be?) then perhaps linking to each local sites page on openfoodnetwork.org?

The idea I’m suggesting is there is just one link from the 500 error page, to avoid having to customize it per site. If Rohan has some nifty ideas of how to customize, I can set that up instead.

The Xero error page is really good. The only bit that needs customising is the email address. We can take ContentConfig.footer_email from the database. Maybe rename the field first.

I’m very happy that you take this forward. The grumpy cat is really not friendly at all. And it doesn’t give people any hint what is wrong.

I also think that the 404 page should look more different to the 500 page. It happened to me a couple of times that I saw a 404 and thought it was a 500 or the other way round.

@maikel do you know how ContentConfig.footer_email can be obtained when displaying a 500 page? My understanding is the full app state isnt available.

I don’t know. What about redirecting to a pretty 500 page? Like Spree redirects to /unauthorized.

If there is an error such that the 500 page is shown, we can make it look better (what I’ve been doing) but I dont know how to insert database content.

You could have a static page that contains some useful links, for example to a contact page or to a report-error page. The URL to that page is local, e.g. /contact, and that page is rendered normally and can contain database content.

Or you could generate a static file containing the email address whenever the email address is changed. That has the advantage that it works even if the database connection is broken.

The error page itself probably has be static. Otherwise things could go wrong while rendering again.