[Radiant] Re: Using Pow presents a problem
I have also seen this. I don't know the exact reasons, but you can 'fix' it with this setting in development.rb: config.cache_classes = true This also means however that you will have to restart the server way more often to see your changes.. On Aug 29, 9:18 pm, Dave hunkyb...@gmail.com wrote: Hi, RVM REE RadiantCMS 1.0 rc2 using Pow.cx to take care of the development site... go to view the homepage... reloader problems... ThreadError: thread 0x1001d6270 tried to join itself ~/.rvm/gems/ree-1.8.7-2011.03/gems/radiant-1.0.0.rc2/vendor/rails/ actionpack/lib/action_controller/reloader.rb:31:in `lock' ~/.rvm/gems/ree-1.8.7-2011.03/gems/radiant-1.0.0.rc2/vendor/rails/ actionpack/lib/action_controller/reloader.rb:31:in `run' ~/.rvm/gems/ree-1.8.7-2011.03/gems/radiant-1.0.0.rc2/vendor/rails/ actionpack/lib/action_controller/dispatcher.rb:108:in `call' ~/Library/Application Support/Pow/Versions/0.3.1/node_modules/nack/lib/ nack/server.rb:146:in `handle' ~/Library/Application Support/Pow/Versions/0.3.1/node_modules/nack/lib/ nack/server.rb:99:in `start' Show 6 more lines Anyone have any tips on how to develop with Pow and not have this issue with actionpack? Thanks
[Radiant] Re: Can Radiant be something for my site
I don't see why not. Easily! On Aug 27, 12:48 pm, roelof rwob...@hotmail.com wrote: Hello, Im looking for a new CMS for my site. Can I make this site (http://www.tamarawobben.nl) in Radiant. Roelof
[Radiant] Re: Just before write parse of pages in extensions.
Somewhat stabbing in the dark here, but I would probably put something like this in the extension's activate method; Page.send(:include, HamlHack::PagePartExtensions) And in lib/haml_hack/page_extensions.rb: module HamlHack::PageExtensions def self.included(base) base.class_eval do alias_method_chain :parse_object, :haml_hack end end def parse_object_with_haml_hack(name) do stuff end end Have a look at page.rb, esp. the 'parse_object' method. On Aug 28, 6:33 pm, Jordon Bedwell envyge...@gmail.com wrote: Is there a class we can tap into with extensions to parse a page just before write? Somebody wanted the HAML plugin fixed because he ran into a gotcha with the system and HAML where HAML complains about page parts and improper nesting so I wanted to get this fixed for him but have no idea what class I should tap into to do that.
[Radiant] Re: Attachments with Database Mailer?
hi Marshal, Actually, I've been planning to merge the attachments support into the master branch and then into the official fork and gem. My fork has gotten a bit nasty over the years though, so I suspect it will take me some time to go through all the code.. I'll get to it eventually, but if you're really waiting for it, you should probably dig in yourself :) regards, B On Jul 29, 1:32 am, Marshal Linfoot mlinf...@gmail.com wrote: Benny, thank you very much for this extension. I've been using forms and forms_mailer, but have been looking for something that provides file attachment functionality. So I was excited to see your reply to Rachel. My first attempt was to install the radiant-mailer-extension gem (trying to do things the new way) and discovered that it didn't work. The r:mailer:file / tag wasn't being recognized. I then went to your github page, selected the with_attachments branch, downloaded into vendor/extensions, and everything appears to be working well. Any plans to gemify your with_attachments branch? By the way, works fine in 1.0.0-rc2! -- marshal
[Radiant] Re: Attachments with Database Mailer?
hi Rachel, My fork of mailer supports attachments: https://github.com/jomz/radiant-mailer-extension I have combined it with database_mailer succesfully, but the behavior is not what you're after.. For some reason, when database_mailer is installed, mail attachments break, but they do get saved to the db.. On Jul 21, 4:04 am, Rachel Soma ms.rachel.s...@gmail.com wrote: Hi all, I'm using Mailer and Database mailer but I need to be able to send an attachment with the email - I've searched high and low but can't find anything that will work. The database doesn't need to store the attachment, it just needs to email it through. Can anyone point me in the right direction? Cheers, Rachel Young rac...@rachelsoma.comwww.rachelsoma.com My profiles: [image: Flickr] http://flickr.com/photos/rachelyoung [image: Twitter] http://twitter.com/rachelsoma Contact me: [image: Google Talk] ms.rachel.soma
[Radiant] Re: Globalize2 bug?
I think I can shed some light on this, sorry to keep you waiting so long. Obviously, no, that's not how it's intended to work. I think what happened, is that the session locale from the backend (when you translated the page) was re-used on the frontend, as there was no locale provided in the URL. The globalize2 extension does not look up your locale by means of browser settings or IP, merely by the request URI. I'm not sure which version you were using, but it's definitely outdated by now; the extension has been a bit buggy since Radiant itself is multilingual, and would very often clash with other extensions.. It has recently been refactored, and is much more robust now. Please try again with https://github.com/jomz/radiant-globalize2-extension (or gem install radiant-globalize2-extension ), and let me know if you still encounter problems. On Mar 4, 7:58 pm, wlai will@gmail.com wrote: I have an radiant installation with Globalize2 setup. The default is set to be en-us, and have a bunch of other european languages enabled. Repro: - The problem I run into is that I'd create a new page, and save it as the default language (en-us). I visit the URL (http://example.com/ test) and see the page as expected - I'd then go back in admin, click on the Spanish flag to create the spanish version of the page, and saves it. - Now when I visit the URL again, I'd see Spanish page, even though my browser settings is all en-us, and I'm browsing from an US ip address. Is that how Globalize work? The last saved page is the one displayed? That would seem to me to defeat the purpose of a default page, no? Any help appreciated. Thanks.
[Radiant] Re: Conditional tags wiki info: typo or user ignorance?
r:if_url matches=^/ doesn't make much sense.. It means any url starting with a /, so ... any url. This will indeed always render. r:unless_url matches=^/about$ means if we are not on the /about page, so this will also render on every page except the about page. I think this is what you're after: r:unless_url matches=^/about$r:snippet name=slider // r:unless_url r:snippet name=main / r:content part=sidebar inherit=true / r:snippet name=foot / regards, Benny On Feb 23, 7:52 pm, rosslaird r...@rosslaird.com wrote: Thanks for the help, Will. I must be misunderstanding this in a fundamental way. Here's what I have in my layout: r:if_url matches=^/ r:snippet name=slider / r:snippet name=main / r:content part=sidebar inherit=true / r:snippet name=foot / /r:if_url r:unless_url matches=^/about$ r:snippet name=main / r:content part=sidebar inherit=true / r:snippet name=foot / /r:unless_url By my reckoning, that should render all the snippets -- including the slider, which has the About Me info -- on every page except the /about page, for which the above code is intended to remove the slider. But what happens in the above scenario is that the snippets are rendered twice on every page (This creates such a messy page that I have not even looked for the slider snippet to see if it is rendered twice. I think I should fix the reproduction first.) What am I missing? On Feb 23, 9:16 am, William Ross w...@spanner.org wrote: On 23 Feb 2011, at 17:01, rosslaird wrote: In the radiant wiki over on github (I am posting this here because the wiki on github seems to have very low readership), the conditional tags page show this example code: head r:if_url matches=^/$ titleRadiant Handbook/title /r:if_url r:unless_url matches=^/$ titler:title/ - Radiant Handbook/title /r:unless_url /head The documentation goes on to say that the code above would set the page title as “Radiant Handbook” on the homepage, but for all subpages it would use the title of the page, then “… – Radiant Handbook”. Now, when I look at the url regexp in the first bit (if_url matches), then I look at the regexp in the second bit (unless_url), these two expressions look *exactly the same* to me. Each one is ^/$. Am I blind, or are they the same? And if they are the same, should they be? And if not, what should they be? The lack of an else clause in radius makes for rather clumsy notation sometimes: this is really just an if/then/else construction to check for rootpageness. In radius that has to be written as if and then unless with the same condition. In this example the path stays the same so that the same condition is applied first positively then negatively. I am trying to show an About Me link (in an id that slides in and out with JS) on my site on every page except the /about page (which already is about me...). It seems that if_url and unless_url are the way to go here, but I can't seem to get it to work. And I'm wondering is the reason for that has to do with the example code I've been adapting. I just changed the unless_url link to r:unless_url matches=^/about/$, but no dice. The About Me link still shows on that page. Your regex should work for /about/, but it does depend on the url that is requested. It's a rails quirk that /about and /about/ are considered the same path, for example. Partial matches are fine so if the site is simple you might have better results with r:unless_url matches=^/about. Depending on the server, you may also want to set ignore_case=true. best, will
