Html templates, 400 and 500 not recreated on flush or build

[mediabeastnz]

It seems like the html files for error-400 and error-500 are not recreated on dev build or flush.

If you delete them they are recreated which is good but should they not get recreated on flush or build?

This means when you first launch a site those templates will have no database info e.g. site name will be default site name etc.

[stevie-mayhew]

You need to publish the pages to recreate them, its not part of the flush or build step.

[mediabeastnz]

@stevie-mayhew so if you make changes to your template you need to publish these pages every time?
Seems odd?

[jonom]

@mediabeastnz completely agree these should be regenerated on build and flush - and probably even more often than that. Related: #1139

[dhensby]

The error files are created on dev/build so why not regenerated? I agree that they should be.

[jonom]

Hey @dhensby I had some discussion with @chillu about this at #1139 and then moved it to UserVoice but I don't think that has turned out to be a good place to generate discussion. Would love to see some activity on this though - maybe time for a discussion on the dev list?

[chillu]

Template renders can get expensive depending on the project implementation. Adding two page renders to every dev/build is a bit of an overhead that I'd rather avoid (~1-3s?).

As mentioned before in #1139: I would prefer to serve the 404 dynamically by default, and have a stripped down static HTML version of the 500 which would be the same for every install (not generated from Page.ss). Generating the 500 page from Page.ss (and the required complexity of keeping it up to date) could move into a module. What do you guys think?

[lerni]

I think it's a question of concerns. Publishing isn't the preferred job of developers and content-authors do usually not care much about error pages. I had just one project, where CMS driven error-pages were a requirement. I would vote to have this in a module and also would love to see it magically republished.

[dhensby]

I agree that dev/build is not the place to be publishing static error pages.

Having said that, dev/build currently does do that, it just only does it if they aren't there. If dev/build currently has that responsibility, then it is natural that it takes on doing it every time.

However, as this is an issue we should discuss the ideal way to manage error pages and that is to have them dynamic (which is much more fun and relevant for a user).

[mediabeastnz]

Getting them out of the site-tree would be great as it can be a little confusing for a content author.
Settings would make the most sense as it only needs to be configured once.

I'm not sure what options you could have under settings though?

[chillu]

Discussion on mailinglist: https://groups.google.com/forum/#!topic/silverstripe-dev/VFXrusjAnKE

[mediabeastnz]

Sounds like everyone wants it to be a module rather than core which is cool.
Will this issue be updated once a RFC has been completed?

[tractorcow]

I'd like to see it a separate dev task

Perhaps dev/errorfiles ?

[jonom]

Sorry guys I missed the second half of this conversation, thought I was following it. Anyway I created an RFC and think it is in line with the thinking here. I posted it on Framework as I figured the changes would affect that module as well as CMS, plus I figured it would be good to keep the RFCs in one place. silverstripe/silverstripe-framework#4149

[tractorcow]

I guess this is a bug, if user experience isn't what's expected.