silverstripe-cms icon indicating copy to clipboard operation
silverstripe-cms copied to clipboard

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

Open mylesthedev opened this issue 11 years ago • 14 comments
trafficstars

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.

mylesthedev avatar Nov 20 '14 23:11 mylesthedev

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

stevie-mayhew avatar Nov 20 '14 23:11 stevie-mayhew

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

mylesthedev avatar Nov 21 '14 00:11 mylesthedev

@mediabeastnz completely agree these should be regenerated on build and flush - and probably even more often than that. Related: https://github.com/silverstripe/silverstripe-cms/issues/1139

jonom avatar Nov 30 '14 03:11 jonom

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

dhensby avatar Mar 06 '15 19:03 dhensby

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?

jonom avatar Mar 06 '15 20:03 jonom

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?

chillu avatar Mar 08 '15 10:03 chillu

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.

lerni avatar Mar 08 '15 19:03 lerni

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).

dhensby avatar Mar 09 '15 00:03 dhensby

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?

mylesthedev avatar Mar 09 '15 04:03 mylesthedev

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

chillu avatar Apr 27 '15 02:04 chillu

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?

mylesthedev avatar Apr 30 '15 02:04 mylesthedev

I'd like to see it a separate dev task

Perhaps dev/errorfiles ?

tractorcow avatar Apr 30 '15 02:04 tractorcow

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. https://github.com/silverstripe/silverstripe-framework/issues/4149

jonom avatar May 05 '15 17:05 jonom

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

tractorcow avatar May 11 '17 22:05 tractorcow