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 = '<a href="#" onclick="window.close();"><img src="' + item.public_filename(:full) + '" alt="" /></a>' 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 :)
on 2008-08-04 18:29
on 2008-08-05 00:29
I'm doing some similar and would love to know how to achieve this!
on 2008-08-05 00:53
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
on 2008-08-05 03:27
Hi Sean Sean Cribbs 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. > 2. 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.
on 2008-08-05 12:06
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.
on 2008-08-05 17:25
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: 3. 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 or Sony campaign!) Cheers, Mohit. 8/5/2008 | 11:14 PM.  http://www.microsoft.com/presspass/press/2005/Apr0...  No link, but it was a campaign that Sony ran with a music TV channel!
on 2008-08-05 18:34
> 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. > > 2. 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
on 2008-08-05 18:39
Sean Cribbs 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.
on 2009-06-11 22:24
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> <p> <r:number /> <strong><r:title /></strong> <br /> <r:phone_number /> <br /> <a href="<r:url />">Website</a> </p> </r:store> 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!
on 2009-06-12 01:46
> 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-extensio... 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
on 2009-06-12 21:17
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-extensio... and for details on installation and configuration check out the official page <http://blog.aissac.ro/radiant/paginate-extension/>. Many thanks to: Benny Degezelle, Jim Gay, Andrew Neil and Michael Kessler (hope I didn't forgot anyone)
on 2009-06-13 02:20
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
on 2009-06-13 08:12
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?
on 2009-06-13 08:27
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/"> <!-- Internet Explorer needs some ugly hacks to render PNG images with transparency --> <div id="logo" style="filter:progid:DXImageTransform.Microsoft.AlphaImageLoader(src= \'/images/logo.png\',sizingMethod=\'scale\');"></div> <r:else> <!-- the rest of browsers just make it rigth --> <img src="/images/logo.png" id="logo" alt="Logo"/> </r:else> </r:if>
on 2009-06-13 12:06
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 Southard <firstname.lastname@example.org>