[LRUG] Rendering maintenance pages?

Artan Sinani artisinani at gmail.com
Sat Jun 29 01:59:35 PDT 2013


You could trigger the page_cache as part of your deploy process, by simply
using curl (
http://stackoverflow.com/questions/9423511/rails-3-2-pre-render-bake-a-new-page-cache-immediately-after-expiry
).

Or as a rake task: https://gist.github.com/rtsinani/5890442.

Artan


On 28 June 2013 12:12, Tom Ward <tom at popdog.net> wrote:

> 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.
>
> Tom
>
> On 28 June 2013 11:54, Artan Sinani <artisinani at gmail.com> wrote:
>
>> 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.
>>
>> Rails 4 is moving away from page_cache, but I think it works well for
>> production static but development dynamic pages.
>>
>> Artan
>>
>>
>> On 28 June 2013 10:40, Tom Ward <tom at popdog.net> wrote:
>>
>>> Hey folks,
>>>
>>> I'm working with Joel, and we thought we'd let you know what we've come
>>> up with.
>>>
>>> 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).
>>>
>>> Then, to generate a static version we have a rake task with the
>>> following:
>>>
>>>     session = Rack::Test::Session.new
>>> Rack::MockSession.new(Rails.application)
>>>     response = session.get('http//example.com/errors/404')
>>>     if response.status == 200
>>>       File.write Rails.root + 'public' + '404.html', response.body
>>>     else
>>>       raise 'Failed to generate 404 page'
>>>     end
>>>
>>> So far it seems to work well.
>>>
>>> Tom
>>>
>>>
>>>
>>> On 27 June 2013 11:01, Paul Robinson <paul at 32moves.com> wrote:
>>>
>>>> On 27 Jun 2013, at 10:55, Daniel Barlow <dan at telent.net> wrote:
>>>>
>>>> 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.
>>>>
>>>>
>>>>
>>>> Ah, got you.
>>>>
>>>> I think this is what we're after then:
>>>>
>>>>
>>>> http://icelab.com.au/articles/precompiled-rails-static-404-and-500-pages/
>>>>
>>>> It'll need a bit of a tweak to produce a maintenance page, but that
>>>> looks like your starter for 10...
>>>>
>>>> _______________________________________________
>>>> Chat mailing list
>>>> Chat at lists.lrug.org
>>>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>>
>>>>
>>>
>>> _______________________________________________
>>> Chat mailing list
>>> Chat at lists.lrug.org
>>> http://lists.lrug.org/listinfo.cgi/chat-lrug.org
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.lrug.org/pipermail/chat-lrug.org/attachments/20130629/10a8a7c0/attachment-0003.html>


More information about the Chat mailing list