Possible to disable cache for a single page?

Ruby Apps Radiant CMS
1

Hi,

I have a list of thumbnails and when clicked they open a larger image in
a popup window.

I have a page in radiant with a <r:press_image /> tag for the popup and
supply an img-parameter to the page that I use in the tag that looks
like this:

tag ‘press_image’ do |tag|
html = “”
img = tag.globals.page.request.parameters[:img].nil? ? nil :
tag.globals.page.request.parameters[:img].to_i
item = PressAttachment.find(img) if img
html = ‘’ if item
html
end

Works fine on my machine where cache is disabled but on the live server
the popup is cached and it always displays the first image viewed
because of the cache.

My question is if I can disable the cache for a single page or if anyone
has a suggestion to how I could achive this otherwise.

Thanks in advance, love working with radiant and my clients too :slight_smile:

2

I’m doing some similar and would love to know how to achieve this!

3

The typical solution is to make a page subclass that adds this method:

def cache?
false
end

Then make the page that you want uncached to be of that type. Before
you do that, however, take into consideration why you need the page
uncached. It may be that the need for it to be uncached is secondary
to a greater functional need from the system, and that that should be
addressed first.

Sean

4

Hi Sean

Sean C. wrote:

The typical solution is to make a page subclass that adds this method:

def cache?
false
end

I’m just thinking of putting this down as the starting point for one of
the pages in the ‘Summer Reboot’ but I have a couple of questions to
understand this slightly better:

  1. Where would that code go? How does one go about creating a page
    subclass - from there on, it’s easy.

Then make the page that you want uncached to be of that type. Before
you do that, however, take into consideration why you need the page
uncached. It may be that the need for it to be uncached is secondary
to a greater functional need from the system, and that that should be
addressed first.

  1. What would be an example of a greater functional need from the
    system?

I’m guessing comments fields and some other dynamic pages would need
this functionality. What should someone be careful of in disabling the
cache for a page?

Thanks
Mohit.

5

Hi Sean,

thank you for your answer, works perfectly. I made a no_cache_page.rb in
my models folder for my extension and put this in it:

class NoCachePage < Page
def cache?
false
end
end

To activate it I just put NoCachePage in the activate method of my
extension.

Btw. a possible subject for the Summer Reboot could be explaining the
different ways you include your extension files in the activate method,
right now I have a mix that I have found in different extensions looking
like this:

NoCachePage
Page.send :include, CollectionTags
Page.send :include, PressTags

The NoCachePage thing I found in the MailerExtension while the Page.send
examples are from the PageAttachments extension, but now I see that the
MailerExtension’s tags are included without using Page.send. Is there
anything already written on this subject?

Thanks again for making the most enjoyable cms around and the nice
support here.

6

Gert Jørgensen wrote:

examples are from the PageAttachments extension, but now I see that the
MailerExtension’s tags are included without using Page.send. Is there
anything already written on this subject?

Hi Gert

There are currently seven articles listed (planned? hoped for?) under
the Summer Reboot:

  1. Writing your Own Extension
    • Creating an extension I – Adding tags (and some useful tags) [AW]
    • Creating an extension II – Adding a tab in Admin UI (and what is
      shards?)
    • Creating an extension III – Modifying the Page UI from an
      extension
    • Creating an extension IV – Extending and overriding Radiant
      behavior [CF]
    • Creating an extension V – Creating a special page type
    • Creating an extension VI – Skinning controllers with front-end
      layouts (share_layouts) [SC]
    • Global Tags

I think a part of what you wrote here belong in Part V. As for what
happens upon activation and how tags could be included, we need
something. Perhaps, something like ‘Inside an Extension’ that explains
some of the concepts involved in an extension?

By the way, please feel free to add any information to the Summer Reboot

  • don’t worry about it being complete/ completely correct. It will get
    fixed eventually! Also, since it’s a wiki, some information is better
    than no information - the first run is for developers… and the ‘Summer
    Reboot’ equivalent of “Citation Needed” is most acceptable. Just start
    something (oops, I sound like a Microsoft[1] or Sony[2] campaign!)

Cheers,
Mohit.
8/5/2008 | 11:14 PM.

[1]
http://www.microsoft.com/presspass/press/2005/Apr05/04-18StartSomethingPR.mspx
[2] No link, but it was a campaign that Sony ran with a music TV
channel!

7

I’m just thinking of putting this down as the starting point for one of the
pages in the ‘Summer Reboot’ but I have a couple of questions to understand
this slightly better:

  1. Where would that code go? How does one go about creating a page subclass
  • from there on, it’s easy.

That would go in app/models of an extension, preferably.

  1. What would be an example of a greater functional need from the system?

I’m guessing comments fields and some other dynamic pages would need this
functionality. What should someone be careful of in disabling the cache for
a page?

Right. The only caveat of disabling the cache is the potential for
lower performance. However, my point in bringing that up is that one
should focus on the why you need an uncached page in the first
place, and address that need first. For example, with comments (see
the radiant-comments project on github from ntalbott and
artofmission), it may not be necessary to make the page uncached
because you can clear the cache after a comment is posted.

Sean

8

Sean C. wrote:

