<div dir="ltr">You could trigger the page_cache as part of your deploy process, by simply using curl (<a href="http://stackoverflow.com/questions/9423511/rails-3-2-pre-render-bake-a-new-page-cache-immediately-after-expiry" target="_blank">http://stackoverflow.com/questions/9423511/rails-3-2-pre-render-bake-a-new-page-cache-immediately-after-expiry</a>).<div>
<br></div><div style>Or as a rake task: <a href="https://gist.github.com/rtsinani/5890442">https://gist.github.com/rtsinani/5890442</a>.</div><div style><br></div><div style>Artan</div></div><div class="gmail_extra"><br><br>
<div class="gmail_quote">On 28 June 2013 12:12, Tom Ward <span dir="ltr"><<a href="mailto:tom@popdog.net" target="_blank">tom@popdog.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra">We originally considered using the page cache, but decided against it. One of our requirements is that the static pages are updated on every deploy, so that they always include any changes to the layout or stylesheets. We also want a deploy to fail if the static pages can't be generated. To use the page cache we'd need to restart our server, wait for it to reload, trigger requests for each error page and then if they fail for some reason, back out the whole deployment again. It seemed more complicated process than running a simple rake task.</div>
<div class="gmail_extra"><br></div><div class="gmail_extra">Tom</div><div class="gmail_extra"><br></div><div class="gmail_extra"><div class="gmail_quote">On 28 June 2013 11:54, Artan Sinani <span dir="ltr"><<a href="mailto:artisinani@gmail.com" target="_blank">artisinani@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">You could also use the page_cache, which it'll render the HTML in the public folder. You still have the ErrorsController with only one action 'show', which will render the view with the same file name as the id. Eg. error/404 will render views/errors/404.html.erb. You can then trigger the page_cache as part of your deploy.<div>
<br></div><div>Rails 4 is moving away from page_cache, but I think it works well for production static but development dynamic pages.<span><font color="#888888"><br><div><br></div><div>Artan</div></font></span></div>
</div><div><div><div class="gmail_extra"><br><br><div class="gmail_quote">
On 28 June 2013 10:40, Tom Ward <span dir="ltr"><<a href="mailto:tom@popdog.net" target="_blank">tom@popdog.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr">Hey folks,<div><br></div><div>I'm working with Joel, and we thought we'd let you know what we've come up with. </div><div><br></div><div>We've created an ErrorsController with actions for all of our error pages. Requesting /errors/404, for example will render our 404 page using the standard asset pipeline, layouts, etc (all of which we make use of).</div>
<div><br></div><div>Then, to generate a static version we have a rake task with the following:</div><div><br></div><div> session = Rack::Test::Session.new Rack::MockSession.new(Rails.application)<br></div><div><div> response = session.get('http//<a href="http://example.com/errors/404" target="_blank">example.com/errors/404</a>')</div>
</div><div> if response.status == 200</div><div> File.write Rails.root + 'public' + '404.html', response.body</div><div> else</div><div> raise 'Failed to generate 404 page'</div><div>
end</div><div><br></div><div>So far it seems to work well.</div><div><br></div><div>Tom</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 27 June 2013 11:01, Paul Robinson <span dir="ltr"><<a href="mailto:paul@32moves.com" target="_blank">paul@32moves.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><div><div><div>On 27 Jun 2013, at 10:55, Daniel Barlow <<a href="mailto:dan@telent.net" target="_blank">dan@telent.net</a>> wrote:</div>
<br><blockquote type="cite"><div class="gmail_quote"><div>I think you're actually agreeing with each other here: Joel is talking about a rake task and a static page, which presumably would be written to this "separate area of disk" to be served directly by nginx/your upstream proxy next time the app is brought down, but he wants it to be produced using the same layout, styles and general look & feel as the app itself and to stay in sync when the app changes. It seems like this is the kind of thing the asset precompiler should be able to do, but I've no idea how.<br>
</div></div></blockquote></div><br><div><br></div></div><div>Ah, got you.</div><div><br></div><div>I think this is what we're after then:</div><div><br></div><div><a href="http://icelab.com.au/articles/precompiled-rails-static-404-and-500-pages/" target="_blank">http://icelab.com.au/articles/precompiled-rails-static-404-and-500-pages/</a></div>
<div><br></div><div>It'll need a bit of a tweak to produce a maintenance page, but that looks like your starter for 10...</div></div><br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>
<br>_______________________________________________<br>
Chat mailing list<br>
<a href="mailto:Chat@lists.lrug.org" target="_blank">Chat@lists.lrug.org</a><br>
<a href="http://lists.lrug.org/listinfo.cgi/chat-lrug.org" target="_blank">http://lists.lrug.org/listinfo.cgi/chat-lrug.org</a><br>
<br></blockquote></div><br></div>
</div></div></blockquote></div><br></div></div>
</blockquote></div><br></div>