Re: [Radiant] Dropbox or other file store?
On 17 Jan 2013, at 18:30, Jim Gay wrote: > I'd love to have that. I think we'd need to create an adapter for the > paperclip gem which handles the uploads. > Currently you can do S3, file system, and I think rackspace cloud > files (not sure about that though) There's a paperclip-dropbox gem that looks quite mature. In theory you could just install that and configure paperclip to use it. The configuration mechanism John wrote for clipped is quite fog-specific, but if you're not using fog then those extra settings won't have any effect. It might just work. These days I think a better way to configure paperclipped is by setting config.paperclip_defaults in an environment file and overriding them only minimally in the model. It keeps the configuration out of your code and makes it easy to use different storage for development and production. The best option might be to drop the whole configuration mechanism and require people to configure in the radiant app. best, Will
Re: [Radiant] Multi-user
Sorry. That was meant to go off-list. D'oh. will On 19 Mar 2012, at 12:53, William Ross wrote: > On 19 Mar 2012, at 12:10, PaulinLondon wrote: > >> We are interested in using Radiant as a true multi-user-and-multi-site >> platform. Is there anyone interested in taking on this project for us? > > > Possibly. It would depend on your timetable - we're quite busy at the moment > - and the nature of the project. > > Could you tell me a little more? > > best, > > Will > > > > __ > > William Ross > Director, Spanner Ltd > w...@spanner.org > wrross on Skype, wrr...@me.com on iChat > Office: +44 1229 588098 > Mobile: +44 7771 562745 > > > > __ William Ross Director, Spanner Ltd w...@spanner.org wrross on Skype, wrr...@me.com on iChat Office: +44 1229 588098 Mobile: +44 7771 562745
Re: [Radiant] Multi-user
On 19 Mar 2012, at 12:10, PaulinLondon wrote: > We are interested in using Radiant as a true multi-user-and-multi-site > platform. Is there anyone interested in taking on this project for us? Possibly. It would depend on your timetable - we're quite busy at the moment - and the nature of the project. Could you tell me a little more? best, Will ______ William Ross Director, Spanner Ltd w...@spanner.org wrross on Skype, wrr...@me.com on iChat Office: +44 1229 588098 Mobile: +44 7771 562745
Re: [Radiant] Custom data - which way to choose?
On 15 Feb 2012, at 16:17, Christian Aust wrote: > Hi all, > > my radiant-1.0 site needs some sort of calendar. A couple of entries > (about 80) per year will contain a description (no tags needed but > filters are welcome) along with a date/time attribute and a boolean > flag or two. It'd be nice to generate an .ics file for downloading the > future events. > > What is the current way to do this with radiant, as it is in 1.0? I > doubt using pages and page fields, because I think there's no UI to > deal with dozens or hundreds of sub-entries of a page. > > I could create some model along with tags and controllers/views and > separate it from pages, right? But wouldn't mean that to re-implement > a lot of stuff that's already being done for pages? Treating calendar information as page data is always horrible. Have a look at the event_calendar extension: https://github.com/radiant/radiant-event-calendar-extension With event_map and taggable_events it gives you this: http://350.royalsociety.org/calendar/2010/june or more prosaically, this: http://bcrunners.org.uk/calendar and it comes with a tolerable UI. best, Will
Re: [Radiant] Tiny-Paper Extension and IE9
On 17 Jan 2012, at 15:28, Jordon Bedwell wrote: > 2012/1/17 Bjørn Michelsen : >> Hello all, >> >> I am using the latest version of the Tiny-Paper Extension with Radiant >> 0.9.1. The problem is that the extension does not seem to work with >> Internet Explorer 9. That is, clicking the buttons in the toolbars have >> no effect. It does, however, work in Chrome, Firefox, Opera and Safari. >> >> Any suggestions? > > This is a pretty broad question and pretty broad description. We > cannot diagnose an error with 'it works in everything but IE9' being > implied, because we have no idea what error you are getting. Please > provide an error so that we can try to help you if we can. Question seems ok to me. Buttons don't do anything in IE9, no error messages. The problem is very likely to be with the included version of the TinyMCE toolbar. It will be ancient, and TinyMCE is full of browser-specific hacks. It is now supposed to be compatible with Explorer 9, so you might just be able to upgrade it: http://www.tinymce.com/download/download.php You would need to replace the /javascripts/tiny_mce/ folder. Let us know how you get on. best, will
Re: [Radiant] Upgrading from 0.9.1 to 1.0.0-rc4
On 13 Jan 2012, at 00:29, Marshal Linfoot wrote: > I'm having trouble with an upgrade to rc4 and wondering if anyone else has > run into similar problems. > > Starting with a cloned copy of 0.9.1 instance, I've followed the guide from > Jim Gay, https://gist.github.com/1540782, and can successfully start up an > rc4 version of the site. But none of the former paperclipped assets are > accessible The missing assets are probably just a configuration issue. Have you run rake db:migrate? I guess you must have for it to run at all. If so, please could you tell me what you have for these config settings: assets.additional_thumbnails(this is the old setting used by paper clipped) assets.thumbnails.image assets.thumbnails.video assets.thumbnails.pdf paperclip.storage paperclip.path paperclip.url thanks, Will
Re: [Radiant] JavaScript usage from admin interface
On 2 Dec 2011, at 21:15, Ross Laird wrote:
> I'm rebuilding one of my Radiant sites using the latest version, and
> I've decided to incorporate my JavaScripts into the Design -->
> Javascripts area rather than load them from a subdirectory. However, I
> haven't been able to find any documentation about how to do this
> properly (and, being seemingly one of the few Radiant users who is not
> a programmer, I need documentation). Do I just place each of the
> scripts into new JavaScripts pages? And, if I do that, how do I refer
> to the scripts on the pages? For example, here is some sample code
> that I currently place in the header snippet:
>
>
> http://downloads.mailchimp.com/js/
> jquery.form-n-validate.js">
>
>
>
>Hyphenator.config({
>displaytogglebox : false,
>orphancontrol: 2
>});
>Hyphenator.run();
>
>
> How do I use scripts like these (and the links to which they point),
> in the same way as they are currently being used in the header
> snippet, in the Design --> Javascripts area of the admin interface?
It's probably much simpler than it looks.
Scripts that come from elsewhere should be left alone so that the service
provider (e.g. mailchimp) can continue to do what they do.
Scripts that you've downloaded from somewhere (eg. the jquery tweet plugin) can
be considered static and left in the filesystem.
Radiant's javascript-editing mechanism is the right place for scripts that you
create or intend to edit. In your example, that may only be the final inline
script in which you invoke the hyphenator.
In that case you'll end up with something like this in your layout:
http://downloads.mailchimp.com/js/jquery.form-n-validate.js";
type="text/javascript">
And a single javascript page called 'site.js' in which you can put this:
Hyphenator.config({
displaytogglebox : false,
orphancontrol: 2
});
Hyphenator.run();
The script tags and CDATA wrappers and so on are done for you.
If you also want to bring the signup.js script into an editable place, the
procedure is the same: create a javascript page called signup.js, paste in the
javascript code from that file and then change the tag in your layout to this:
Note that the javascript machinery will create a path within radiant that
matches /js/. It's probably a good idea to move all your static javascript
files to /javascripts/ to avoid collisions.
best,
Will
>
> This seems like such a simple question (probably the answer is just to
> copy and paste the code), but there may be factors to consider, such
> as how (and from where) Javascript links are loaded.
>
> Is this as simple as it sounds?
>
> Thanks in advance.
>
> Ross
Re: [Radiant] Re: Radiant 1.0.0rc3 rake production db:bootstrap
On 18 Oct 2011, at 21:48, Jim Gay wrote: > On Tue, Oct 18, 2011 at 4:43 PM, Nicholas Henry > wrote: > That works, thank you. Not sure if this is a common occurrence or not. I > can't imagine it was an issue with my environment, I created a brand new rvm > gemset and installed the Radiant gem. Might be a bit of a turnoff for new > comers to Radiant. > > I'd love to kill that, but I believe it's an artifact of using Bundler. The need to use bundle exec rake? Yes, it does lead to some ugly command lines. Perhaps we could work round that with new options to the radiant binary? radiant bootstrap, radiant update... will
Re: [Radiant] Radiant 1.0.0rc3 assets image upload error
On 7 Oct 2011, at 13:07, jsman wrote: > Hello fellow Radiant users, > > When uploading an image to the asset bucket in Radiant 1.0.0 RC3 I get > the following error: > > NoMethodError (undefined method `original_width=' for # 0x7f1a49fb9b58>): Hi Jeffrey, Is this an upgrade? You probably just need to migrate the 'clipped' extension. rake db:migrate:extensions or for greater precision: rake radiant:extensions:clipped:migrate best, Will
Re: [Radiant] Passenger 3 Rack problem
On 30 Sep 2011, at 06:43, Paul Noden wrote: > Hi All, > > I am trying to move to using nginx on a Dreamhost VPS and encountered > a little hiccup in the plan - their nginx Passenger version is 3.0.0-5 > whereas their apache Passenger version is 2.2.9-2. > > Am getting the standard PhusionPassenger::UnknownError no such file to > load -- rack/cache (MissingSourceFile) > > Passenger 3 had some changes in regards to vendored gems, however it > is throwing the exception within /vendor/radiant/vendor/rails/ > activesupport/lib/active_support/dependencies.rb so clearly there is > some support. Has anyone got any experience or advice on how to > resolve this, my searches of the web and mailing list archives haven't > revealed solid next step, and in the meantime I'm back on apache… I haven't noticed any issues with nginx and Passenger 3 either locally or in production. Has anything else changed? will
Re: [Radiant] Re: Radiant Edge Install issues
On 15 Sep 2011, at 15:21, Dave wrote: > Hi Will, > > Anything come of this? Any suggestions? Yes. I've had a busy morning, but I'm very glad you made me think it through: first because it turned out to be quite a serious problem and then because I realised that it could all be much, much simpler. I've pushed some updates this morning: if you update your local repository and build the gem, you should find that it all just works. (I know, I said that last time. but it should). I think RC3 will be out when the others have had a chance to review. best, will
Re: [Radiant] Re: Radiant RC2 - Assets - Uploading a Video Error
On 14 Sep 2011, at 19:11, James Martens wrote: > Yes, you do need ffmpeg installed - RC2 will simply not boot without > it, in my (admittedly limited) experience with RC2, so this > requirement has been met already in my dev and production servers. > > The issue I can see is that radiant was looking for a ruby file in the > local project directory when it should have been looking in the gem > directory (which is where I found it). The fact that this occurred on > 3 systems (2 OSX/Lion, one Ubuntu 10.4) suggests to me that something > is quirky in the install process, but it's entirely possible that I > screwed up 3 separate times too :) > > As you say though, this is an older build and is about to be replaced > - a very valid point. > > Any ideas if upgrading to RC3 will cause significant issues from RC2? > I don't really have the luxury of time to debug tons of issues (as I > have already ported this app from 0.9 and used up a lot of my budget > in that exercise). > If it is a clean upgrade path and has significant performance benefits > over RC2 it will be worth it, otherwise it will be a difficult > decision to make, even if I do enjoy running the latest and greatest > (and as annoying as bugs are, solving problems is fun too!) RC3 is architecturally much more up to date than RC2, makes proper use of Bundler and prefers to handle everything as gem dependencies. There is nothing vendored and while we've taken a lot of care to be backward compatible with older installations, the new model is much cleaner and easier to manage. There is some unavoidable manual work in changing config.gem lines in environment.rb to gem lines in the Gemfile but otherwise you should find that it is a drop-in replacement for RC2, and a lot of what was new in that release is now quite mature, especially the asset manager. It does depend how much customising you've done, though. There are migrations and updates that might be complicated by local changes. I would say it was definitely worth giving it a go, and that it will probably just work. But I always think that. Please let me know when it doesn't. best, will
Re: [Radiant] Re: Radiant Edge Install issues
On 14 Sep 2011, at 18:37, Dave wrote: > Hi, > > It is not just chunky-png... that gem is listed in the rc3 gems > lockfile to be nothing but version 1.2.1 but the gemspec installs > 1.2.4. Now, if that was the only gem with a problem it would be > nothing.. to fix.. but it is a lot of gems... too many to deal with by > hand. Another one... cucumber is at 1.0.6 on install, but the radiant > gem is hardcoded to want 1.0.3 It does look like there's an out of date Gemfile.lock checked in. I'm just creating an empty space to try it out. (there's one in the radiant gem and one in the instance, you see. long story). (and I meant gem list, not gem show. Sorry. doesn't matter now, though) will > > > > Hence my comment about all the gems... the gem dependency radiant > command shows... > > Gem radiant-1.0.0.rc3 > ZenTest (= 4.6.0) > acts_as_tree (~> 0.1.1) > bundler (~> 1.0.0) > compass (~> 0.11.1) > cucumber-rails (~> 0.3.2) > database_cleaner (~> 0.6.5) > delocalize (~> 0.2.3) > haml (~> 3.1.1) > highline (~> 1.6.2) > rack (~> 1.1.1) > rack-cache (~> 1.0.2) > radiant-archive-extension (~> 1.0.0) > radiant-clipped-extension (~> 1.0.6) > radiant-debug-extension (~> 1.0.0) > radiant-exporter-extension (~> 1.0.0) > radiant-markdown_filter-extension (~> 1.0.0) > radiant-sheets-extension (~> 1.0.0.pre) > radiant-site_templates-extension (~> 1.0.0) > radiant-smarty_pants_filter-extension (~> 1.0.0) > radiant-textile_filter-extension (~> 1.0.0) > radius (~> 0.7.1) > rails (~> 2.3.12) > rake (~> 0.8.7) > rdoc (~> 3.9.2) > rspec (~> 1.3.1) > rspec-rails (~> 1.3.3) > sqlite3 (~> 1.3.4) > webrat (~> 0.7.3) > will_paginate (~> 2.3.11) > > Gem radiant-archive-extension-1.0.0 > > Gem radiant-clipped-extension-1.0.10 > acts_as_list (~> 0.1.2) > paperclip (~> 2.3.16) > uuidtools (~> 2.1.2) > > Gem radiant-debug-extension-1.0.0 > > Gem radiant-exporter-extension-1.0.0 > > Gem radiant-markdown_filter-extension-1.0.0 > bluecloth (~> 2.1.0) > > Gem radiant-sheets-extension-1.0.0.pre > coffee-script (~> 2.2.0) > sass (~> 3.1.2) > > Gem radiant-site_templates-extension-1.0.0 > > Gem radiant-smarty_pants_filter-extension-1.0.0 > rubypants (~> 0.2.0) > > Gem radiant-textile_filter-extension-1.0.2 > RedCloth (~> 4.2.0) > > > But that is missing dependencies for a lot of the needed gems... Any > clues on how to simply fix this? It looks like the Gemfile.lock > provided is the culprit. I am not sure why that is. > > Thanks! > > > > > > > On Sep 14, 1:27 pm, William Ross wrote: >> On 14 Sep 2011, at 18:17, Dave wrote: >> >>> Seems the gemspec builds a gem that cannot actually install anything, >>> as it depends on gems it did not install in the first place. Other >>> then hand editing the radiant gems lockfile is there an easier way to >>> use the rc3 gem??? >> >> You shouldn't need to hand-edit anything, but all of this is (very close) >> pre-release code that we are in the final stages of testing and rolling out. >> I'm sorry it's causing errors. Also sorry I failed to notice your heavy >> sarcasm. Yay. >> >> There are three stages involved here: >> >> 1. gem install radiant-* should install radiant and all of the gems on which >> it depends. >> >> 2. radiant myApp should create an instance of radiant in the directory >> ./myApp >> >> 3. cd'ing into that directory and running bundle install should lock a >> bundle that makes the same newly installed gems available to the myApp app. >> >> For some reason in your installation the chunky_png gem wasn't available to >> the app. Could you please let me know what you get in response to these >> commands: >> >> $ gem show chunky_png >> $ bundle show chunky_png# might blow >> up, but still useful >> $ gem dependency radiant >> >> thanks for testing this, >> >> will >> >> >> >> >> >> >> >> >> >>> On Sep 14, 12:58 pm, Dave wrote: >>>> Hi, >> >>>> In fact, now that I try and create a site with the new radiant gem, >>>> all it does it error out on missing gems. >> >>>> Yay. >> >>>> On Sep 14, 12:42 pm, Dave wrote: >> >>>>> Hi William, >> >>>>> Here
Re: [Radiant] Re: Radiant Edge Install issues
On 14 Sep 2011, at 18:17, Dave wrote: > Seems the gemspec builds a gem that cannot actually install anything, > as it depends on gems it did not install in the first place. Other > then hand editing the radiant gems lockfile is there an easier way to > use the rc3 gem??? You shouldn't need to hand-edit anything, but all of this is (very close) pre-release code that we are in the final stages of testing and rolling out. I'm sorry it's causing errors. Also sorry I failed to notice your heavy sarcasm. Yay. There are three stages involved here: 1. gem install radiant-* should install radiant and all of the gems on which it depends. 2. radiant myApp should create an instance of radiant in the directory ./myApp 3. cd'ing into that directory and running bundle install should lock a bundle that makes the same newly installed gems available to the myApp app. For some reason in your installation the chunky_png gem wasn't available to the app. Could you please let me know what you get in response to these commands: $ gem show chunky_png $ bundle show chunky_png# might blow up, but still useful $ gem dependency radiant thanks for testing this, will > On Sep 14, 12:58 pm, Dave wrote: >> Hi, >> >> In fact, now that I try and create a site with the new radiant gem, >> all it does it error out on missing gems. >> >> Yay. >> >> On Sep 14, 12:42 pm, Dave wrote: >> >> >> >> >> >> >> >>> Hi William, >> >>> Here is one thing for you. >> >>> command: >>> radiant myApp >> >>> errors out with... >> >>> /Users/campista-socialista/.rvm/gems/ree-1.8.7-2011.03@radiant/gems/ >>> radiant-1.0.0.rc3/bin/../config/../config/preinitializer.rb:18: >>> Bundler couldn't find some gems: Could not find chunky_png-1.2.1 in >>> any of the sources. Did you run `bundle install`? (RuntimeError) >>> from /Users/campista-socialista/.rvm/gems/ree-1.8.7-2011.03@radiant/ >>> gems/radiant-1.0.0.rc3/bin/../config/boot.rb:48:in `load' >>> from /Users/campista-socialista/.rvm/gems/ree-1.8.7-2011.03@radiant/ >>> gems/radiant-1.0.0.rc3/bin/../config/boot.rb:48:in `preinitialize' >>> from /Users/campista-socialista/.rvm/gems/ree-1.8.7-2011.03@radiant/ >>> gems/radiant-1.0.0.rc3/bin/../config/boot.rb:19:in `boot!' >>> from /Users/campista-socialista/.rvm/gems/ree-1.8.7-2011.03@radiant/ >>> gems/radiant-1.0.0.rc3/bin/../config/boot.rb:122 >>> from /Users/campista-socialista/.rvm/rubies/ree-1.8.7-2011.03/lib/ >>> ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in >>> `gem_original_require' >>> from /Users/campista-socialista/.rvm/rubies/ree-1.8.7-2011.03/lib/ >>> ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' >>> from /Users/campista-socialista/.rvm/gems/ree-1.8.7-2011.03@radiant/ >>> gems/radiant-1.0.0.rc3/bin/radiant:5 >>> from /Users/campista-socialista/.rvm/gems/ree-1.8.7-2011.03@radiant/ >>> bin/radiant:19:in `load' >>> from /Users/campista-socialista/.rvm/gems/ree-1.8.7-2011.03@radiant/ >>> bin/radiant:19 >> >>> Any idea why that occurs? >> >>> On Sep 14, 11:13 am, William Ross wrote: >> >>>> On 14 Sep 2011, at 15:58, Dave wrote: >> >>>>> >> >>>>> Is there a way to use the radiant gem and have it play nice without >>>>> the vendored rails...??? >> >>>>> I am quite capable of using Bundler and my Gemfile to ensure Radiant >>>>> is happy, but apparently this is not possible with the current radiant >>>>> gem? >> >>>> What you have there is not really edge, but quite an old release candidate >>>> that is about to be replaced any moment now. >> >>>> Edge radiant vendors nothing, uses Bundler properly and sets everything up >>>> for you. The way to get it right now is from the repository: >> >>>> First install radiant: >> >>>> $ rvm 1.8.7 # if you're using RVM. You may also want an >>>> @radiant gemset for testing purposes >> >>>> $ cd /tmp # or wherever >>>> $ git clone git://github.com/radiant/radiant.git >>>> $ cd radiant >>>> $ gem build radiant.gemspec >>>> $ sudo gem install radiant-1.0.0.rc3.gem >> >>>> Then use radiant to create an application: >> >>>> $ cd /var/www # or wherever >>>> $ radiant myapp >>>> $ cd myapp >>>> … edit Gemfile to add extensions and config/environment.rb >>>> to configure application >>>> $ bundle install >>>> $ rake db:bootstrap >> >>>> If you run into any problems with that sequence, please let us know. This >>>> is all about to be released and we'd be very glad of any input from >>>> testers. >> >>>> Thank you, >> >>>> will >> >>>> ps. Once the RC3 gem is released, the installation sequence just be `gem >>>> install radiant`, of course. __ William Ross Spanner Ltd 18 Fountain Street Ulverston Cumbria LA12 7EQ 01229 588098 or 07771 562745
Re: [Radiant] Re: Radiant Edge Install issues
On 14 Sep 2011, at 17:58, Dave wrote: > Hi, > > In fact, now that I try and create a site with the new radiant gem, > all it does it error out on missing gems. I'm glad to hear that the gem is working, but apart from the unavoidable deprecation noise it shouldn't show any errors in the instance you generate. Is it still to do with chunky_png? will > > Yay. > > > > On Sep 14, 12:42 pm, Dave wrote: >> Hi William, >> >> Here is one thing for you. >> >> command: >> radiant myApp >> >> errors out with... >> >> /Users/campista-socialista/.rvm/gems/ree-1.8.7-2011.03@radiant/gems/ >> radiant-1.0.0.rc3/bin/../config/../config/preinitializer.rb:18: >> Bundler couldn't find some gems: Could not find chunky_png-1.2.1 in >> any of the sources. Did you run `bundle install`? (RuntimeError) >> from /Users/campista-socialista/.rvm/gems/ree-1.8.7-2011.03@radiant/ >> gems/radiant-1.0.0.rc3/bin/../config/boot.rb:48:in `load' >> from /Users/campista-socialista/.rvm/gems/ree-1.8.7-2011.03@radiant/ >> gems/radiant-1.0.0.rc3/bin/../config/boot.rb:48:in `preinitialize' >> from /Users/campista-socialista/.rvm/gems/ree-1.8.7-2011.03@radiant/ >> gems/radiant-1.0.0.rc3/bin/../config/boot.rb:19:in `boot!' >> from /Users/campista-socialista/.rvm/gems/ree-1.8.7-2011.03@radiant/ >> gems/radiant-1.0.0.rc3/bin/../config/boot.rb:122 >> from /Users/campista-socialista/.rvm/rubies/ree-1.8.7-2011.03/lib/ >> ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in >> `gem_original_require' >> from /Users/campista-socialista/.rvm/rubies/ree-1.8.7-2011.03/lib/ >> ruby/site_ruby/1.8/rubygems/custom_require.rb:36:in `require' >> from /Users/campista-socialista/.rvm/gems/ree-1.8.7-2011.03@radiant/ >> gems/radiant-1.0.0.rc3/bin/radiant:5 >> from /Users/campista-socialista/.rvm/gems/ree-1.8.7-2011.03@radiant/ >> bin/radiant:19:in `load' >> from /Users/campista-socialista/.rvm/gems/ree-1.8.7-2011.03@radiant/ >> bin/radiant:19 >> >> Any idea why that occurs? >> >> On Sep 14, 11:13 am, William Ross wrote: >> >> >> >> >> >> >> >>> On 14 Sep 2011, at 15:58, Dave wrote: >> >>>> >> >>>> Is there a way to use the radiant gem and have it play nice without >>>> the vendored rails...??? >> >>>> I am quite capable of using Bundler and my Gemfile to ensure Radiant >>>> is happy, but apparently this is not possible with the current radiant >>>> gem? >> >>> What you have there is not really edge, but quite an old release candidate >>> that is about to be replaced any moment now. >> >>> Edge radiant vendors nothing, uses Bundler properly and sets everything up >>> for you. The way to get it right now is from the repository: >> >>> First install radiant: >> >>> $ rvm 1.8.7 # if you're using RVM. You may also want an >>> @radiant gemset for testing purposes >> >>> $ cd /tmp # or wherever >>> $ git clone git://github.com/radiant/radiant.git >>> $ cd radiant >>> $ gem build radiant.gemspec >>> $ sudo gem install radiant-1.0.0.rc3.gem >> >>> Then use radiant to create an application: >> >>> $ cd /var/www # or wherever >>> $ radiant myapp >>> $ cd myapp >>> … edit Gemfile to add extensions and config/environment.rb >>> to configure application >>> $ bundle install >>> $ rake db:bootstrap >> >>> If you run into any problems with that sequence, please let us know. This >>> is all about to be released and we'd be very glad of any input from testers. >> >>> Thank you, >> >>> will >> >>> ps. Once the RC3 gem is released, the installation sequence just be `gem >>> install radiant`, of course. __ William Ross Spanner Ltd 18 Fountain Street Ulverston Cumbria LA12 7EQ 01229 588098 or 07771 562745
Re: [Radiant] Radiant RC2 - Assets - Uploading a Video Error
On 13 Sep 2011, at 18:22, James Martens wrote: > Hi again radiant peeps. > > Another issue has cropped up for me on RC2. > In assets, I am trying to upload a video, but I am getting a very > strange error (occurs in both development and production). The error > happens as soon as I click the create asset button and appears to be > in the post process phase: > > > MissingSourceFile (no such file to load -- /Users/jaemo/projects/ > family_justice/lib/paperclip_processors/frame_grab.rb): That is an odd error, but I'm not surprised: RC2 is very old now. RC3 is about to be released and will bring in a much more recent version of the clipped extension. I would advise that you try edge radiant (from the github repository) or wait a day or so for RC3. And yes, people have tried uploading videos. You need ffmpeg installed to get most of the benefit but it works very well. Will
Re: [Radiant] Radiant Edge Install issues
On 14 Sep 2011, at 15:58, Dave wrote: > > > Is there a way to use the radiant gem and have it play nice without > the vendored rails...??? > > I am quite capable of using Bundler and my Gemfile to ensure Radiant > is happy, but apparently this is not possible with the current radiant > gem? What you have there is not really edge, but quite an old release candidate that is about to be replaced any moment now. Edge radiant vendors nothing, uses Bundler properly and sets everything up for you. The way to get it right now is from the repository: First install radiant: $ rvm 1.8.7 # if you're using RVM. You may also want an @radiant gemset for testing purposes $ cd /tmp # or wherever $ git clone git://github.com/radiant/radiant.git $ cd radiant $ gem build radiant.gemspec $ sudo gem install radiant-1.0.0.rc3.gem Then use radiant to create an application: $ cd /var/www # or wherever $ radiant myapp $ cd myapp … edit Gemfile to add extensions and config/environment.rb to configure application $ bundle install $ rake db:bootstrap If you run into any problems with that sequence, please let us know. This is all about to be released and we'd be very glad of any input from testers. Thank you, will ps. Once the RC3 gem is released, the installation sequence just be `gem install radiant`, of course.
Re: [Radiant] rails version on radiant
On 19 Aug 2011, at 12:09, Jacky Huang wrote: > Hi, > > I install radiant on ubuntu with 'sudo gem install rails radiant'. And > the rails version is 3.0.10. > jacky@jacky-laptop:~$ rails -v > Rails 3.0.10 > jacky@jacky-laptop:~$ radiant -v > Radiant 0.9.1 > jacky@jacky-laptop:~$ > I know currently radiant is not supported with rails 3.0. So I am > confused with this result. Are there something wrong? $ gem install rails radiant is an instruction to install first the rails gem, and then the radiant gem. You're getting the latest rails and the latest (non-prerelease) radiant, and everything is as it should be but not quite what you wanted. If you were using the nearly-nearly-ready radiant 1, you would only need to say: $ gem install radiant and rails would be brought in automatically as a dependency. If you want to use radiant 0.91, you also only need to say: $ gem install radiant but in that case it works because older versions of radiant include their own copies of rails in vendor/rails. So as it happens, your installation of rails 3.10 might not matter. It's best to uninstall it, though: when you start adding extensions and other gems that have their own dependencies on ActiveSupport (or similar) you can end up with rails-version-confusion. best, will
Re: [Radiant] Having issues getting RadiantCMS to run for the first time
On 6 Aug 2011, at 22:33, Chance wrote: > First off, I'm still pretty much a Rails newb, especially < 3 so > forgive me if this is pretty naive. Anyway, I've followed the > installation instructions but I am running into the following error. > Any help would be very much appreciated, thanks! > > > => Booting WEBrick > => Rails 2.3.11 application starting on http://0.0.0.0:3000 > [...warnings about deprecation] > /Users/chance/.rvm/gems/ruby-1.8.7-p352/gems/radiant-1.0.0.rc2/lib/ > radiant/extension_loader.rb:154:in `select_extension_roots': undefined > method `each' for nil:NilClass (NoMethodError) Is this a radiant that you've recently updated? The immediate cause is probably that you need a line like this in environment.rb: config.ignore_extensions [:dutch_language_pack, :french_language_pack, :german_language_pack, :italian_language_pack, :japanese_language_pack, :russian_language_pack, :debug] The best remedy is to change to your application directory and run: rake radiant:update If there have been changes then this will create a new environment.rb file (among other updates) and rename the existing file to environment.bak. best, will > from /Users/chance/.rvm/gems/ruby-1.8.7-p352/gems/radiant-1.0.0.rc2/ > lib/radiant/extension_loader.rb:131:in `load_extension_roots' > from /Users/chance/.rvm/gems/ruby-1.8.7-p352/gems/radiant-1.0.0.rc2/ > lib/radiant/extension_loader.rb:37:in `extension_load_paths' > from /Users/chance/.rvm/gems/ruby-1.8.7-p352/gems/radiant-1.0.0.rc2/ > lib/radiant/extension_loader.rb:45:in `add_extension_paths' > from /Users/chance/.rvm/gems/ruby-1.8.7-p352/gems/radiant-1.0.0.rc2/ > lib/radiant/initializer.rb:214:in `set_autoload_paths' > from /Users/chance/.rvm/gems/ruby-1.8.7-p352/gems/radiant-1.0.0.rc2/ > vendor/rails/railties/lib/initializer.rb:135:in `process' > from /Users/chance/.rvm/gems/ruby-1.8.7-p352/gems/radiant-1.0.0.rc2/ > vendor/rails/railties/lib/initializer.rb:113:in `send' > from /Users/chance/.rvm/gems/ruby-1.8.7-p352/gems/radiant-1.0.0.rc2/ > vendor/rails/railties/lib/initializer.rb:113:in `run' > from /Users/chance/.rvm/gems/ruby-1.8.7-p352/gems/radiant-1.0.0.rc2/ > lib/radiant/initializer.rb:210:in `run' > from /Users/chance/code/rails/cs/config/environment.rb:12 > from /Users/chance/.rvm/rubies/ruby-1.8.7-p352/lib/ruby/site_ruby/1.8/ > rubygems/custom_require.rb:55:in `gem_original_require' > from /Users/chance/.rvm/rubies/ruby-1.8.7-p352/lib/ruby/site_ruby/1.8/ > rubygems/custom_require.rb:55:in `require' > from /Users/chance/.rvm/gems/ruby-1.8.7-p352/gems/radiant-1.0.0.rc2/ > vendor/rails/activesupport/lib/active_support/dependencies.rb:182:in > `require' > from /Users/chance/.rvm/gems/ruby-1.8.7-p352/gems/radiant-1.0.0.rc2/ > vendor/rails/activesupport/lib/active_support/dependencies.rb:547:in > `new_constants_in' > from /Users/chance/.rvm/gems/ruby-1.8.7-p352/gems/radiant-1.0.0.rc2/ > vendor/rails/activesupport/lib/active_support/dependencies.rb:182:in > `require' > from /Users/chance/.rvm/gems/ruby-1.8.7-p352/gems/radiant-1.0.0.rc2/ > vendor/rails/railties/lib/commands/server.rb:84 > from /Users/chance/.rvm/rubies/ruby-1.8.7-p352/lib/ruby/site_ruby/1.8/ > rubygems/custom_require.rb:55:in `gem_original_require' > from /Users/chance/.rvm/rubies/ruby-1.8.7-p352/lib/ruby/site_ruby/1.8/ > rubygems/custom_require.rb:55:in `require' > from script/server:3 > > > > Here is my gem list for my 1.8.7 rvm gemset: > > actionmailer (2.3.11) > actionpack (2.3.11) > activemodel (3.0.9) > activerecord (2.3.11) > activeresource (2.3.11) > activesupport (3.0.9, 2.3.11) > acts_as_list (0.1.4) > arel (2.0.10) > builder (2.1.2) > cocaine (0.1.0) > compass (0.10.6) > delocalize (0.2.6) > diff-lcs (1.1.2) > haml (3.0.25) > i18n (0.5.0) > mime-types (1.16) > paperclip (2.3.16) > rack (1.1.2) > radiant (1.0.0.rc2, 0.9.1) > rails (2.3.11) > rake (0.8.7 ruby) > RedCloth (4.2.7) > rspec (2.6.0) > rspec-core (2.6.4) > rspec-expectations (2.6.0) > rspec-mocks (2.6.0) > tzinfo (0.3.29) > uuidtools (2.1.2) > will_paginate (2.3.15) __ William Ross Spanner Ltd 18 Fountain Street Ulverston Cumbria LA12 7EQ 01229 588098 or 07771 562745
Re: [Radiant] Version of compass that's compatible with Radiant 0.9.1
On 20 Jul 2011, at 23:33, Wes Gamble wrote: > On 7/20/11 4:58 PM, Wes Gamble wrote: >> >> On 7/20/11 4:32 PM, Wes Gamble wrote: >>> >>> Does anyone know if there is a version of Compass that's compatible with >>> using Radiant 0.9.1 as a gem? >>> >>> Radiant 0.9.1 packages haml as a plugin (and hence Sass). >>> >>> Thanks, >>> Wes >> FWIW, I vendor'ed radiant, removed the haml plugin and seem to be >> successfully running off the latest compass, haml, and sass gems. >> >> Wes > OK, I inadvertently lied, I had to make changes to the following Sass files > to make them conform to the new Sass syntax. > > public/stylesheets/sass/admin/modules > _opacity.sass > _rounded.sass > _shadow.sass Those files have all been removed from nearly-version-1 in favour of compass mixins. They can cause intermittent crashes if left in place (each time an nginx worker starts up and sass tries to parse the old files) so we will need a routine, or at least a warning, to remove them. I think sass 3.1 is the first version of Sass not to understand !notation. Not sure. You shouldn't run into any other problems but if you do, you could try Haml 3. best will
Re: [Radiant] use compass w/ 1.0.0.RC
On 1 Jul 2011, at 16:57, Joel Oliveira wrote: > Compass and sass (and scss) are supported but I've found that if you want to > use a version of compass/sass that's higher than the vendored versions it > gets a little tricky. If you're ok with built-in support with compass 0.10.6 > and haml (I think?) then you're already clear. Edge radiant is on compass 0.11.1 and haml/sass 3.1.1, but it hasn't made it into an RC yet. will
Re: [Radiant] use compass w/ 1.0.0.RC
On 1 Jul 2011, at 15:29, Bob Sleys wrote: > You bring up another point I'm confused on. It's a been a while since I've > done a site and used sass so this scss is new to me. I just checked the sass > website and see scss in the new syntax and ya I agree it looks to be a step > backward to me at least at first glance. So now the question is does radiant > sass filter support both syntax's and if so how? Yes, it does. You can choose either sass or scss from the filter dropdown on the edit-stylesheet page. will
Re: [Radiant] use compass w/ 1.0.0.RC
On 1 Jul 2011, at 15:22, Bob Sleys wrote: > I guess my little test didn't go far enough to see it work > > How do you import one sass style sheet into antoher IE. > > is is possible to do something like this? > > // In this file you should write your main styles or centralize your imports > > // Automatically imports compass/CSS3 and compass/Utilities > // See http://compass-style.org/docs/reference/compass/ > @import compass > > // Other custom styles > @import partials/grid > @import partials/solarize > @import partials/main > @import partials/page_header > @import partials/page_nav > @import partials/page_footer > @import partials/flashes I don't think you can do that at the moment. I'm not even sure it possible, since the compiled sass is only accessible over http. There is nothing in the filesystem to @import. I do agree that it's desirable, though. Perhaps Jim has plans. will
Re: [Radiant] use compass w/ 1.0.0.RC
On 1 Jul 2011, at 14:47, Bob Sleys wrote:
> Since Radiant now includes compass for it's own use how can it be used to
> setup the site?
>
> I tried including a compass plugin in a .scss file and including that
> stylesheet into the layout but that didn't work, no include happened.
> Perhaps I'm missing something obvious.
It should just work. I've just tried this in Sass:
@import compass/css3
div
border: 3px solid #777
+box-shadow()
and this in scss:
@import "compass/css3";
div {
border: 3px solid #777;
@include box-shadow();
}
And both seem fine. Which version of radiant are you using, please?
will
ps. am I the only one who thinks SCSS is a dull step backwards?
Re: [Radiant] Re: Multiple Server Deployment for Radiant
On 27 Jun 2011, at 04:56, Shanison wrote: > Hi William, > > Thank you very much for your detailed explanation and suggestion. This > is very helpful. For my case, actually it is for railover, so I think > I have to use rSync or write an extension that money patch the asset > manager, where upon any files uploaded to the server, I can do a > synchronization. > > This is a bit trouble though. We have also thought of storing all > assets in the db instead. Synchronization of db is much easier and > efficient. But this means that we have to money patch the asset > manager again to make it store in db instead of file system. That would probably be easier to code: it's just a different paperclip storage module. See eg. http://patshaughnessy.net/2009/4/14/database-storage-for-paperclip-rewritten-to-use-a-single-table but it doesn't feel like a very appealing solution. You would miss out on a lot of server-side optimisation: delivering static files is always the way to go if you can. It should be fairly easy to trigger a script from the asset manager. Again, it's not our code but the behaviour of Paperclip that you need to change. Have a look at the flush_writes and flush_deletes methods in Paperclip::Storage::Filesystem. If I was doing this I think I'd add :after_storage and :after deletion callbacks. best, will
Re: [Radiant] errors with clean install of radiant 1.0.0.RC2
Hi Bob,
Thanks for the report. This is a curious and intermittent problem that has a
github issue in the clipped extension. I think it's fixed now that we're
offloading nearly everything into gems, but that work is in progress at the
moment so I can't quite tell yet.
I may well vendor acts_as_list anyway. It's only about 20 lines and it has
caused 100 times that much discussion.
best,
will
On 21 Jun 2011, at 14:09, Bob Sleys wrote:
> I've installed radiant 1.0.0.rc2 into a clean RVM setup with an empty gemset
> running ruby 1.8.7.
>
> Installing radaint (gem install radiant --prerelease) yielded the following
> installed gems
>
> *** LOCAL GEMS ***
>
> activemodel (3.0.9)
> activerecord (3.0.9)
> activesupport (3.0.9)
> acts_as_list (0.1.3)
> arel (2.0.10)
> builder (2.1.2)
> compass (0.10.6)
> delocalize (0.2.6)
> haml (3.0.25)
> i18n (0.5.0)
> paperclip (2.3.11)
> rack (1.1.2)
> radiant (1.0.0.rc2)
> rake (0.8.7)
> RedCloth (4.2.7)
> sqlite3 (1.3.3)
> tzinfo (0.3.28)
> uuidtools (2.1.2)
> will_paginate (2.3.15)
>
> Doing a rake db:bootstrap using the stylized blog and browsing the resulting
> site works fine.
>
> Now on the errors. Editing a page yields the following error.
> NoMethodError in Admin/pages#edit
>
> Showing
> /home/bsleys/.rvm/gems/ruby-1.8.7-p334@ooo-web/gems/radiant-1.0.0.rc2/vendor/extensions/clipped/app/views/admin/pages/_assets.html.haml
> where line #5raised:
>
> undefined method `acts_as_list' for #
>
> Extracted source (around line #5):
>
> 2: - include_javascript 'admin/assets'
> 3:
> 4: #attachment_list.assets
> 5: %ul#attachment_fields{:class => @page.page_attachments.empty? ? 'empty'
> : ''}
> 6: = render :partial => 'admin/page_attachments/attachment', :collection
> => @page.page_attachments
> 7: %p.note
> 8: = link_to t('clipped_extension.assets'), '#attach_asset', :class =>
> 'popup'
>
> Trace of template inclusion:
> /home/bsleys/.rvm/gems/ruby-1.8.7-p334@ooo-web/gems/radiant-1.0.0.rc2/app/views/admin/pages/_fields.html.haml,
>
> /home/bsleys/.rvm/gems/ruby-1.8.7-p334@ooo-web/gems/radiant-1.0.0.rc2/app/views/admin/pages/edit.html.haml
>
>
> Uploading an image via the assets page gave the following error
> NameError in Admin/assetsController#create
>
> uninitialized constant Asset::UUIDTools
> RAILS_ROOT: /home/bsleys/projects/ooo-web
>
> Application Trace | Framework Trace | Full Trace
> Request
>
> Parameters:
>
> {"commit"=>"Create Asset",
> "format"=>"html",
> "authenticity_token"=>"QbD6zpC1EN7q988vhTag/18ZAAPK0CcauHnoEUD1Rfk=",
> "asset"=>{"title"=>"logo",
> "caption"=>"",
> "asset"=>#}}
>
>
Re: [Radiant] Values of the Radiant community (and Ecommerce solution?)
On 20 Jun 2011, at 16:34, Jim Gay wrote: > On Mon, Jun 20, 2011 at 10:17 AM, rosslaird wrote: >> I am consistently impressed with how helpful and friendly people are >> to another on this list. It's good to see. And I wonder about the role >> that geek practices such as the agile methodology play in this kind of >> friendly behavior. I've been reading more about agile and related >> practices (I am a writer, not a programmer), and I have been surprised >> at the emphasis, in those practices, on ethics such as collaboration, >> authenticity, appropriate conflict resolution, and so on. In Lyssa >> Adkins' book "Coaching Agile Teams," she emphasizes values such as >> courage, focus, respect, and openness. As someone with a professional >> background in counselling, I can't help but notice how much overlap >> there is between agile values and counselling values. It's very >> heartening to see such deep, resonant, ancient human values at work in >> contemporary practices such as software development. And the Radiant >> community, more than any other software development community that >> I've encountered, embodies those values in the communications on this >> forum. Thanks for walking your talk. >> >> Now, to my question: I'm looking for an ecommerce solution, to >> integrate with Radiant, that will allow me to sell my books (three of >> them) and my consulting services on my website (I'm running Radiant >> 0.9.1). Is something like Shopify a good option, or is there a simpler >> (or better) solution for someone like me? >> >> Thanks in advance. >> >> Ross Laird >> >> > > I'm so glad to hear that feedback, Ross. Me too. Very cheering. Thank you. I have one site that runs shopify and radiant together. It's behind an nginx proxy that uses SSI (so retro!) to incorporate bits of radiant content into the shopify pages. It works but it's a lot of hassle to create and look after, and the benefits are only there because that particular business wants to look more seamless and corporate than it really is. If the seller is an individual then I find people are prepared to take more trouble and to accept a more personal payment route. Especially the maker of the product, which I suppose you are. Paul's paypal-with-confirmation extension sounds like a good way to go. In the happy world of Rails 3 I think one of the project goals is to sit happily as an engine next to a Spree shop, but I wouldn't like to guess at a timetable for that. best, will
Re: [Radiant] Multiple Server Deployment for Radiant
On 19 Jun 2011, at 16:54, Shanison wrote: > Hi all, > > I have one Radiant website but deployed to a few servers, and one of > the server S1 will be used to serve static file content and serve as a > reverse proxy and redirect dynamic page request back to the other > servers S2, S3, S4. So my question is that when admin login to the > admin page, it can be from any of the servers, S2 or S3, S4. If he > uploads files e.g. images to S2, how can the rest of servers serves > the files? If a request comes in to display a page and is served at > S3, that images used in the page won't be displayed as it is not in > the same server. > > Is there a way to synchronize it? Thank you. I've done this different ways in the past and the I think the right one would depend on your reason for spreading across several servers in the first place: * If it's for load-sharing, and you can think of one of the servers as the master, you may find it's enough just to redirect all requests for /admin and /assets to the master. * if it's for redundancy and failover, you will need some scripting behind radiant to move files around. Again, the method depends on your situation: you can do it with rsync or an active push from the receiving server. It would be easy to write an extension that triggered the mirroring script upon image update, but note that you'd have to duplicate all the thumbnail sizes as well as the original image. * If it's geographical, or the other two solutions don't appeal, you could just use a CDN with uplift, or the built-in S3 support we get from paperclip. I think the most successful strategy I've used was to set up both database servers (this was a rather paranoid and very busy site) as simple static-file asset servers, and to direct all requests for static files from those two. There were some rather basic rsync scripts to mirror uploaded assets. I figured that if the database went down then the rest didn't really matter anyway. If anyone knows a standard (cross-platform) way that we could meet this requirement from within radiant's asset manager I'd be very happy to write it in. For what it's worth, I don't deploy across multiple servers any more, apart from a separate database host. More recently I've found that one decent server with a long cache life is more efficient than several with only brief caches (as they must be, because you're only ever clearing the cache on one of them). best, will
Re: [Radiant] Re: animated GIFs
On 15 Jun 2011, at 11:09, GD wrote: > On Jun 15, 12:02 pm, William Ross wrote: >> On 15 Jun 2011, at 09:28, GD wrote: >> >>> Hello Everybody, >> >>> I am new to the list, very new to CMSs and very very new to Radiant (a >>> great system, very excited to use it) ... >> >>> building my wife's chocolate & truffles website I wonder, if Radiant >>> display animated GIFs. I uplloaded one and it doesn't work. Is there a >>> trick to it or an extension? >> >> Hello Guido, and welcome. >> >> Radiant doesn't touch the image file itself, so if you want to display the >> uploaded GIF, you should only need a tag like this: >> >> >> >> You should be able to omit the size parameter too: 'original' is the default. >> >> If you want to display one of the resized versions, you will run into two >> issues. First, the standard thumbnail and icon are translated to PNG format >> for use in the admin interface. You would need to add another thumbnail >> style that did not change the image format. Secondly, an issue with >> paperclipped: due to a pdf-resizing hack it will only capture the first >> frame of an animated gif. There is a patch that we can apply if the main >> distribution doesn't adopt it, but it will get a bit messy and I'm reluctant >> unless there is a strong demand from the animated-gif-resizing community. >> >> best, >> >> will > > Thank all for your quick answers > > @will > > 1. so if I choose the right dimensions for the gif, so the system > won't have to do an resizing, the animation will play, when the pages > are displayed? If you upload an animated gif file and then display the original file, there is no processing involved and the file will display normally. I For a static image file you could also use one of the automatically-resized versions, but with an animated GIF the resizing breaks the animation, so it's not usually a good option. There is also the separate question of what height and width to specify in your html (or radius tag). That doesn't affect the file-processing and as usual, for best results you want the image to display at its natural size. In your case that will be the dimensions of the original file you uploaded. You can also achieve this by omitting the height and width parameters and letting the browser decide, but it's generally better to specify dimensions if you can. In short, you have to make the animated GIF at the right size before you upload it, but after that it should all just work. > 2. is there an alternative to animegifs, that radiant will display > without any hassle? Not really, no, but it depends on your ultimate purpose. If you just want to display a slideshow of chocolates, which I think we can all agree is a good thing, then you can do it better with static images and javascript effects. For more complex animations your only other option is to use flash (which the asset manager will handle but not process). best, will
Re: [Radiant] animated GIFs
On 15 Jun 2011, at 09:28, GD wrote: > Hello Everybody, > > I am new to the list, very new to CMSs and very very new to Radiant (a > great system, very excited to use it) ... > > building my wife's chocolate & truffles website I wonder, if Radiant > display animated GIFs. I uplloaded one and it doesn't work. Is there a > trick to it or an extension? Hello Guido, and welcome. Radiant doesn't touch the image file itself, so if you want to display the uploaded GIF, you should only need a tag like this: You should be able to omit the size parameter too: 'original' is the default. If you want to display one of the resized versions, you will run into two issues. First, the standard thumbnail and icon are translated to PNG format for use in the admin interface. You would need to add another thumbnail style that did not change the image format. Secondly, an issue with paperclipped: due to a pdf-resizing hack it will only capture the first frame of an animated gif. There is a patch that we can apply if the main distribution doesn't adopt it, but it will get a bit messy and I'm reluctant unless there is a strong demand from the animated-gif-resizing community. best, will
Re: [Radiant] animated GIFs
On 15 Jun 2011, at 09:54, Christian Aust wrote: > I assume you're using the 1.0 release candidate, and therefore the new asset > manager extension? > > I've seen this with transparent PNG, too. The paperclipped created thumbnails > didn't have transparent areas but instead black background. Radiant itself > shouldn't change the file that you're uploading but will use imagemagick to > create variants with other dimensions. The asset manager will only create the thumbnails that you tell it to, apart from a couple of standard sizes that we use in the admin interface. Both of those are small so we use pngs: in most other cases the original file format will be preserved. Imagemagick should handle transparency, but it does have some issues in older versions. It tends to add a black halo. Try and make sure you have version 6.2.4 or later. The asset manager is not very well documented at the moment, I'm afraid. It will be soon. For now you have to edit the config entry assets.thumbnails.image, where you can define as many thumbnails as you like with this kind of format: tiny:size=20x20#,format=png|huge:size=1280x1280>|... likewise for assets.thumbnails.video and so on. Be warned, though: one reason it's not documented is that we haven't committed to the format yet, so it is likely to change. The other reason is that soon this will all be configurable through the admin interface. best, will
Re: [Radiant] Clipped extension questions
On 2 Jun 2011, at 20:26, Wes Gamble wrote: > An interesting note: > > ImageMagick is included by default on the Heroku "bamboo" (Phusion REE 1.8.7) > stack, since assets uploading "just works" on Heroku. > > (I'm embarrassed to say that I just realized this even though have been > successfully uploading assets (on 0.9.1) on Radiant on Heroku for months.) > > ffmpeg is definitely not there, and I'm guessing ghostscript isn't either. > > I'll dig into the Heroku side of things about any opportunities to customize > those system level things, but in case it comes up... Thank you. Useful. I'll add an initializer to check for ghostscript on startup too: if it's missing you'll still get pdf icons. will
Re: [Radiant] Clipped extension questions
On 2 Jun 2011, at 20:19, Wes Gamble wrote: > Is ghostscript only used to generate PDF thumbnails? yes. will
Re: [Radiant] Understanding the configuration of the new clipped extension that manages assets
On 2 Jun 2011, at 18:42, Wes Gamble wrote: > So do the settings under the 'assets' key in Radiant::Config do anything > anymore, or is everything managed under 'clipped' now? > > Trying to set up for S3, and added all the 'assets.s3' settings and then > realized these all have to be 'clipped' > > Is 'assets' just an alias for 'clipped' or is it an actual different > namespace that means something outside of the context of 'clipped'? You can just use assets.s3.* as before. I considered changing the namespace but I decided the main thing was to make upgrades easy at this stage. I will probably complicate things later, when there are more back end options, but before then I mean to make the configuration interface a lot more helpful. will
Re: [Radiant] Lost some Radiant rake tasks in 1.0.0 RC2
On 2 Jun 2011, at 06:16, Paul Noden wrote: > Hi Jim / Wes, > > > On 6/1/11 9:18 PM, Jim Gay wrote: > >> Paul, I'm not sure I understand, but I missed your offer for > >> debugging: I accept! > > Jim - Am very happy to help however I can - I want to get involved in > Radiant, probably have most to contribute to extension development but happy > to pitch in when I gain familiarity. Priority for me is shipping a project on > 1.0.0 (having trouble with the reader extensions, if I can get some help off > list to check my configurations before I go reporting a non-issue on github > I'd certainly appreciate it! I have need for a few days of a radiant > freelancer asap! ) I've just started bringing reader and forum up to date for v1. Do let me know what you've got. will
Re: [Radiant] Re: Error after updating to 1.0 RC2
On 2 Jun 2011, at 02:17, Sam Whited wrote: > Wow. Took me ages to find, but I forgot to remove the old "assets" > extension. Nevermind, silly mistake on my part. I really need to make that 'duplicate definition' error more useful. They're always hard to fix. Thanks for reminding me. will > —Sam > > On Wed, Jun 1, 2011 at 20:49, Sam Whited wrote: >> After updating to Radiant 1.0 RC2 I've begun having the following error >> >> "Duplicate config definition for 'assets.additional_thumbnails'. Are >> you loading something twice?" >> >> when running most rake tasks (including migrations for new extensions). >> >> Has anyone else encountered this? A trace points me at config.rb, but >> I assume it's being called from an extension. Logs provided no further >> details. I'm assuming it's something to do with paperclipped. >> >> Best, >> Sam >> >> -- >> Sam Whited >> pub 2048R/0DBB515F >> >> SamWhited.com >> s...@samwhited.com >> 404.492.6008 >> >> Georgia Institute of Technology >> Mechanical Engineering Undergraduate >> swhi...@gatech.edu >> > > > > -- > Sam Whited > pub 2048R/0DBB515F > > SamWhited.com > s...@samwhited.com > 404.492.6008 > > Georgia Institute of Technology > Mechanical Engineering Undergraduate > swhi...@gatech.edu __ William Ross Spanner Ltd 18 Fountain Street Ulverston Cumbria LA12 7EQ 01229 588098 or 07771 562745
Re: [Radiant] Editing Radiant settings
On 1 Jun 2011, at 19:38, Wes Gamble wrote: > Should we still use the Radiant settings extension with 1.0.0 if we want to > edit settings easily? They won't conflict, but I hope you'll find most extension developers bring their configuration into the new interface. I'm about to make it a bit easier to do that. There are a lot of advantages to that approach - eg. validation, selection and defaulting are all done for you - but you do lose the ad-hoc config-creation that the settings extension allows. will
Re: [Radiant] Overriding the default admin layout
On 31 May 2011, at 20:15, Wes Gamble wrote: > How do I override the default admin. layout for Radiant? > > I'm playing with the Radiant 1.0.0 prerelease and it's caching the Javascript > into an "all" file and I want to take that behavior out, since I'm deploying > on Heroku and can't write to the filesystem. In this case it should be enough to set config.action_controller.perform_caching = false in config/environments/production.rb. If you really want to override the layout you can do that by including an app/layouts/application.html.haml in any extension. best, will
Re: [Radiant] radiant-1.0 any time soon?
On 15 May 2011, at 18:24, Jim Gay wrote: > There will be a lot happening this week. > I'm planning to hack on Radiant most of the time, so RailsConf should > bring some updates. > > The last pieces for 1.0 are bug fixes and the asset manager. The asset manager is about ready. John's latest changes to the workflow have all been implemented, and very little significant functionality remains to add: * hook up the 'insert' buttons * sanitize the configuration process (to separate the architectural settings from the merely convenient) There are a couple of #todos and I can see plenty of optimisations and cosmetic improvements that could be made, but it's tidy enough and functionally almost complete, so I think it's rc-ready. I've vendored it and would welcome your bug reports and improvements. best, will ps. The way assets are presented now means that I'm quite keen to add processors that will create video and pdf thumbnails, but it would have to be done in a platform-agnostic or at least a degradeable way. If anyone would like to throw in some code that would be a great help.
Re: [Radiant] Rails 3.x, how are we doing?
Hi Saša, There is a very active, though slightly intermittent rails 3 branch, and the main reason for the relative quiet recently is that we are right on the edge of a verson 1 release candidate. The roadmap broadly goes like this, as I understand it: * get v1.0 out with a definite core feature set and no bugs * document the feature set and API properly * small 1.0.x releases to fix anything we missed * get v2.0 out with the same feature set but on rails 3 * invent new stuff All of these efforts are a lot closer to completion than they might seem: the challenge we face is to offer a steady release schedule and a predictable target while also getting all this new work out the door. It's going to be an interesting year for radiant. best, will ps. Jim will correct anything I've put wrongly, I hope. On 29 Apr 2011, at 18:28, Saša Babić wrote: > I hope this won't give the wrong impression, because I do realise things > don't just happen by themselves and I'm grateful to everyone who's been > involved with Radiant development. > > Is there anything being done to migrate Radiant to the latest Rails. Any > future plans in that respect? I don't see anything in the repository. I might > have missed it, though. > > BTW, am I wrong to think that the traffic on this mailing list has been > slowed down as well? Did everyone just migrate to BrowserCMS (latest beta > supports Rails 3.0), Refinery (Rails 3.0 supported) or something else? :) > __ William Ross Spanner Ltd 18 Fountain Street Ulverston Cumbria LA12 7EQ 01229 588098 or 07771 562745
Re: [Radiant] Re: Tags and taggable
On 13 Mar 2011, at 20:40, rosslaird wrote: > It seems that tags uses a 'tags' table. I am using the tags extension > (version 1.5), created by Benny Degezelle and Jim Gay. The version of > taggable that I am trying to run alongside tags is version 1.2.1, > created by you (Will). Both of these versions are the most recent > available from github. > > Maybe the tags extension that I am running is the incorrect one? It's > this one: > > https://github.com/jomz/radiant-tags-extension Hm. I don't really know, since I use taggable for this kind of thing, but all I'm seeing here: https://github.com/jomz/radiant-tags-extension/blob/master/db/migrate/001_add_tag_support.rb is the meta_tags and taggings tables. > There are various other tags extensions listed on github (though all > the others seem to be qualified for a special application, such as > navigation). > > Before I go messing around with the tags extension (which I will > surely mess up even more), maybe this is simply a matter of getting > the correct tags extension. (Maybe?) I guess that depends what you're aiming to do. Both will do the job of tagging pages and then getting at them through tag clouds and other lists. Taggable is more general purpose but not so well-prepared out of the box. best, will > > Ross > > On Mar 13, 6:51 am, William Ross wrote: >> On 12 Mar 2011, at 22:18, rosslaird wrote: >> >>> I have the tags extension installed, and I want to try out taggable. >>> But it seems that both use a table called "tags," and this causes the >>> migration of taggable to halt. I suppose I will have to remove the >>> tags extension to install taggable, but if there is another way to do >>> this (so that I preserve both extensions) that would be preferable. >>> Ideas and suggestions most welcome. >> >> I thought the tags extension used a 'meta_tags' table and MetaTag object? >> They ought to be compatible in the sense that you can install one and then >> the other without destructive side effects. >> >> You might even be able to run them side by side: taggable takes over the >> keywords field where tags adds its own text-to-tags process. I wouldn't >> recommend it, though: there are likely to be odd method-name clashes and >> some admin UI collisions are likely. It will be hard to evaluate them, even >> if they work. >> >> best, >> >> will
Re: [Radiant] Tags and taggable
On 12 Mar 2011, at 22:18, rosslaird wrote: > I have the tags extension installed, and I want to try out taggable. > But it seems that both use a table called "tags," and this causes the > migration of taggable to halt. I suppose I will have to remove the > tags extension to install taggable, but if there is another way to do > this (so that I preserve both extensions) that would be preferable. > Ideas and suggestions most welcome. I thought the tags extension used a 'meta_tags' table and MetaTag object? They ought to be compatible in the sense that you can install one and then the other without destructive side effects. You might even be able to run them side by side: taggable takes over the keywords field where tags adds its own text-to-tags process. I wouldn't recommend it, though: there are likely to be odd method-name clashes and some admin UI collisions are likely. It will be hard to evaluate them, even if they work. best, will
Re: [Radiant] Re: How to take advantage of server-side caching (Rack cache) without using browser caching
On 9 Mar 2011, at 16:46, rosslaird wrote: > I can find various online postings and tutorials about increasing the > cache in rails, but is there a conventional way to do this in Radiant? > In other words, how do you do this: > >> The default cache timeout is only five minutes, though. I normally increase >> that to at least a week. The governing variable is SiteController.cache_timeout, and one common place to set it is in config/environment/production.rb: SiteController.cache_timeout = 24.hours best, will
Re: [Radiant] How to take advantage of server-side caching (Rack cache) without using browser caching
On 8 Mar 2011, at 16:18, Wes Gamble wrote: > William, > > Thanks for your reply. > > On 3/8/11 9:37 AM, William Ross wrote: >> >> On 5 Mar 2011, at 23:38, Wes Gamble wrote: >> QUESTION: Is the current caching scheme in Radiant (Rack) completely >> dependent on client-side caching, implying that a given user _must_ do a >> full render before any caching benefits are realized? >> >> >> No. The default cache timeout is only five minutes, though. I normally >> increase that to at least a week. During the timeout interval you should >> only be rendering the page once. >> >> I have been wondering about putting a 'cacheable?' flag on snippets and >> perhaps even rendering them on save if that flag is set. It feels a bit >> overcomplicated, though. The time would probably be better spent making >> radius less slow in the first place. >> > Even that one time is too much because it results in a ~10s page load. In > the meantime, I have implemented the fragment cache extension (which although > it was last updated for Radiant 0.8, works fine in 0.9.1) to cache these > slow-rendering snippets. > > I think you've answered my question, in that it appears that Rack::Cache is > only "pre-configured" to handle freshness based client side caching, and > although you _could_ use it for server side caching, Radiant isn't set up out > of the box to do that. I am still looking into it. The default Etag > behavior implemented by Rails and Rack::Cache seems to only save you response > transmission time on a cache hit, which doesn't seem like a particularly big > win (if I understand correctly). A successful Rack::Cache hit is a big win. A cache hit should reduce your response time to little more than webserver delays and in a relatively static radiant site with a long cache lifetime that's what you get. That's really the situation for which radiant is ideal. As soon as you move away from a simple publishing scenario it gets more strained, and if you introduce any degree of personalisation or responsiveness you're thrown back on the basic rendering machinery. As you've found, it's not optimised for speed. That's the price of flexibility: there is no determinate way to work out which pages are invalidated by changes to a particular object, so we can't render at save and there is no shortcut to an etag or even a last-modified date. We just have to render the page. > Agreed on making Radius less slow - if I have time, I will look at it. The good news there is that Radius development can proceed independently of radiant's release programme. The bad news is that the only real speedup will come from rewriting the ragel machine definition to emit C instead. best, will
Re: [Radiant] How to take advantage of server-side caching (Rack cache) without using browser caching
On 5 Mar 2011, at 23:38, Wes Gamble wrote: > I need to gain a deeper understanding of how the Radiant (Rack) cache works > in order to solve a performance problem. > > PROBLEM: I've created a sidebar in my app. which traverses the entire tree of > pages using Radius tags in order to render - it basically generates a tree > view of the published page hierarchy. This is extremely slow, however, and > takes on the order of 6-10s to render. I can set up standard Radiant caching > to be some amount of time, but for each user's _first_ request, the entire > page is re-rendered (2nd - N requests are cached locally in the browser and > return just fine). > > I have read through the Radiant::Cache class, and if I understand correctly, > the SiteController.cache_timeout value is used to set the "Cache-Control" > response header's "max-age" attribute. But the behavior that this appears to > exhibit is that the first request is still a full render, and then subsequent > requests pull from the local browser cache. > > PREFERRED WORKAROUND: Obviously, I need to improve the performance of the > rendering of the sidebar, but I'd like to try and have a workaround for now. > > I wrote a cron job that requests all of the pages of the site in order to > load up the Rack cache on the server, and then allow new clients to the site > to be able to take advantage of that server side caching. But still, for any > user, that first request still takes as long as a full render. I've > verified that the Rack cache appears to be filling up on the server. > > QUESTION: Why doesn't the page get served from the server side Rack cache > when a new user request a page that has been loaded into the Rack cache? Is > it because the default Etag calculation logic in Rails involves a full > re-render of the page in order to calculate the Etag? In testing you may not be seeing the standard public behaviour. Rack::Cache is (by default) configured to pass through any request with a Cookie: header, which means that a logged-in admin user will never hit the cache even on the published site. I've changed that recently in edge, so that the admin interface is explicitly uncached and the cookie header can be ignored. Nothing has blown up yet, but it still might. > QUESTION: Is the current caching scheme in Radiant (Rack) completely > dependent on client-side caching, implying that a given user _must_ do a full > render before any caching benefits are realized? No. The default cache timeout is only five minutes, though. I normally increase that to at least a week. During the timeout interval you should only be rendering the page once. I have been wondering about putting a 'cacheable?' flag on snippets and perhaps even rendering them on save if that flag is set. It feels a bit overcomplicated, though. The time would probably be better spent making radius less slow in the first place. best, will
Re: [Radiant] Re: Authentication for one Section of Site
On 1 Mar 2011, at 14:57, Carl Youngblood wrote: > Never mind, I think I got enough ideas from looking at Aslak > Hellesøy's ba extension. > > On Tue, Mar 1, 2011 at 1:49 PM, Carl Youngblood wrote: >> I found this topic on the mailing list from a few years ago. I'm >> building an extension that supports site user registration and login. >> I would like to be able to support two ways of restricting access to >> page content. I would like to create a different page type that would >> require login to be seen, such as: >> >> class SecurePage < Page >> end >> >> and I'd like to create tags for displaying content only if a user is >> logged in and only if a user is not logged in, such as: >> >> Secret information >> Public information You can do nearly all of this with the reader and reader_group extensions, if you don't mind adopting quite a lot of framework machinery to achieve a fairly simple purpose. Reader defines the tags that you mention and reader_group lets you restrict any page to one or more groups. If controlling access is going to be your only requirement then I wouldn't bother with all that: the key methods are find_page and show_page in SiteController and, as others have said, Page.cache?. You may find a starting point here: https://github.com/spanner/radiant-reader_group-extension/blob/master/lib/site_controller_extensions.rb The main difficulty will be that you want the same page to appear differently to a logged-in user. That's going to make effective caching much harder, though with care you can probably cache the default page and bypass the cache when a login cookie is present. best, will
Re: [Radiant] Re: send multiple emails with mailer?
On 27 Feb 2011, at 19:16, craayzie wrote: > If someone could jump in and provide guidance on how to best implement > sending multiple emails upon form submission that would be huge. I'd > hate to spend time working on an implementation only to figure out > afterwards that it wasn't the best approach. My advice, for what it's worth, would be to fork the mailer extension, make the very simple changes required to specify several messages in the 'mailer' part, and request that they are pulled. best, will
Re: [Radiant] Perhaps a bug, perhaps not
On 27 Feb 2011, at 19:18, BIO wrote: > If I put this into my "header" snippet then the parent and all the > child pages display images: > > Nyack Community Garden href="/">Nyack Community Garden id="site-subtitle">Established ... > > > If I put this into the snippet then only the parent displays the > images: > > Nyack Community Garden href="/">Nyack Community Garden id="site-subtitle">Established ... > > > The only difference is the leading slash: > > src="/images... This is normal web server behaviour if you consider that your child pages are effectively subdirectories. They have addresses in the form /child, but it is quite common for your web server configuration to turn that into /child/, and if you have grandchild pages they will look like /child/grandchild/. Without a leading slash the src attribute specifies a relative url, in this case /child/images or /child/grandchild/images, which don't exist. Is there a reason why you don't want the leading slash? best, will
Re: [Radiant] Conditional tags wiki info: typo or user ignorance?
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: > > > > Radiant Handbook > > > - Radiant Handbook > > > > 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 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 . Depending on the server, you may also want to set ignore_case="true". best, will
Re: [Radiant] Registering observers in a radiant extension
On 21 Feb 2011, at 09:57, swartz wrote: > Is there a better way to register an observer for a Radiant extension > than editing environment.rb? > > I have tried adding extension_config block to my extension like so > > extension_config do |config| >config.active_record.observers = :mymodel_observer > end > > But that did not work. In edge - but iirc not in 0.9.1 - you can put anything you want to run early into [extension root]/config/initializers. You should be able to define observers from there. best, will
Re: [Radiant] conflict with my extension and group extension
On 22 Feb 2011, at 14:47, MitchV wrote: > Thanks all for the great work on Radiant. > > I have built a simple little extension that sets up @font-face styles > correctly for all browsers based on fonts found in the assets > collection. > > The problem is the extension conflicts with the "Reader" extension. > > Specifically my extension needs to modify the behavior of show_page in > the site controller. I basically copied the way group does it using > alias method chain. > > Everything works fine until I include the reader, group, forum > extension set. Then it gets into a stack overflow inside of the > site_controller. Could you send me the error message and the stack? thanks, will
Re: [Radiant] Re: vhost extension site scoping
On 14 Feb 2011, at 08:14, craayzie wrote: > So weird. I run the migration but it does nothing to db/schema.rb: > > add_index "snippets", ["name", "site_id"], :name => > "index_snippets_on_name_and_site_id", :unique => true > add_index "snippets", ["name"], :name => "name", :unique => true > > Here's the exact migration: > > $ cat db/migrate/004_migration4.rb > class AddSiteIdIndex < ActiveRecord::Migration > def self.up >remove_index :snippets, :name > end It's probably the named index, and me being too hasty. Try remove_index :snippets, :name => 'name' will
Re: [Radiant] Re: vhost extension site scoping
On 14 Feb 2011, at 05:46, craayzie wrote: > So this appears to be simple issue of the Snippets model validation > not being updated. I know the proper way to do this is to create an > ActiveRecord migration but just to see it work I hand-edited vendor/ > radiant/app/models/snippet.rb > > - validates_uniqueness_of :name, :scope > + validates_uniqueness_of :name, :scope => :site_id > > I then ran 'rake db:migrate' but nothing changed? Did I miss a step? Slight muddle there: migrations change the database columns. Validations are applied in the model before the object is saved to the database. In the case of Snippets you have both kinds: there's a uniqueness constraint in the database which is supported by a validates_uniqueness call in the model class so that we can return advisory messages rather than just throwing errors. I don't know what the current situation is with the vhost extension but your fix to the validates_uniqueness call is right and you can remove the uniqueness constraint from the database with this migration: remove_index :snippets, :name You'll find similar validations on Layout and User but perhaps those won't matter. best, will
Re: [Radiant] radiant-settings broken with Radiant 0.9.1 and trunk (continued)
On 12 Feb 2011, at 06:36, cody eilar wrote: > Since I couldn't post a reply to the actual thread I am starting a new > one... > > Anyways, I am having the same problem as the above title. I am unable > to successfully install and run the radiant-settings extension. I do > the following steps: > > sudo gem install radiant-settings-extension > script/extension install settings > script/console production > -->Radiant::Config['roles.settings']='admin' > > rake radiant:extensions:settings:update > rake radiant:extensions:settings:migrate > > Then when I try to access "Subtites" for example under the > Applications window under Settings, I get an error such as: undefined > method `description' for # That doesn't sound like 0.9.1. Are you using edge? In that case you don't need settings: there's a new, extendable configuration panel built in. best, will
Re: [Radiant] Navigation question
On 10 Feb 2011, at 02:37, a...@akhlah.com wrote: > Forgive me if this seems a bit simplistic I am new to Radiant > > this is what I have on the main page > > > > > > > > > > > When I put the table on sub pages the links do not work - they seem to > just append to the url that they are coming from This is just how html linking works: A destination in the form "/somewhere" is absolute - that is, relative to the root of your site - but a link in the form "somewhere" with no initial slash is relative to the address of the page on which it sits. If you move it to a subpage it will point to a descendant of that page. In this case all you need to do is put a / at the beginning of each address. In rails apps relative links can be slightly troublesome anyway: our routing means that /page and /page/ will both render correctly, but the web browser sees one as a file and one as a subfolder and links from them differently. /links tend to work best. best, will ps. more at http://www.coffeecup.com/help/articles/absolute-vs-relative-pathslinks/
Re: [Radiant] How to render a snippet from inside a tag definition
On 2 Feb 2011, at 11:35, Hadi S. wrote: > I am defining some specific tags for a project. Is there a way to > render a snippet > from inside a tag definition? > > In my tag i need to retrieve the type of the page and want to render a > specific > snippet dependent of the type. You should be able to call render_snippet directly. Something like this piece of untested made-up code: if snippet = Snippet.find_by_name(snippet_name) tag.globals.page.render_snippet(snippet) end but I would feel uncomfortable about hard-coding content names. You might be better off defining conditional tags based on page class (...) and keeping the content-choice in the content layer. best, will
Re: [Radiant] Re: Slow page load times
On 2 Feb 2011, at 10:19, potapuff wrote: > Have same problem: all pages a responsed with 200 code. > > First of all i'd check: >SiteController.cache_timeout ~1 day >Radiant::Config['dev.host'] is different from production >Page.find_by_parent_id(nil).cache?true I've been looking into this a bit more and I suspect that for both you and Carl these tests are conducted while you are logged into the admin part of the site? Rack::Cache by default is configured to pass through any request that comes with a Cookie header. That would explain why visitors like Anton didn't see the performance problems that Carl was describing. If so it could be considered a testing artefact, but there are other reasons why a cookie might be present and we don't want them all to disable the cache. I've just checked in an update to make the cache indifferent to cookies and explicitly uncache the admin pages instead. I'd be interested to see if your results are different now. There is probably a debate to be had here but imho the radiant codebase generally presumes that pages are not personalised and if we want to build for efficient delivery of per-user content then we need to change a lot more than just the cache headers. I think this update just makes things more consistent, but I'm happy to be disagreed with. Caching is a tricky subject and I am often wrong. This should also help with extensions like reader and shop that use their own cookieing scheme. I'm doing some experiments with cached forum pages to see how that works out. best, will
Re: [Radiant] Unique slug constraint on children of ArchivePage
On 1 Feb 2011, at 15:50, D.Kreft wrote: > On Tue, Feb 1, 2011 at 6:43 AM, William Ross wrote: > > I don't use the archive extension but my feeling here is that the logic in > the model is right and your url scheme is twisting things a bit out of shape. > Any reason not to use /events/city//MM/DD? Then the slug constraint would > be helping you as it's meant to. It may just be a case of creating a page for > each city. > > If I use the scheme you're suggesting (and I have thought of it), it would > lead to longer urls and it still wouldn't solve the problem. The scheme we > use is more like: > > /apac/seminars/2011/02/01/beijing > /apac/workshops/2011/03/02/beijing > > Turning this upside-down would require adding another directory (e.g. events) > to maintain a sane IA, and would make the urls look like: > > /apac/events/beijing/2011/02/01/seminar > /apac/events/beijing/2011/03/02/workshop If I was trying to give it a sane IA I wouldn't publish the calendar using a blog-history extension in the first place :) I do think there's an architectural flaw in the Archive extension: I would be inclined to interpolate the date string in the slug method (rather than in child_path) so that at validation we see the path that is actually used. This is very old code, though, carried forward mostly for compatibility reasons. I doubt that people will be keen to make fundamental changes, but I could well be wrong. The slug is a more monkeypatchable change so you might be able to do it from the outside just by overriding child_path and slug. It probably depends how much use you are making of ArchiveMonthPage and the like. > But this still doesn't solve the problem because as soon as we want to host > another seminar or workshop in Beijing, we're right back to square > one--Radiant is going to whine about duplicated slugs. The other obvious change is just to make your slugs different. beijing2 or beijing_june, say. You can still have 'Beijing' in page title and breadcrumb. ? best, will
Re: [Radiant] Unique slug constraint on children of ArchivePage
On 1 Feb 2011, at 14:13, D.Kreft wrote:
> I'm using an old version of Radiant (0.6.7) [1] but I think this behavior
> still exists in tip as well based upon what I see in github [2].
>
> My customer has a bunch of events in various cities across the world this
> year that they want to publish via our CMS. So the natural and most
> convenient thing to do is to put them under an ArchivePage so the URLs look
> like this:
>
> http://ourhost.ourdomain.com/events//MM/DD/city
I don't use the archive extension but my feeling here is that the logic in the
model is right and your url scheme is twisting things a bit out of shape. Any
reason not to use /events/city//MM/DD? Then the slug constraint would be
helping you as it's meant to. It may just be a case of creating a page for each
city.
And you're right that validations are very difficult to monkeypatch but I'm not
very keen on putting a special case in the Page model, nor on backporting it.
If you're prepared to upgrade then life will get a lot easier: most obviously
because you can use r:aggregate tags to combine the children of several pages,
eg by publishing an events archive for each city and combining them on a main
calendar page.
With an up to date installation you could also consider using the
event_calendar extension to provide proper calendar functionality. You can add
(my) event_map for googlemapping and taggable_events if you want to tag your
events by city (or any other scheme). See for example:
http://350.royalsociety.org/calendar/2010/june
http://350.royalsociety.org/map?month=7&year=2010
we built that last year (which is why the various extensions listed above all
exist) and you may well find it does what you need.
best,
will
>
> Where /MM/DD is the date that the event will be held.
>
> The problem with this, however, is that my customer is going to be hosting
> multiple events in the same city on different dates, e.g.:
>
> http://ourhost.ourdomain.com/events/2011/02/01/chicago
> http://ourhost.ourdomain.com/events/2011/03/15/chicago
>
> However, the uniqueness constraint in page.rb[2] makes this impossible, since
> it enforces a unique slug under the parent. This seems excessively and
> unnecessarily restrictive for an ArchivePage--the uniqueness constraint
> really should be on the URL, not the slug.
>
> I'm able to get around this problem by hacking page.rb to include the
> following:
>
> validates_uniqueness_of :slug, :scope => :parent_id, :message => 'slug
> already in use for child of parent', :if => Proc.new { |page|
> page.parent.class_name != 'ArchivePage' }
>
> validate :unique_slug_unless_parent_is_archive
>
> private:
>
> def unique_slug_unless_parent_is_archive
> return unless parent.class_name == 'ArchivePage'
>
> my_url = self.url
>
> match = Page.find_by_url(my_url)
>
> if match and match != self
> errors.add :class_name, "URL #{my_url} is not unique. Choose another
> slug."
> end
> end
>
> However, for hopefully obvious reasons, I don't want to hack the source
> directly--I'd rather monkey patch, but it doesn't look as if the change I
> made to the "validates_uniqueness_of" line above (in bold) is possible with a
> monkey patch.
>
> Is there any chance of making this an official change in Radiant? Are there
> any other solutions or problems with my hack that I'm overlooking?
>
> Thanks,
>
> -dan
>
> -- Footnotes
>
> [1] An upgrade is in the works, but I keep getting preempted by "more
> important stuff." :-\
> [2] https://github.com/radiant/radiant/blob/master/app/models/page.rb
>
Re: [Radiant] if home page
On 28 Jan 2011, at 17:29, trans wrote: > How to use radiant tags to say "if home page"? You mean, to test whether a page is the home page? ... By the way, in edge this has changed to: ... along with many other url/path clarifications. The old if_url notation will still work too. best, will
Re: [Radiant] Slow page load times
On 24 Jan 2011, at 07:29, Carl Youngblood wrote: > On Sun, Jan 23, 2011 at 8:50 PM, William Ross wrote: > From a brief look it seems that the rss-reader extension disables all page > caching. It does this in a rather inadvisable way (by amending the Page class > itself rather than defining a specialist subclass) but since your site is > primarily an RSS-aggregator, fixing that wouldn't help much. > > The extension is quite old and I expect the decision dates back to the old > radiant cache: with Rack::Cache in front of the whole thing it doesn't make > sense any more. Simply commenting out these lines in lib/rss_reader.rb: > > > def cache? > > > false > > > end > > > > should make a big difference. > > William, I just thought of something. We're running Radiant 0.8.0. Would this > affect your advice at all? No, that shouldn't make any difference. But the advice is more diagnostic than curative, if you see what I mean. There are lots of factors that could be slowing you down and that was only one. Here are some more diagnostics: 1. Make sure you don't force-reload the page. On a normal radiant installation I find that a hard refresh in firefox will always pass through the cache. It shouldn't: the cache is configured to ignore reload requests from the client, but for some reason they still work. Hitting refresh without any modifier keys will ignore the browser cache but should still allow you to test the server cache. 2. Reload the page (without forcing it) twice in quick succession and on the second attempt examine the response headers. The easy way to do that is to install Firebug and watch the 'Net' panel. If the cache is working you should get '304 Not Modified' for everything. If you get '200 OK' responses for the radiant page in that test then your site is not cached. 3. Have a quick look at the webserver configuration. If there are proxies or redirects involved, for example, it's easy to mangle cache headers. 4. Now you can be fairly sure that the problem is in a radiant extension. You will need to poke around in the console (in production mode on the live site) to find out more. Here are some values you could check: SiteController.cache_timeout(should be a duration, most likely 5.minutes) Radiant::Config['dev.host'] (make sure this isn't the same as your production host) Page.find_by_parent_id(nil).cache? (that's the home page. cached? should be true) That last will most likely return false, and you will need to track down why. best, will
Re: [Radiant] Error Creating New Page 0.91 ArgumentError (interning empty string):
On 24 Jan 2011, at 06:32, Cleverlemming wrote:
> Hail Caesars!
>
> I received a 500 Internal Server Error when trying to create a new
> page. Looking through the stack trace, the problem turned out to be
> that there was no default page.status set in Radiant::Config. I set it
> back to draft and all is well again.
>
> Maybe it makes sense to default to Draft in status.rb if no options
> are passed to the intialize method? I
As it happens, the next release will do exactly that as a side effect of the
new configuration interface.
Thanks for the message, though: very useful.
best,
will
>
> Hope this helps somebody.
>
> Peace,
> Pete
>
> Processing Admin::PagesController#new (for 184.100.170.199 at
> 2011-01-24 00:29:11) [GET]
> Parameters: {"page_class"=>"Page", "page_id"=>"1", "action"=>"new",
> "controller"=>"admin/pages"}
>
> ArgumentError (interning empty string):
> vendor/radiant/app/models/status.rb:14:in `intern'
> vendor/radiant/app/models/status.rb:14:in `[]'
> vendor/radiant/app/models/status.rb:14:in `each'
> vendor/radiant/app/models/status.rb:14:in `find'
> vendor/radiant/app/models/status.rb:14:in `[]'
> vendor/radiant/app/models/page.rb:274:in `new_with_defaults'
> /opt/ruby-enterprise/lib/ruby/gems/1.8/gems/will_paginate-2.3.15/lib/
> will_paginate/finder.rb:170:in `method_missing'
> vendor/radiant/app/controllers/admin/pages_controller.rb:21:in `new'
> compass (0.10.6) lib/compass/app_integration/rails/actionpack2/
> action_controller.rb:7:in `process'
> vendor/radiant/vendor/plugins/haml/rails/./lib/sass/plugin/rack.rb:
> 41:in `call'
> passenger (3.0.1) lib/phusion_passenger/rack/request_handler.rb:
> 96:in `process_request'
> passenger (3.0.1) lib/phusion_passenger/abstract_request_handler.rb:
> 513:in `accept_and_process_next_request'
> passenger (3.0.1) lib/phusion_passenger/abstract_request_handler.rb:
> 274:in `main_loop'
> passenger (3.0.1) lib/phusion_passenger/classic_rails/
> application_spawner.rb:321:in `start_request_handler'
Re: [Radiant] Slow page load times
On 23 Jan 2011, at 19:04, Carl Youngblood wrote: > Hello, we're running a Radiant installation and we're experiencing > very slow load times. Here's our site: > > http://transfigurism.org > > We're running it on a linode 512 vm. The site uses the > radiant_rss_reader extension to construct many different snippets. I > was wondering if this was the problem, but have checked the RSS cache > and verified that it is not retrieving the RSS feeds again if they've > been cached within the set interval (currently 1 hr). From a brief look it seems that the rss-reader extension disables all page caching. It does this in a rather inadvisable way (by amending the Page class itself rather than defining a specialist subclass) but since your site is primarily an RSS-aggregator, fixing that wouldn't help much. The extension is quite old and I expect the decision dates back to the old radiant cache: with Rack::Cache in front of the whole thing it doesn't make sense any more. Simply commenting out these lines in lib/rss_reader.rb: def cache? false end should make a big difference. best, will > > But it seems that whenever I initiate a refresh from the browser, > pages take about 30 seconds to load. Almost all of this time appears > to be spent in ruby. When I click refresh, the CPU load spikes to > about 60% for the duration of this 30s period and then at the end the > page appears suddenly, implying that bandwidth and browser rendering > are not the bottlenecks. > > When I click around in the site after going through these slow load > times for all the pages, they come up very suddenly, leading me to > believe that they are being served from the radiant cache at that > point. > > My first question is, is there a way to make it so that a browser > refresh does not cause the radiant cache to be invalidated? I would > like to set up an hourly cron job that spiders the web site to > basically "prime" the cache and make it so that real-world requests > are served up quickly from the cache instead of having to be re-parsed > and rendered by radiant. > > Second question is, why is my site taking so long for radiant to > render? It doesn't strike me as an especially complex layout? Is my > radiant process running out of memory or something? Any > recommendations on apache and/or db configurations that would help > here? > > Thanks, > Carl
Re: [Radiant] Conditional on URL Subdomain?
On 23 Jan 2011, at 02:30, Cleverlemming wrote: > Hail Caesars, > > I see how to use the conditionally based on URL, but what about subdomains in the base URL? > I have a site with several, like military.mysite.com and > oregon.mysite.com. I'd like the header image and a few other little > details to change, based on subdomain, but this doesn't warrant > creating separate sites as most of the content is shared. Do I need to > make a custom tag? Have a look at https://github.com/spanner/radiant-mobile-extension It's not quite what you're after but should point in the right direction. will
Re: [Radiant] Re: render_radiant
On 20 Jan 2011, at 21:38, swartz wrote: > I gave a very brief look at your extension. > I do not mean to devalue your contribution(in fact, thank you for it), > but isn't this what share_layout extension does? > https://github.com/radiant/radiant-share-layouts-extension > > Also check spanner's fork: > https://github.com/spanner/radiant-share-layouts-extension Ah, yes. That fork is a bit out of date now. I should delete it, really. The most recent work on layouts is Dirk's 'layouts' extension, which includes nested_layouts as well but doesn't show up very well in searches because it's a fork with a different name: https://github.com/squaretalent/radiant-layouts-extension The purpose of my fork was to add ActionMailer support, which is an ugly business but useful. That code has since moved to 'mailer_layouts': https://github.com/spanner/radiant-mailer_layouts-extension and I use it in the reader extensions to make the administrative email a bit nicer. best, will
Re: [Radiant] Crazy,crazy,You have never seen such perfect N*U*D*E ART
It was splendid, wasn't it? But it shouldn't have got through. Sorry about that. I've blocked the sender so there shouldn't be another. best, will On 18 Jan 2011, at 09:47, Arthur Gunn wrote: > wow, what a truly incredible spam specimen. >
Re: [Radiant] Strange trouble creating a custom tag…
On 13 Jan 2011, at 08:58, Marc wrote: > Hi, > > I've been experimenting with adding a custom tag to Page, which works > when I have: > > module UiTags > include Radiant::Taggable > > desc "Returns the server host name" > tag 'lsi:hostname' do |tag| >CGI.escapeHTML(request.host()) unless request.nil? > end > end > > but not: > > module UiTags > include Radiant::Taggable > > desc "Returns the server host name" > tag 'hostname' do |tag| >CGI.escapeHTML(request.host()) unless request.nil? > end > end > > I get an error 'lsi' tag not defined… Which is strange since other > extensions use the prefix:name form. Radiant 0.9.1 and Rails 2.3.8. Have you got those the right way round? Should be an easy fix, though. The error is literally correct, and you need to define a tag for the prefix too: desc "Custom namespace" tag 'lsi' do |tag| tag.expand end desc "Returns the server host name" tag 'lsi:hostname' do |tag| CGI.escapeHTML(request.host()) unless request.nil? end There may be useful work you can do to set context within the Isi tag, but note that when you call in that chained form the tag attributes are not passed through to the prefix tag. best, will
Re: [Radiant] Re: Looking for pointers: Access to request headers, intercept form submission early, etc...
On 10 Jan 2011, at 20:59, Marc wrote: > On Jan 10, 7:45 pm, William Ross wrote: >> Radius tags are implemented in the Page model, where you shouldn't have >> access to the request, but it also defines request and response accessors >> that are populated by the SiteController, so in a radius tag you can access >> the request directly. The solid way would be: >> >> referer = tag.globals.page.request.referer >> >> but since we're rendering inside Page it's usually ok just to say: >> >> referer = request.referer >> >> The biggest problem you'll find is that in order to display request-specific >> content you have to disable the page cache. If you just want to pick up >> googlers you might find it easier to do in javascript. > > I was planning on using it to jazz up the file not found response, > i.e. differentiate internal link error from external reference miss. I > get the impression that it already disables the page cache for its > responses. Yes, it does. There's already an tag too (in app/models/file_not_found_page.rb). It should be easy to add more. best, will
Re: [Radiant] Looking for pointers: Access to request headers, intercept form submission early, etc...
On 10 Jan 2011, at 07:10, Marc wrote: > Hi, > > I seem to remember from somewhere that radius tags can't get access to > session state, e.g. HTTP Headers. Specifically "Referer"? Is that > correct? Just about to start digging into rails and would be nice to > get hints where to look... No, it's quite possible but can be slightly awkward in use. Radius tags are implemented in the Page model, where you shouldn't have access to the request, but it also defines request and response accessors that are populated by the SiteController, so in a radius tag you can access the request directly. The solid way would be: referer = tag.globals.page.request.referer but since we're rendering inside Page it's usually ok just to say: referer = request.referer The biggest problem you'll find is that in order to display request-specific content you have to disable the page cache. If you just want to pick up googlers you might find it easier to do in javascript. > Also I'm was wondering if someone can provide pointers to how I can > get at the form post before it is interpreted. I was looking at > modifying the mailer extension to use obscured field names (part of > getting http://nedbatchelder.com/text/stopbots.html techniques > working). I have an old fork of the Mailer that implements a honeypot mechanism quite similar to what's described there but I think a bit less sophisticated. It may show you where to start: https://github.com/spanner/radiant-mailer-extension best, will
Re: [Radiant] Pagination within Aggregate Tag
On 21 Dec 2010, at 03:21, Keith Hanson wrote: > Hi All! > > I think my problem is fairly simple, but I'm finding that the > paginated="true" attribute does absolutely nothing in this context: > > http://pastie.org/1393524 You're right. The nesting of the tags there means that you're actually calling aggregate:each:children:each and I missed that one when fitting the pagination. Would you mind filing an issue? I think it just needs drying out but I'd better check why the author didn't just call children:each in the first place. thanks, will
Re: [Radiant] Good example of an "application endpoint" (RailsPage)
On 20 Dec 2010, at 22:03, Wes Gamble wrote:
> I was reading through this post on Shared Layouts
> (http://www.ruby-forum.com/topic/158686),
>
> and came across the explanation of the "Application" page type.
That was a while ago and what Sean was referring to is now just called a
RailsPage. Still not a very good name but share_layouts is a very useful tool.
Essentially, it undoes the twist that radiant has applied to the normal rails
MVC. In radiant the Page model class acts like a controller, the page content
acts like a view template and the layout content acts as a layout template.
There are no real view templates (outside admin) and the SiteController is just
a page-picker: rendering is delegated to the requested page. You can add more
public-facing controllers and views, but they exist in the normal rails world,
cut off from the rendering of radiant content.
Share_layouts fixes that by letting your normal rails controller wrap radiant
layouts around view-rendered content, and by letting your views define
pseudo-page-parts for use in those layouts.
Here's a rough hello world:
# in app/controllers/greetings_controller.rb
class GreetingsController < ApplicationController
radiant_layout "standard"
def index
@greeting = "Hello World"
end
end
# in views/greetings/index.html.haml:
%p
The :main page part is populated for you.
- content_for :title do
%h1
= @greeting
- content_for :introduction do
%p
This is the intro.
# in the "standard" layout:
The output from this, given a route to GreetingsController#index, will be:
Hello World
This is the intro.
The :main page part is created automatically.
As you see, the overall rendering of the view template is captured as a :main
page page part, and any other page part you want to bring into the template can
be declared with a content_for block. Title, :breadcrumbs and I think :slug are
treated specially.
If you don't want to hard-code the name of your radiant layout in the
controller, you can supply a block that optionally takes the controller as
argument:
radiant_layout { Radiant::Config['configured.layout'] }
or
radiant_layout { |controller| controller.choose_layout }
def choose_layout
# here all the usual request machinery is available
# include current_user and current_site, if relevant
end
Note that the block must return the name of a layout, not the layout itself.
You may also be interested in Dirk's amalgamation of this and nested_layouts
into a single layouts extension or my mailer_layouts which lets you build email
messages the same way.
best,
will
Re: [Radiant] Re: Duplicate 'slug' and 'breadcrumb' fields after adding page_fields extension
On 18 Dec 2010, at 19:00, Joshua Danger French wrote: > On Dec 17, 2010, at 10:52 PM, Todd wrote: >> Do you think edge is stable enough for me to get by for a while? I >> know edge is, by definition, not "stable," but I would really like to >> have the PageFields functionality (without my site going down in >> flames). > > Edge has been baking for a while and I know others are using it. As far as I > know all the outstanding issues are enhancements, which should mean there are > no *known* bugs. I think the last feature added was Spanner's config work, so > he's probably the current authority on whether edge is stable or not... > personally, I'm comfortable with it. I've been using it in public without problems and it tests clean. The next things that happen - as far as I know - are more fundamental so what you get at the moment is probably as stable as it will be for a while. will
Re: [Radiant] Event Calendar extension - ERROR: relation "taggings" does not exist
Stoyan, You need 'taggable' too. 'taggable_events' is just a bit of glue to apply it to the calendar. Best, Will Pardon brevity: small phone, fat thumbs. On 17 Dec 2010, at 23:08, SS wrote: > Hi, > > I've been looking for the right extension/gem that will fix this error > message that I keep getting when creating a new Calendar using the > Event Calendar extension: > > > Admin::CalendarsController#create (ActiveRecord::StatementInvalid) > "PGError: ERROR: relation \"taggings\" does not exist\n: SELECT > a.attname, format_type(a.atttypid, a.atttypmod), d.adsrc, a.attnotnull > \n FROM pg_attribute a LEFT > > > Here are all the extensions I've installed in Radiant: > > event_calendar > taggable_events > > > I thought all I needed were those two extensions. Do I need another > Rails gem? Any suggestions on what to install or configure? > > > Thanks, > S
Re: [Radiant] Spanner Paperclipped Fork
On 15 Dec 2010, at 16:58, bradley.t.her...@gmail.com wrote: > I'm trying to install the paperclipped fork from Spanner (which > searching around I found may be necessary for the Library extension) > but whenever I run I get the following error > > rake aborted! > Object is not missing constant Asset! That's a generic failure-to-load error. I don't know why it's happening, though. I have that combination in use in many places. Which version of radiant and what rake task are you trying to run? It's very likely that the forked paperclipped requires edge radiant, btw. will
Re: [Radiant] Partials access to local objects
On 13 Dec 2010, at 19:05, bradley.t.her...@gmail.com wrote: > I'm writing an extension to add a new feature to the "taggable" > extension and I need to do something very simple: add a new column to > the taggable index page. This is pretty simple: > > admin.tag.index.add :thead, "add_required_header", :after => > "modify_header" > admin.tag.index.add :tbody, "add_required_cell", :after => > "modify_cell" > > However, in my partial, I need to reference the tag object from > index.html.haml: > > - for tag in @tags >%tr.node.level-1 > - render_region :tbody do |tbody| >. >. >. >/ Partial code should be inserted here >/ - tbody.required_cell do >/ - if tag.required >/ Required > > However, the "tag" object is not available within the partial. Is > there any way I can get access to that when I'm adding code via > partials? No. It's a weakness of the otherwise very cunning shards mechanism that there is no way for it to get at local variables. Taggable could help, perhaps by including an empty partial (_other_columns.html.haml?) with some locals or by setting a @current_tag variable within the index-page loop. Neither approach is very pleasing, but it will take a while to arrive at a better solution that is also simple enough to live with. I need to clear up that index page anyway (as you can see from the 'node.level-1'). Would anyone like to suggest a best practice here? will
Re: [Radiant] Page saving error
On 13 Dec 2010, at 09:01, rcz wrote: > In Radiant CMS when I'm trying to save any page that has any PageType > but "normal" (Archive, Index,etc.) I get this error: > > NoMethodError in Admin/pagesController#update > > undefined method `[]' for nil:NilClass > > With clean Radiant everything's work, my radiant carried with some > extension, which may cause problem. Can anyone give me any clue how > can I solve this problem? Thanks. It is an extension problem. It should be easy to find and you can probably eliminate it by changing the order in which the extensions load. I think one of your extensions is calling Page.accepts_nested_attributes(:something) too late. Some Page subclasses have already been created, and they don't get the call. When you try to save a page with one of those classes (ArchivePage, etc) it doesn't know what to do with the nested attributes in the form. The error you see is due to an absence of nested_attributes_options. First you need to work out which of your extensions is responsible. There are two ways to do that: either add some debugging lines to vendor/radiant/vendor/rails/ activerecord/lib/active_record/nested_attributes.rb or (more easily), search through all the files in vendor/extensions looking for the string accepts_nested_attributes and see what stands out. Then you need to make sure that troublesome extension loads before there is any inheritance from Page. To do that you uncomment this line in config/environment.rb: # config.extensions = [ :all ] and prepend the name of your extension: config.extensions = [:something, :all] > ps. I apologize for my poor English. Your English seems excellent to me. Please do say if anything here is unclear. best, will > > stack trace: > > NoMethodError in Admin/pagesController#update > > undefined method `[]' for nil:NilClass > > RAILS_ROOT: F:/Work/Rails/Radiant/dev_version/test_app > Application Trace | Framework Trace | Full Trace > > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > activerecord/lib/active_record/nested_attributes.rb:335:in > `assign_nested_attributes_for_collection_association' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > activerecord/lib/active_record/nested_attributes.rb:244:in > `fields_attributes=' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > activerecord/lib/active_record/base.rb:2906:in `send' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > activerecord/lib/active_record/base.rb:2906:in `assign_attributes' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > activerecord/lib/active_record/base.rb:2902:in `each' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > activerecord/lib/active_record/base.rb:2902:in `assign_attributes' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > activerecord/lib/active_record/base.rb:2775:in `attributes=' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > activerecord/lib/active_record/base.rb:2669:in `update_attributes!' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/app/ > controllers/admin/resource_controller.rb:64:in `update' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > actionpack/lib/action_controller/base.rb:1331:in `send' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > actionpack/lib/action_controller/base.rb:1331:in > `perform_action_without_filters' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > actionpack/lib/action_controller/filters.rb:617:in `call_filters' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > actionpack/lib/action_controller/filters.rb:638:in > `run_before_filters' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > actionpack/lib/action_controller/filters.rb:189:in `call' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > actionpack/lib/action_controller/filters.rb:189:in `call' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > actionpack/lib/action_controller/filters.rb:635:in > `run_before_filters' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > actionpack/lib/action_controller/filters.rb:615:in `call_filters' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > actionpack/lib/action_controller/filters.rb:610:in > `perform_action_without_benchmark' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > actionpack/lib/action_controller/benchmarking.rb:68:in > `perform_action_without_rescue' > F:/Work/Rails/Radiant/dev_version/test_app/vendor/radiant/vendor/rails/ > activesupport/lib/active_support/core_ext/benchmark.rb:17:in `ms' > F:/Work/Ruby187/p302/lib/ruby/1.8/benchmark.rb:308:in `realtime' > F:/Work/Rails/Radiant/dev
Re: [Radiant] Textile (and other) filters have no effect - still see straight html
On 10 Dec 2010, at 15:56, lmorris99 wrote: > New install of Radiant here, 0.9.1; > extensions show Textile 1.0 (and other filters too of course). > > My problem is: > I edit a page, and change the Filter from to Textile, click > Save changes; > then I edit the page again, and I still see straight html. > > Textile is a wysiwyg editor, right? So I should not be seeing html, > right? No, that's all as it should be. There are extensions that will give you that sort of translated view - last time I needed one, tinypaper[1] looked best - but the textile and markdown filters don't work that way. They allow you to use different kinds of shorthand [2] in order to simplify what you have to type and edit, but they don't interpret it for you as you go along. It can be difficult to persuade word processor users of the benefits of textile or markdown, but if you're used to code you'll probably find it very pleasing. Give yourself a chance to get used to it before you go back to wysinwyg. best, will [1] http://ext.radiantcms.org/extensions/178-tiny-paper [2] http://redcloth.org/textile and http://daringfireball.net/projects/markdown/
Re: [Radiant] Programmatically creating pages
On 9 Dec 2010, at 16:13, Neil wrote: > In reference to my previous post - as I'm importing content into Radiant from > Wordpress, how do I go about setting the created_by to a user? Every time I > set the value, it's always NULL that ends up in the table (although > updated_by is working just fine) > > Is there a hook in the code that I haven't spotted that's doing this? Yes, probably. UserActionObserver sets created_by in a before_create filter that isn't visible from the Page class itself. In the console or a rake task there is no current user, so it nulls any existing association. Are you scripting the import? In that case you just need to set UserActionObserver.current_user to a user object before you create the pages. If you're assigning a different user to each page, the easiest way is just to do it in another operation after creation. And re: > The /blog part I can deal with, but the day is causing me issues. Is > there any way I can get Radiant to work without the day part in the > route? I don't use the archive extension - which is responsible for your urls here - but looking at the code, the url format will be quite hard to change. It's spelt out in several places and used to support the day/month/year views. Perhaps an easier option would be to print the old and new paths as the posts are imported and use that output to create many specific rewrite rules rather than one general one? best, will
Re: [Radiant] image 404s
On 2 Dec 2010, at 00:25, rosslaird wrote: > I have just started using Radiant (which is just great, by the way), > so apologies in advance for what may be a very simple question: the > server log shows various 404s to image files: button.png and new- > snippet.png are two examples. My setup is on locahost, for testing, so > the 404 refers to (for example) this url: > http://localhost/images/admin/button.png. Both of those are files used by older versions of the admin interface. The most likely explanation is that one of your extensions is not up to date: being contemporary with an older version of radiant it is assuming the presence of files that don't exist any more. Radiant's helper methods mean that the author probably didn't need to spell out the image path, but something like this (in your radiant instance directory) should show you where it's coming from: grep -r 'new-snippet' . I don't get any matches from a normal radiant site except in old log files. best, will > There are quite a few image files in /images/admin, but not > button.png. On the other hand, there is a new-snippet.png in the > images/admin directory, but I still get a 404 for that file as well. > These image files are not ones that I have created, so I'm not sure > what's going on. I do have some extensions installed (Chronicle, blog, > mailer, paperclipped, settings) and I don't know if these are a > factor. I have combed through all the css files I can find, and > nothing seems to point to these missing files. > > Suggestions? > > Thanks in advance. > > Ross Laird
Re: [Radiant] Library and PaperClipped
On 10 Nov 2010, at 13:45, William Ross wrote: > On 10 Nov 2010, at 13:31, Jim Gay wrote: > >> On Mon, Nov 8, 2010 at 9:45 AM, Anthony Bouch >> wrote: >>> Have been trying to get a gallery to work with Radiant. >>> >>> I've tried the 'Galleries' extension - but could see no way to add >>> images from the asset list to the gallery. >>> >>> Am also now looking at the Library extension and their fork of >>> Paperclipped - but after trying to run the rake development >>> db:migrate:extensions task - I'm now getting an error which says.. >>> >>> undefined method `is_taggable' for # >>> > > Ah sorry. That's my fault, I think. The library relies a variant of paperclip > that I've been meaning for months to pull into the mainstream: > > https://github.com/spanner/paperclipped > > However, in this case I think the problem is a missing 'taggable' extension: > > https://github.com/spanner/radiant-taggable-extension ... or possibly just load order. Taggable and paperclipped have to load before the library extension does. will
Re: [Radiant] Library and PaperClipped
On 10 Nov 2010, at 13:31, Jim Gay wrote: > On Mon, Nov 8, 2010 at 9:45 AM, Anthony Bouch wrote: >> Have been trying to get a gallery to work with Radiant. >> >> I've tried the 'Galleries' extension - but could see no way to add >> images from the asset list to the gallery. >> >> Am also now looking at the Library extension and their fork of >> Paperclipped - but after trying to run the rake development >> db:migrate:extensions task - I'm now getting an error which says.. >> >> undefined method `is_taggable' for # >> >> ..nor can I start the webserver. >> >> Any ideas? Help? >> >> Tony > > I haven't tried, but you could run the task with "--trace" > rake db:migrate:extensions --trace > > That will show you the stack trace and you can look for an error > coming from one of your extensions. It will tell you the line number > where the error occurs. > > Also, you should be more specific here. You said that you are looking > at the Library extension "and their fork" of Paperclipped. > Pointing us to a specific repository would be helpful. Ah sorry. That's my fault, I think. The library relies a variant of paperclip that I've been meaning for months to pull into the mainstream: https://github.com/spanner/paperclipped However, in this case I think the problem is a missing 'taggable' extension: https://github.com/spanner/radiant-taggable-extension I've updated all these extensions to take out the (deprecated) config.extension hooks but right now that means dependencies aren't properly caught and it's easy to miss something. Sorry about the hassle: everything will work when we standardise on gems but until then it's a bit in-between. (You could try installing all this from gems, but there are complications there too because at the moment most of my extensions are waiting in beta versions for the configuration interface to make it into radiant. The gems currently available are the beta versions and not compatible with radiant 0.9.1, or indeed with radiant edge. You would need the 'preconfiguration' branch.) As it happens I've just been updating an image gallery that uses exactly this combination: http://lordmayorshow.org/library/history/ So if there's anything I can do to help, do let me know. best, will
Re: [Radiant] Application error when Loggin into admin area
On 5 Nov 2010, at 04:00, Obi wrote:
> Ah, yes I remember being told to rake something in a set of instructions,
> every-time I do though I get this message (hadn't realized the rake was so
> important so I just skipped it, oops):
>
> rake aborted!
> No Rakefile found (looking for: rakefile, Rakefile, rakefile.rb, Rakefile.rb)
> /usr/lib/ruby/gems/1.8/gems/rake-0.8.7/lib/rake.rb:2377:in `raw_load_rakefile'
> (See full trace by running task with --trace)
>
> what could this mean? I'm pretty sure I already have rake installed
Hello Obi,
Are you running rake from the root of your radiant application? Rake is
installed globally but the tasks are defined locally, so the normal sequence
would be like this:
radiant /path/to/website
cd /path/to/website
rake db:migrate
... install some extensions, do something else...
cd /path/to/website
rake db:migrate:extensions
It must have worked once or your database wouldn't be there at all.
best,
will
>
>> You get specific details right here.
>> It tells you the error (ActionView::TemplateError)
>> Then it tells you where
>> on line #1 of
>> vendor/extensions/stereotype/app/views/admin/_stereotype_td.html.haml:
>> And then shows you the actual code from that line
>> 1: - stereotype = page.custom_fields.find(:first, :conditions =>
>> ["name = ?", "stereotype"])
>
> - Okay, so your saying it's the stereotype extension causing this problem.
>
> I guess the solution will either be figuring out how to do the rake or
> figuring out how to uninstall the extension. For now it's probably better
> that I figure the rake out.
>
> Any idea what causes the rake to abort?
>
> Cheers
>
> On 05/11/2010, at 00:51, Jim Gay wrote:
>
>> You got it!
>> It's telling you that the application is looking in the database for a
>> table that isn't there:
>>
>> ActionView::TemplateError (PGError: ERROR: relation "custom_fields"
>> does not exist
>>
>> Do you need to migrate the database?
>>
>> rake db:migrate:extensions
>>
>> On Thu, Nov 4, 2010 at 11:45 PM, Obi wrote:
>>> ah, I see...
>>>
>>> Could this section be the problem? Or should I look further up?
>>>
>>> Rendering /var/www/orgnot/public/500.html (500 Internal Server Error)
>>>
>>>
>>> Processing Admin::PagesController#index (for 98.143.144.89 at 2010-11-05
>>> 03:16:47) [GET]
>>> Parameters: {"action"=>"index", "controller"=>"admin/pages"}
>>> Rendering template within layouts/application
>>> Rendering admin/pages/index
>>>
>>> ActionView::TemplateError (PGError: ERROR: relation "custom_fields" does
>>> not exist
>>> LINE 1: SELECT * FROM "custom_fields" WHERE ("custom_fields".page_id...
>>> ^
>>> : SELECT * FROM "custom_fields" WHERE ("custom_fields".page_id = 1 AND
>>> (name = 'stereotype')) LIMIT 1) on line #1 of
>>> vendor/extensions/stereotype/app/views/admin/_stereotype_td.html.haml:
>>> 1: - stereotype = page.custom_fields.find(:first, :conditions => ["name =
>>> ?", "stereotype"])
>>> 2: %td.published_status.status
>>> 3: = stereotype.value if stereotype
>>>
>>>
>>> vendor/extensions/stereotype/app/views/admin/_stereotype_td.html.haml:1:in
>>> `_run_haml_vendor47extensions47stereotype47app47views47admin47_stereotype_td46html46haml_locals_defaults_level_object_page_simple_stereotype_td'
>>> radiant (0.9.1)
>>> vendor/plugins/haml/rails/./lib/haml/helpers/action_view_mods.rb:11:in
>>> `render'
>>> radiant (0.9.1) vendor/plugins/haml/rails/./lib/haml/helpers.rb:90:in
>>> `non_haml'
>>> radiant (0.9.1)
>>> vendor/plugins/haml/rails/./lib/haml/helpers/action_view_mods.rb:11:in
>>> `render'
>>> radiant (0.9.1) app/helpers/admin/regions_helper.rb:11:in `render_region'
>>> radiant (0.9.1) app/helpers/admin/regions_helper.rb:9:in `map'
>>> radiant (0.9.1) app/helpers/admin/regions_helper.rb:9:in `render_region'
>>> radiant (0.9.1) app/views/admin/pages/_node.html.haml:2:in
>>> `_run_haml_47usr47lib47ruby47gems47146847gems47radiant45046946147app47views47admin47pages47_node46html46haml_locals_level_node_object_page_simple'
>>> radiant (0.9.1)
>>> vendor/plugins/haml/rails/./lib/haml/helpers/action_view_mods.rb:11:in
>>> `render'
>>> radiant (0.9.1) vendor/plugins/haml/rails/./lib/haml/helpers.rb:90:in
>>> `non_haml'
>>> radiant (0.9.1)
>>> vendor/plugins/haml/rails/./lib/haml/helpers/action_view_mods.rb:11:in
>>> `render'
>>> radiant (0.9.1) app/helpers/admin/node_helper.rb:6:in `render_node'
>>> radiant (0.9.1) app/views/admin/pages/index.html.haml:17:in
>>> `_run_haml_47usr47lib47ruby47gems47146847gems47radiant45046946147app47views47admin47pages47index46html46haml'
>>> radiant (0.9.1)
>>> vendor/plugins/haml/rails/./lib/haml/helpers/action_view_mods.rb:13:in
>>> `render'
>>> radiant (0.9.1)
>>> vendor/plugins/haml/rails/./lib/haml/helpers/action_view_mods.rb:13:in
>>> `render'
>>> radiant (0.9.1) lib/radiant/resource_responses.rb:18:in `response_for'
>>> radiant (0.9.1) app/controllers/
Re: [Radiant] Recent Spam and Request for Moderators
I can help with that. Let me know what you need, if you still do. will On 29 Oct 2010, at 20:49, Jim Gay wrote: > We recently had a few spam messages come through to the list. I'm both > very sorry and very annoyed about that. > I've banned the offending members, but I'd love to get more assistance > with the list management. > > We have a few moderators but I'm looking for a few more to step up and > help out. Please reply of you'll have time once or twice a month to > moderate the messages that come in from new members or squash the spam > that makes it through from existing members. > > Thanks! > > -- > Jim Gay > Saturn Flyer LLC > http://www.saturnflyer.com > 571-403-0338
Re: [Radiant] Best way to protect pages with custom auth-system?
On 29 Oct 2010, at 04:35, Jim Gay wrote: > On Sat, Oct 16, 2010 at 3:08 PM, swartz wrote: >> I have a custom auth-system based on authlogic (based largely on >> reader extension). >> I have two roles: regular users and moderators. >> I also have two extra pages types, one is for moderators only, the >> other is for either. >> >> Whats would be recommended way to require certain user role to access >> a particular page type? >> Should I define a custom process() method for each page or is there a >> better way? reader_group does something similar by overriding find_page and show_page in site_controller, but I looking at it now I probably should just have chained Page#find_by_url and defined some new exception types for the controller to catch. best, will
Re: [Radiant] Stacktrace when using taggable_events in Radiant 0.9.1 - Undefined method `attached_tags'
On 27 Oct 2010, at 06:05, Jim Gay wrote: On Wed, Oct 27, 2010 at 1:00 AM, john muhl wrote: On Tue, Oct 26, 2010 at 2:02 PM, SS wrote: Hi, Does anyone know why I'm getting this stacktrace when I try to add a new Event in my Radiant project? Am I missing another extension/plugin that is not mentioned in the documentation for taggable_events extension? i don't have any first hand experience but a quick poke around the repo it looks like you need at least event_calendar. do you have that installed properly? Nor I, but it sounds like you might not have migrated taggable_events if you are getting "undefined method `attached_tags' " Taggable_events is a tiny bit of glue, and not very well documented. Sorry! Doesn't do much, you see, except to connect these two: * taggable extension: http://github.com/spanner/radiant-taggable-extension * event_calendar extension: http://github.com/radiant/radiant-event-calendar-extension The attached_tags association is defined by taggable (pages already have a tags method) so I suspect you're missing that. I'll make the instructions better. best, will ps. I haven't seen your original messages with the trace yet, but it does sound we're missing a friendly 'uninstalled extension' signal now that they all expect to be installed as gems.
Re: [Radiant] Need help with Compass configuration for Radiant
On 25 Oct 2010, at 20:20, Wes Gamble wrote: > I'm not on edge. Still doesn't work for me. > > I was already putting @import compass/css3/border-radius at the top of my > sheet. Taking away the "border-radius" doesn't change the outcome, as you > would expect. I didn't say it would. I said the rest of your changes were unnecessary, but I didn't realise you were still running SNS. Sorry. In that case, you need to change the sns_sass_filter so that it passes through the compass configuration. This is probably the right way: def filter(text) begin Sass::Engine.new(text, Compass.sass_engine_options).render rescue ... end end and you do need the initializer. best, will > > I am still not successfully pulling in the compass mixins at all. > > Does anyone know if there was anything besides the compass initializer that > was added to support Compass in Radiant? > > Thanks, > Wes > > On 10/25/10 2:00 PM, William Ross wrote: >> You shouldn't need any special measures. Have you tried just putting >> >> @import compass/css3 >> >> At the top of one of your sheets? On edge that should just work. >> >> Best, >> >> Will >> >> >> >> Please excuse speling. Fat thumbs. >> >> On 25 Oct 2010, at 18:51, Wes Gamble wrote: >> >>> Radiant 0.9.1 (vendor'ed) >>> SNS extension >>> >>> I'd like to take advantage of various Compass Sass features within my >>> Radiant layouts (e.g. border-radius, etc.). >>> >>> Compass initialization file: >>> >>> I pulled down the radiant/config/initializers/compass.rb file from Github >>> and placed it into vendor/radiant/config/initializers >>> require 'compass' >>> require 'compass/app_integration/rails' >>> Compass::AppIntegration::Rails.initialize! >>> Compass configuration file: >>> >>> I took a compass.rb from another (non-Radiant) project and placed it in >>> vendor/radiant/config. I changed the paths based on my current settings >>> for the SNS extension: >>> # This configuration file works with both the Compass command line tool and >>> within Rails. >>> >>> # Require any additional compass plugins here. >>> >>> project_type = :rails >>> project_path = Compass::AppIntegration::Rails.root >>> >>> # Set this to the root of your project when deployed: >>> http_path = "/" >>> css_dir = "css" >>> http_stylesheets_path = "/stylesheets" >>> sass_dir = "stylesheets/sass" >>> images_dir = "public/images" >>> http_images_path = "/images" >>> javascripts_dir = "public/javascripts" >>> http_javascripts_path = "/javascripts" >>> environment = Compass::AppIntegration::Rails.env >>> # To enable relative paths to assets via compass helper functions. >>> Uncomment: >>> # relative_assets = true >>> I @import compass/css3/border-radius in my Radiant-managed CSS (Sass) file, >>> but cannot use the "+border-radius" mixin within my CSS. >>> >>> What am I doing wrong? >>> >>> Many thanks, >>> Wes Gamble >>> >>>
Re: [Radiant] Need help with Compass configuration for Radiant
You shouldn't need any special measures. Have you tried just putting @import compass/css3 At the top of one of your sheets? On edge that should just work. Best, Will Please excuse speling. Fat thumbs. On 25 Oct 2010, at 18:51, Wes Gamble wrote: > Radiant 0.9.1 (vendor'ed) > SNS extension > > I'd like to take advantage of various Compass Sass features within my Radiant > layouts (e.g. border-radius, etc.). > > Compass initialization file: > > I pulled down the radiant/config/initializers/compass.rb file from Github and > placed it into vendor/radiant/config/initializers > require 'compass' > require 'compass/app_integration/rails' > Compass::AppIntegration::Rails.initialize! > Compass configuration file: > > I took a compass.rb from another (non-Radiant) project and placed it in > vendor/radiant/config. I changed the paths based on my current settings for > the SNS extension: > # This configuration file works with both the Compass command line tool and > within Rails. > > # Require any additional compass plugins here. > > project_type = :rails > project_path = Compass::AppIntegration::Rails.root > > # Set this to the root of your project when deployed: > http_path = "/" > css_dir = "css" > http_stylesheets_path = "/stylesheets" > sass_dir = "stylesheets/sass" > images_dir = "public/images" > http_images_path = "/images" > javascripts_dir = "public/javascripts" > http_javascripts_path = "/javascripts" > environment = Compass::AppIntegration::Rails.env > # To enable relative paths to assets via compass helper functions. Uncomment: > # relative_assets = true > I @import compass/css3/border-radius in my Radiant-managed CSS (Sass) file, > but cannot use the "+border-radius" mixin within my CSS. > > What am I doing wrong? > > Many thanks, > Wes Gamble > >
Re: [Radiant] Please remove both addresses from this group
Heather, As far as I know you will have to remove yourself, but it's very easily done. Instructions are here: http://groups.google.co.uk/support/bin/answer.py?hl=en-uk&answer=46608 best, will On 18 Oct 2010, at 15:52, Heather Calderon wrote: > hcalde...@texasstampede.org > heathercaldero...@gmail.com > > thank you, > > > > Heather Calderon > Texas Stampede > (214) 520-8874 > >
Re: [Radiant] how to integrate with Google Map
On 14 Oct 2010, at 08:59, sawangpong wrote: > How to integrate with google map.? That depends what you want to display on the map. Have a look at the event_map extension for one example: http://ext.radiantcms.org/extensions/244-event-map http://github.com/spanner/radiant-event_map-extension There the event data already exists and the work is done by a controller that returns javascript defining a pointer and label for each location. There is also a dedicated google_maps extension: http://ext.radiantcms.org/extensions/98-google-maps which allows you to create maps by hand in the admin interface. I don't think it's up to date for radiant 0.9 or google maps v3, but it shouldn't be hard to make it work. best, will
Re: [Radiant] Using devise (or some other authentication/authorization framework) as a log in solution for Radiant end-users
On 5 Oct 2010, at 19:04, Jim Gay wrote: >> or >> b) using something else and challenges faced by using that something else >> alongside Radiant. >> >> Many thanks, >> Wes > > We will eventually pull out the editor auth stuff and make it > configurable too, but check out the extension registry to see how > other extensions do it (some piggyback the user model which you should > avoid) > http://ext.radiantcms.org/extensions/155-reader I'm busy with reader at the moment so it's worth looking at the beta branch[1], but the changes are mostly limited to the admin and messaging interfaces. When the radiant login framework changes I'll follow it, so framework changes are unlikely until then. For now it's a fairly straightforward and user-friendly authlogic implementation and the only strange glue is to make admin users able to act as readers without any extra maintenance. None of the reader extensions (group-based access, forum, downloads, etc) are internationalized yet, though some of that work has kindly been done for me and will appear soon. It should make local configuration a bit more straightforward too. > http://ext.radiantcms.org/extensions/122-members > http://ext.radiantcms.org/extensions/179-member > http://ext.radiantcms.org/extensions/12-ba The people working on the shop extensions have put a lot of thought into handling visitor accounts too. Not sure where you'd find that yet. best, will [1] http://github.com/spanner/radiant-reader-extension/tree/beta
Re: [Radiant] Upgrading: 0.6.7 -> 0.9.1
On 23 Sep 2010, at 22:47, D.Kreft wrote: > But isn't it a bit "bad" (to put it mildly) that running the migrate rake > tasks would drop all of my tables? That's not much of a "migration"--it's > more like a hostile takeover. I'm reminded that a few months back I did an > upgrade from 0.6.7 to 0.8.1 (that work has been lost, unfortunately) and I > didn't have this data loss problem. It certainly shouldn't do that. Are you sure you didn't run bootstrap? will
Re: [Radiant] Upgrading: 0.6.7 -> 0.9.1
On 23 Sep 2010, at 21:55, john muhl wrote: > On Thu, Sep 23, 2010 at 3:17 PM, D.Kreft wrote: >> I'm attempting to upgrade Radiant from 0.6.7 to 0.9.1 and it's proving to be >> quite a pain. > > i prefer to upgrade one version at a time. so in your case i'd first > go to 0.6.9, then 0.7.1, 0.8.1 and finally 0.9.1 ... which isn't quite as bad as it sounds. There are tags in the repository for every version from 0.6.8 onwards, so it's just a case of doing: git checkout 0.6.8 rake db:migrate a few times. You can skip some of the minor updates, as John suggests. The update task on the other hand is not incremental: all it does is copy over the current set of files (and latterly this involves backing up and replacing your configuration files, so running it more than once can be destructive). With any luck you can step through all the migrations and then run rake radiant:update once at the end. If your installation is more complicated, it's likely that you'll run into problems with extension compatibility across major version changes. In that case your best bet is probably to strip it down to radiant core and a few essentials, update as above and then have a look at what's available now. best, will
Re: [Radiant] Issue with 0.9.1 and events_calendar
On 22 Sep 2010, at 02:19, wprater wrote: > After an upgrade to 0.9.1, an old copy of events_calendar is no longer > working. We're not able to upgrade the extension at this time. The > exception being thrown is the following: > > = > "can't convert Array into String", but there does not seem to be an > array being passed in, it's just a Time object > = Please could you post the stack trace? will
Re: [Radiant] textile_editor extension
On 10 Sep 2010, at 06:39, Steven Southard wrote: > On Sep 9, 2010, at 5:16 PM, Steven Southard wrote: > >> Does anyone have a working 9.1 version of this extension? > > > Who knows what it would take to update the 8.1 version? I was noticing that > someone had started another extension that seemed like it did mostly the same > thing. Is this a new start because there was something difficult about > continuing with textile_editor? It was nice but I always wish in integrated > with assets better. I had a version here http://github.com/spanner/radiant-textile_editor-extension for 0.8.1 that would pop up the asset list and let you choose a size, but I never got round to adding inline uploads and it never really felt like a very satisfactory solution. will
Re: [Radiant] Problem with Redcloth after Dreamhost upgrade.
On 29 Aug 2010, at 19:01, Anton J Aylward wrote: > See http://www.systemI.ca for the output. > > Well ... this is the story. > > I've had a number of Radiant app running on Dreamhost. > All was well. > Then they upgraded me to a 64-bit machine. > This broke all the local compiled gems in ~/.gems/ > > So I deleted, reloaded and recompiled. > As you can see from the error message, this still doesn't work. > Dreamhost don't support Radiant/RoR and just advised me to recompile. > > Well I did recompile: Please could you show us the output you get from # gem environment This looks like a linking sort of problem. thanks, will
Re: [Radiant] Customizing the user admin UI at the column level
On 13 Aug 2010, at 05:01, Wes Gamble wrote:
> On 8/12/10 6:47 PM, William Ross wrote:
>>
>> On 13 Aug 2010, at 00:35, Wes Gamble wrote:
>>>
>>> After looking into it, though, I see the admin/users/edit and
>>> admin/users/index views under the Radiant core are more or less hard-coded
>>> at the column level, but the error messages imply that I should be able to
>>> add a partial somewhere for my custom fields.
>>>
>>> Questions:
>>>
>>> What is the preferred way to customize at this level?
>>
>> You're on the right lines, though I would normally use this kind of idiom to
>> get more control:
>>
>> admin.users.edit.add
>> :form, "edit_program", :after => "something"
>>
>> and
>> then you need to create the partial, which in this case would
>> be
>>
>>
>> vendor/extensions/your_extension/app/views/admin/users/_edit_program.html.haml
>>
> I did this, and created a file in the correct place, and entered the
> following in my "activate" method:
>
> admin.users.edit.add :form, "edit_program", :after => "edit_roles"
>
> My partial looks like this:
>
> - form.edit_program do
> %p
> = f.label :program_id, t('program'), :class => "optional"
> = f.select :program_id, Program.all.collect {|p| [p.name, p.id]}
>
> and I get the classic
>
> " wrong number of arguments (0 for 1)"
>
> message when I try to render the form. This is because, AFAIK, the partial
> hasn't been passed the "form" variable as a local.
No, you're right, and I've never found the right answer for that. The only way
I know to use FormBuilder methods is to wrap a fields_for around the partial:
- fields_for :user, @user do |ff|
= ff.label :program_id, t('program'), :class => "optional"
= ff.select :program_id, Program.all.collect {|p| [p.name, p.id]}
which isn't very helpful when you're trying to reuse a bit of form, but it does
work.
will
Re: [Radiant] Customizing the user admin UI at the column level
On 13 Aug 2010, at 00:35, Wes Gamble wrote: > I have reviewed the contents of > http://wiki.github.com/radiant/radiant/modifying-the-page-ui in depth. > > I have extension that modifies the user model to be attached to something > called a program, and I've made the change in the DB, and modified the user > model in my extension code like so: > > User && class User < ActiveRecord::Base > belongs_to :program > end > > so that the association will be there. > > Now, I would like to be able to display and edit program assignments for a > given user in the admin. UI. > > In my extension's "activate" method, I added the following lines in the hopes > of customizing the UI: > > admin.user.edit.form << 'edit_program' > admin.user.index.thead << 'program_header' > admin.user.index.tbody << 'program_cell' > > thinking that the display of the user admin was super dynamic and it would > just figure out how to display the edit components based on attribute type. > > But when I try to look at the index view of users, I get: > > "`program_header' default partial not found! `program_cell' default partial > not found!" as errors in the index display. > > and > > `edit_program' default partial not found! as an error in the edit display. > > After looking into it, though, I see the admin/users/edit and > admin/users/index views under the Radiant core are more or less hard-coded at > the column level, but the error messages imply that I should be able to add a > partial somewhere for my custom fields. > > Questions: > > What is the preferred way to customize at this level? You're on the right lines, though I would normally use this kind of idiom to get more control: admin.users.edit.add :form, "edit_program", :after => "something" and then you need to create the partial, which in this case would be vendor/extensions/your_extension/app/views/admin/users/_edit_program.html.haml If you want it to live somewhere else - eg. to share a form component between several models - then you can specify the full path to the partial in the usual way: admin.users.edit.add :form, "admin/programs/edit_program", :after => "something" > Do I need to just override the entire edit and index views? Much better to avoid that: working through the UI you are relatively safe from interface changes and able to co-operate with other extensions. > Is there some Javascript-y way to do this that I'm missing? Nope. best, will
Re: [Radiant] Using Sass mixins with Radiant managed Sass-filtered CSS files
On 10 Aug 2010, at 17:47, Wes Gamble wrote: > All, > > I have a Sass file that I am managing in Radiant. I'd like to pull in a > mixin to keep the Sass file clean. > > I placed my mixin Sass file in > RADIANT_ROOT/public/stylesheets/sass/_mixins.sass > > I refer to it from my stylesheet with the import statement > > @import mixins.sass > > and the file can't be found. > > What am I doing wrong? Nothing wrong, but you need to set load_paths in the sass_filter extension so that the sass engine looks in the right place for your mixin. There's a fork here to do that: http://github.com/spanner/radiant-sns-sass-filter-extension I wrote it quite a while ago and things have probably moved on since then, but it'll give you the idea. will
Re: [Radiant] Radiant 9.1 and Multi Site
On 27 Jul 2010, at 06:47, Alexis Masters wrote: > Is anyone making any progress in getting multi site going on 9.1? It is a > core extension for me, and I can't do any more Radiant sites without it. To > get the functionality I need, I've actually been driven back to Coldfusion, a > fate almost worse than death :-) The sites extension [1] is working on 0.9 except for some small but vital interface bits like the site-chooser. It's an attempt to clarify the currently rather confusing multi_site situation and not quite finished yet, but I will make sure it keeps working in the same way through the work that's coming up to move the fundamentals of multi_site into core. best, will [1] http://github.com/spanner/radiant-sites-extension
Re: [Radiant] paperclipped_uploader
On 25 Jul 2010, at 18:25, Steven Southard wrote: > This is an addon to paperclipped right? I've added it to extension, updated, > migrated and I'm not seeing anything new. I've got a bunch of images to > upload and I'd like to have a simple interface to do it all at once. What am > I missing here? A button marked 'batch upload'. I must have broken something. Will check tomorrow. will