Right. The only caveat of disabling the cache is the potential for
lower performance. However, my point in bringing that up is that one
should focus on the why you need an uncached page in the first
place, and address that need first. For example, with comments (see
the radiant-comments project on github from ntalbott and
artofmission), it may not be necessary to make the page uncached
because you can clear the cache after a comment is posted.

Sean

Thanks for the explanations. I shall try to put these into the
documentation this weekend. I think the example from the
radiant-comments extension will be very useful. I shall look it up!

Cheers,
Mohit.
8/6/2008 | 12:37 AM.

9

This is an old thread that I have been meaning to follow up. Sean
suggested:

that one
should focus on the why you need an uncached page in the first
place, and address that need first

I wanted to provide an example of why I needed to have a page not
cached and see if there was a better way to implement this. Feel free
to chime in!

This is why I needed the page not to be cached:

I created a store directory extension which had structured data such
as store name, floor, location etc. Nothing special to this, basically
the same as the “link roll” example extension.

I created some custom tags to displays the store index. Again nothing
special here. However, the store index linked to a store’s detail
page.

I created a route:

map.with_options(:controller => 'site') do |site|
  site.connect 'store-directory/:name', :action => 'show_page',

:url => ‘/store-directory/store’
end

This captures URL’s like these:

/store-directory/mcdonoughs-your-independent-grocery
/store-directory/carlton-cards

This routed to a single store page which acted as my template. The
name (or slug) was used to look up the store in the database. I used
some tags in my store details pages which looked something like this:

<r:store>



Website

The store tag found the store by name/slug.

Because I was using a single page to display the store details which
would change based on the name passed in the URL, the first store that
was shown would be cached and when visiting other store details, it
would display the cached store, rather than the proper details.

Making the store template page not cached, resolved this issue.

Did I go about this the right way, or is there a better method so I
can have all the store details cached as well? Any thoughts would be
much appreciated! Thanks!

10

This extension has been around for a while, but as we didn’t need it in
our projects the last months was left behind. Thanks to some great
contributors it lived on, and now, as we had a little time on our hands
we updated and tested it. It works fine both on Radiant 0.7.1 and
Radiant 0.8 (RC1) You can check out the source code on github
http://github.com/Aissac/radiant-paginate-extension/tree/master and
for details on installation and configuration check out the official
page http://blog.aissac.ro/radiant/paginate-extension/.

Many thanks to: Benny D., Jim G., Andrew N. and Michael
Kessler (hope I didn’t forgot anyone)

11

This is an old thread that I have been meaning to follow up. Sean
suggested:

that one
should focus on the why you need an uncached page in the first
place, and address that need first

Indeed!

/store-directory/carlton-cards
A better solution would be to create a new model called StorePage,
inheriting from Radiant’s Page model. You can override the find_by_url
method, so that the StorePage would behave as an ‘index’ page, or a
‘show’ page. For example:

/store-directory
Would be an index page, listing all your stores

/store-directory/mcdonoughs-your-independent-grocery
/store-directory/carlton-cards
These would be ‘show’ pages, for individual stores.

You would only need to create a single StorePage in your Radiant
sitemap. In the above example, this would have the slug ‘store-
directory’. Each of the sub-pages, corresponding to individual Store
models, would exist as ‘virtual pages’. You won’t see them in the
sitemap of the Radiant admin, but they exist on the public facing site.

If you use this approach, you don’t need to create any custom routes.
The index/show pages would both be rendered using the
SiteController#show_page action. This should mean that caching works
just as you would expect. So the /store-directory page and /store-
directory/carlton-cards pages would be cached without interfering with
each other.

Here is an example of a model that overrides the page model:

http://github.com/nelstrom/radiant-movies-extension/blob/97b149f84f75e887dd37261acdee3ebd6570b26c/app/models/movie_page.rb#L5-17

Note the tags: movies:if_index/ and movies:unless_index/. The
content for the index page should go inside the if_index tag, and the
content for the ‘show’ pages should go inside the unless_index block.

I hope this helps clear things up.

Cheers,
Drew

12

Not sure if this a problem with browsers in general or Back Door but
the following code only works maybe 80% of the time. It always give
an answer and never gives both. It will sometimes say, “is IE” on
other browsers and sometime say “not IE” on an ie browser. Using if
and else has the same results. Any suggestions?

<r:if cond=“request.env[‘HTTP_USER_AGENT’] =~ /MSIE/”>
is IE
</r:if>

<r:unless cond=“request.env[‘HTTP_USER_AGENT’] =~ /MSIE/”>
not IE
</r:unless>

Steven

13

I was noticing further that when a page was reading as IE it would be
IE no mater what browser I tried and if it wasn’t reading like IE then
the same was true. Could this have to do with Radiant’s cache system?

14

Sure seem to be, which makes me wonder how this example shown at
http://backdoor.rubyforge.org/
could ever be reliable.
<r:if cond=“request.env[ ‘HTTP_USER_AGENT’] =~ /MSIE/”>


<r:else>

Logo
</r:else>
</r:if>

15

It would appear that caching is not a good idea with that extension. I
think you would be better served using Microsoft’s conditional comments.

Jim

On Jun 13, 2009, at 2:26, Steven S. [email protected]