[Radiant] Rails 2.3 Templates WAS: Radiant 0.8.0 Asterism Release
Now that Radiant is on Rail 2.3, has anyone investigated (or planning to investigate) using application templates to simplify things? For example, its often been asked if there were an easy way to share template sites and/or themes. This has always been hard to do but it occurs to me that with templates, this will be MUCH easier. Similarly, we have a problem of how to ensure dependencies are met for installing extensions. I'm wondering if: 1. anyone else sees value in pursuing templates as a generalized mechanism to more easily bootstrap radiant sites (ala radiant -t http://www.example.com/my_cool_theme.rad NewSite) or installing and uninstalling extensions 2. anyone is already working on it... I'm rather busy on other fronts these days, so if someone is already thinking about it, I'd rather collaborate than start from scratch. Adam On Sun, Jun 14, 2009 at 12:40 PM, Sean Cribbs seancri...@gmail.com wrote: Looks like it's time for another release of Radiant: http://radiantcms.org/download/ Radiant 0.8.0 Asterism features a brand new and more compliant caching mechanism based on Rack::Cache, and numerous bugfixes and small enhancements. Also included are: * An extensive integration suite using Cucumber and Webrat * Rails 2.3.2 (previously 2.1.2) * Highline 1.5.1 * Haml 2.0.9 Many thanks to our contributors and committers for their contributions. WHAT IS RADIANT CMS? Radiant is a no-fluff content management system made for designers and programmers and is ideal for use on small teams. It is similar to Movable Type or Textpattern, but is much more than a blogging engine. Radiant features: * An elegant user interface * The ability to arrange pages in a hierarchy * Flexible templating with layouts, snippets, page parts, and a custom tagging language (Radius: http://radius.rubyforge.org) * A dynamic extension system * A simple user management/permissions system * Support for Markdown and Textile as well as traditional HTML (it's easy to create other filters) * Operates in two modes: dev and production depending on the URL * A caching system which expires pages every 5 minutes * Built using Ruby on Rails (which means that extending Radiant is as easy as any other Rails application) * Licensed under the MIT-License * And much more... There's even a live demo over on the project Web site: http://radiantcms.org/demo/ WHAT'S NEW IN THIS RELEASE? * Warn about using the RedCloth 3 fallback. [Sean Cribbs, Jason Garber] * Prevent stty errors on JRuby while running bootstrap. [Sean Cribbs] * Moved template_name to ApplicationController [Jim Gay, Michael Kessler] * Remove vizres plugin. [Sean Cribbs] * Update instance config/environments to remove ResponseCache [Jim Gay] * Remove :order option from r:children:count /, which causes errors on postgresql. [Sean Cribbs] * Prevent recursion via the r:content / tag. [Sean Cribbs] * Update Highline. [Sean Cribbs] * Update Cucumber and RSpec, clean up some features and fix specs. [Sean Cribbs] * Set the protected attributes for users in User.protected_attributes [Jim Gay] * Don't allow a nil ETag in SiteController. [David Cato] * Prevent failed login message from sticking around. [Kunal Shah] * Fix failing test regarding extension order. [Brett McHargue] * Catch ActiveRecord::RecordNotFound in Admin::ResourceController [Jim Gay] * Catch missing template errors for show routes [Jim Gay] * Fix with_error in render_matcher not causing the spec to fail when no exception raised. [Jason Garber] * Make features task run in instance mode. [Sean Cribbs] * Remove Admin::AbstractModelController. [Sean Cribbs] * Cleanup deprecated Gem::manage_gems. [Sean Cribbs] * Add begin...rescue blocks to rspec.rake [Sean Cribbs] * Add begin...rescue blocks for requiring cucumber. [Matt Henry] * Deprecate ResponseCache, add Radiant::Cache based on Rack::Cache. [Sean Cribbs] * Use app name for session cookie. [Josh French] * Upgrade to Rails 2.3.2. [Sean Cribbs, Rick DeNatale, Josh French, Kunal Shah] * Populate config.extensions so extensions can be disabled easily. [Jason Garber] * Convert integration specs to Cucumber stories and update RSpec. [Sean Cribbs] * Use ActionView::PathSet instead of normal arrays for view paths. [Pat Allan] * Don't raise exception on unauthenticated request to /admin/logout. [Josh French] * Reverse view paths order in extension loader. [Sean Cribbs, Brent Kroeker] * Remove obviated Ruby 1.8.7 compatibility patch. [Sean Cribbs] * Adjust StandardTags#relative_url_for for case when relative_url_root is nil. [Sean Cribbs] * Correct rendering error in extensions controller. [Sean Cribbs] * Correct typo in config/boot.rb. [Sean Cribbs] * Major refactoring and simplification of LoginSystem. [Sean Cribbs] * Update Haml to 2.0.7. [Sean Cribbs] * Upgrade to Rails 2.2.2. [Sean Cribbs] * Cleanup the config class a little, add some more
[Radiant] Mailer extension question
Hey all, I need some help. I'm trying to make a mailer page where I want to allow users to select the recipient. However, I really don't want to expose the recipient's address. I was planning on using the following form: r:mailer:form name=contact div class=field label for=destinationDestination/label div class=inputr:select name=destination r:option value=0First/r:option r:option value=1Second/r:option /r:select/div /div ... Other stuff ... /r:mailer:form The code suggests that the mailer part is rendered before it is parsed as YAML. So I set my mailer to: subject: Sent from your mailer form from_field: email recipients: r:mailer:if_value name=recipient equals=0 - z...@example.com/r:mailer:if_value r:mailer:if_value name=recipient equals=1 - o...@example.com/r:mailer:if_value But when I run it I get the following error: syntax error on line 4, col 53: `' I'd rather not have to customize the extension if I don't have to. -- Adam van den Hoven Hybrid Web Developer Little Fyr Media p: 604.618.0845 e: adam.vandenho...@gmail.com w: http://www.littlefyr.com ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Re: Mailer extension question
So I went and solved my own problem by modifying things (http://github.com/adsmart/radiant-directory-mailer-extension) and it turns out that it was a very simply addition. Simply change recipients to directory in you mailer part and add recipients_field. The value of the recipients field is now a list of the indexes of items in the directory to use as the recipients. That is, given a mailer of: subject: Sent from your mailer form recipient_field: destination directory: - z...@example.com - o...@example.com and the form from my original post, the message will be sent only to the email address(es) that are selected in the form. I do need help with one bit. I'm not well versed on (T|B)DD so I haven't modified the specs to account for the new behaviour. I'm not quite sure how to do it. Manually keeping the form and the mailer config in sync is more prone to error than I'd like so I'm thinking of adding a tag that would let you do: r:mailer:select name=destination r:directory / /r:mailer:select To get the names, I'm not sure if I prefer directory: - z...@example.com - o...@example.com names: - First Address - Second Address or directory: - name: First Address email: z...@example.com - name: Second Address email: o...@example.com either approach has its advantages and disadvantages. On Thu, 2009-04-09 at 23:26 -0700, Adam van den Hoven wrote: Hey all, I need some help. I'm trying to make a mailer page where I want to allow users to select the recipient. However, I really don't want to expose the recipient's address. I was planning on using the following form: r:mailer:form name=contact div class=field label for=destinationDestination/label div class=inputr:select name=destination r:option value=0First/r:option r:option value=1Second/r:option /r:select/div /div ... Other stuff ... /r:mailer:form The code suggests that the mailer part is rendered before it is parsed as YAML. So I set my mailer to: subject: Sent from your mailer form from_field: email recipients: r:mailer:if_value name=recipient equals=0 - z...@example.com/r:mailer:if_value r:mailer:if_value name=recipient equals=1 - o...@example.com/r:mailer:if_value But when I run it I get the following error: syntax error on line 4, col 53: `' I'd rather not have to customize the extension if I don't have to. -- Adam van den Hoven Hybrid Web Developer Little Fyr Media p: 604.618.0845 e: adam.vandenho...@gmail.com w: http://www.littlefyr.com ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Hosting 0.7.1 site w/ Papperclipped
I've had a lot of success using Dreamhost. Its a discount hosting service so you're getting what you pay for. There have been some unfortunate downtime but in my opinion, its the best option until you're up to the volumes that warrant something like slicehost (http://www.slicehost.com/). Regardless, I would use Google for the email (which is easy to do with Dreamhost); that way if you move hosts, your email doesn't move. Just my 0.02 On Wed, 2009-04-08 at 14:42 -0400, Brian Gernhardt wrote: I'm working on a website for a client and I'm attempting to find a decent host for them. I'm building the site locally right now, using Radiant 0.7.1, Paperclipped, and Styles 'n' Scripts. I've looked around but it's far too easy to find piles of negative feedback about everyone, and difficult to get an independent review. So I thought I'd ask the people actually using Radiant what they think. The site itself is fairly simple, but we'll need a small pile of e- mail addresses as well. Any suggestions, list? ~~ Brian ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant -- Adam van den Hoven Hybrid Web Developer Little Fyr Media p: 604.618.0845 e: adam.vandenho...@gmail.com w: http://www.littlefyr.com ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] [ANN] Tiny-Paper Extension
On Tue, 2009-03-17 at 17:57 +0200, Istvan Hoka wrote: Announcing the Radiant Tiny-Paper Extension! Features: * TinyMCE WYSIWYG editor in your Radiant page as a filter; * Image Browser, based on Paperclipped image assets; * File Browser, based on Paperclipped assets; * Upload assets directly in TinyMCE Image/File browser; * Thumbnails and text list views; * Directly add a link to a Radiant Page from TinyMce editor. Check out the official announcement [http://blog.aissac.ro/2009/03/17/radiant-tiny-paper-extension/] and the source code on github [http://github.com/Aissac/radiant-tiny-paper-extension]. For installation and configuration details visit the Radiant Tiny-Paper Extension documentation page [http://blog.aissac.ro/radiant/tiny-paper-extension/]. Cheers! This looks great!! One question, it says that its 0.7.1 compatible but what about earlier versions, like 0.6.9? Adam -- Adam van den Hoven Hybrid Web Developer Little Fyr Media p: 604.618.0845 e: adam.vandenho...@gmail.com w: http://www.littlefyr.com ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Customizing Radiant's command line behaviour
Ah ha! Ok. well now I have something to work with! I think that this will be more than adequate for my needs. Thanks! On 31-Jan-09, at 6:30 AM, Sean Cribbs wrote: rake db:bootstrap takes a number of environment variable options. Take for example, this line from the script for demo.radiantcms.org: rake production db:bootstrap ADMIN_NAME=Administrator ADMIN_USERNAME=admin ADMIN_PASSWORD=radiant DATABASE_TEMPLATE=/usr/ local/lib/ruby/gems/1.8/gems/radiant-0.6.9/db/templates/styled- blog.yml OVERWRITE=true Sean Mohit Sindhwani wrote: Adam van den Hoven wrote: I was talking about editing radiant directly and bending to my will but writing a script to handle it is probably smarter. Sigh I do hate it when lofty ideas are shot down. :) Now if I could only bypass the interactive portions of the bootstrap. My usual way to do that last part is to create a file that has the hard coded responses and then redirect input from the command line. my_executable.cmd response.txt Would that help? Cheers, Mohit. 1/31/2009 | 6:50 PM. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Customizing Radiant's command line behaviour
On 30-Jan-09, at 7:32 PM, N. Turnage wrote: Adam van den Hoven wrote: The thread on what standard plugins do people use as well the Oops I deleted the contest2 content thread got me thinking that it would be great if someone wrote a tutorial to the effect of, How to customize your Radiant command. Usually I start 90% of my radiant sites by installing the same extensions; they fit into the way I like to do my work. I am also inherently lazy so I'd rather put a lot of work in now to prevent having to do that work over and over again later (I'm told that's not actually lazy, but I'm not convinced). Things I would like know how to do: 1) add my own default plugins to the created site 2) add my own initial site templates (or force a single initial setup) 3) take production database parameters from the command line (I tend to follow the same pattern since most of my sites are on dreamhost) 4) save the results in Git (either in my own repository on Dreamhost or in GitHub) 5) update my custom radiant with the lastest changes (either plugins or radiant itself) half a year from now. . I like the idea of making the radiant command do things the way I like it but (5) is critical if I don't want to fall behind. I also want to control which versions I see of any of these so that I don't get hosed when version 0.8 comes out and now half my extensions won't work with 0.7.9 Sorry, dude, but that wouldn't work that way because of the nature of open source. Not everybody maintains their extensions with up to the minute changes for Radiant edge, there is no standard way for managing Radiant projects in git, extensions aren't always in git repos and the extensions are rarely tagged for which which commits work with which Radiant versions. Not to mention that some people prefer to use the multi_site extension for their Radiant projects which brings a whole other set of complications. Also, Dreamhost hosting for Radiant projects presents a further set of complications that someone like myself doesn't encounter because I use Rails Playground instead. The only way that it might be possible for your suggestion to work is for RadiantMachine to get up and running and have it become the standard way of building and hosting Radiant apps. It would need to be kind of like Wordpress where they have a large number of sites that are hosted by the mothership, but if people so desire they can build and run a Wordpress site on their own servers. What do you think, Sean, you're not busy, eh? Feel like becoming a millionaire? All you need is some venture capital. That's exactly my point, actually. Let me back up a few points because I seem to be starting from a different point of view than most sane rational folk ;) According to the website, Radiant is a no-fluff, open source content management system designed for small teams. Now there are two ways to look at that. One category of small teams will be the sort where, I have to build a website for my company/team/church/self and look this is good. A lot of people using it once, maybe twice. The other category is what I do. I build websites for companies. I have used content management systems for almost a decade now, starting with a small company where we built a CMS for news broadcasters, since then I've been using Interwoven Teamsite for my real work. Radiant is my platform of choice for my moonlighting work. So I'm going to be building a lot of sites from one instance of the radiant gem. Everytime I build a site, I'm going to start exactly the same way (following some variation on my own tutorial on the subject: http://wiki.radiantcms.org/Install_Dreamhost_Using_SSH) . Not very DRY. As you said, not everyone keeps their extension up to date with the edge. Also, not everyone tags their extensions so that its easy to get the right version of an extension to work with my version of radiant. One solution is to fork those into my own repository so I always have the right one. Like I said, I do the same things time and again to start off. So what i want to do is have all those things done for me automatically. Now I could write a script to do all this but it seems more natural to create my default starting site once put it in to my repository and have the radiant command create my starting site, not the current default. This customized radiant would live in my own repository and would be useful only to me. But since I'll use it several times a month, that's ok. Plus since I'm keeping it under version control, I've effectively put my business process under version control too. I know that what I do will be repeatable and if I need to switch computers or bring on a partner, we can continue to use the same. Seriously, though, I think Radiant is just fine as it is. Well, it would be nice to have those blogging features alluded to for 7.1
Re: [Radiant] Customizing Radiant's command line behaviour
I was talking about editing radiant directly and bending to my will but writing a script to handle it is probably smarter. Sigh I do hate it when lofty ideas are shot down. :) Now if I could only bypass the interactive portions of the bootstrap. On 30-Jan-09, at 10:03 PM, Mohit Sindhwani wrote: Adam van den Hoven wrote: Absolutely. I'm talking about tailoring it for MY needs and then documenting how I did it so that others can, if they like, do the same. I don't want to change Radiant, I wan't to change how I use it. Its like taking a suit off the rack and asking a tailor to adjust the fit (only I'm the tailor too). Are you talking about something like this: http://snippets.dzone.com/posts/show/5036 Cheers, Mohit. 1/31/2009 | 2:03 PM. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Accidently removed the body of contest2.radiantcms.org/
Agreed, except for the asset manager, sort of. I can think that an asset manager is going to be something that will be ideosyncratic for many people. I would REALLY like to see not only a standard asset manager but also an architecture that allows me to write my own asset manager without loosing the existing hooks into the UI. This way if I make an extension that needs access to the asset manager, I don't have to know what all the existing asset managers are. I just have to use the AssetManagerBucketHelper or something. On 27-Jan-09, at 1:21 PM, Joe Van Dyk wrote: On Tue, Jan 27, 2009 at 10:56 AM, Mohit Sindhwani t...@onghu.com wrote: Adam van den Hoven wrote: I think this highlights why some sort of versioning really shouldn't be an optional part of radiant. Distribute it as an extension, but make it one of those extensions that comes by default. This way everyone has some protection but I can substitute my own advanced version control or remove it if I like. +1 +2 over here. Other things that we think most people would want by default: - some sort of rich text editor - asset manager better integrated It would be great to have these as extensions, but installed by default. Having an officially blessed extension is important for quality, in our opinion. Joe ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
[Radiant] Customizing Radiant's command line behaviour
The thread on what standard plugins do people use as well the Oops I deleted the contest2 content thread got me thinking that it would be great if someone wrote a tutorial to the effect of, How to customize your Radiant command. Usually I start 90% of my radiant sites by installing the same extensions; they fit into the way I like to do my work. I am also inherently lazy so I'd rather put a lot of work in now to prevent having to do that work over and over again later (I'm told that's not actually lazy, but I'm not convinced). Things I would like know how to do: 1) add my own default plugins to the created site 2) add my own initial site templates (or force a single initial setup) 3) take production database parameters from the command line (I tend to follow the same pattern since most of my sites are on dreamhost) 4) save the results in Git (either in my own repository on Dreamhost or in GitHub) 5) update my custom radiant with the lastest changes (either plugins or radiant itself) half a year from now. . I like the idea of making the radiant command do things the way I like it but (5) is critical if I don't want to fall behind. I also want to control which versions I see of any of these so that I don't get hosed when version 0.8 comes out and now half my extensions won't work with 0.7.9 I know, I know, never suggest something you wouldn't do yourself. Since I'm not entirely sure where I would start, if someone could pitch some suggestions it might get me going. Adam ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Re: Flash In IE
Wow, that is a lot of JavaScript. Since MS has rolled back its click to activate end run around Eolas, its not really necessary any more. Further, something as simple as a slide show should be written to work on pretty much any version of Flash you're going to find in the wild. I, honestly, can't think of any good reason for all that JavaScript to get something that simple to run. I would use the following: object classid=clsid:D27CDB6E-AE6D-11cf-96B8-44455354 width=300 height=120 param name=movie value=test6_flashvars.swf / param name=menu value=false / param name=wmode value=transparent / param name=flashvars value=name1=helloamp;name2=worldamp;name3=foobar / !--[if !IE]-- object type=application/x-shockwave-flash data=test6_flashvars.swf width=300 height=120 param name=menu value=false / param name=wmode value=transparent / param name=flashvars value=name1=helloamp;name2=worldamp;name3=foobar / !--![endif]-- div h1Alternative content/h1 pa href=http://www.adobe.com/go/getflashplayer;img src=http://www.adobe.com/images/shared/download_buttons/get_flash_player.gif alt=Get Adobe Flash player style=border:none; //a/p /div !--[if !IE]-- /object !--![endif]-- /object which I took from the last group of techniques available on this page: http://www.bobbyvandersluis.com/flashembed/testsuite/ However, if you're really married to the JavaScript and its not working for some version of IE, you need to have your Flash Dude figure out what's wrong with his code On 10-Jan-09, at 2:19 PM, Kelly Torian wrote: Russ Johnson wrote: How are you calling the flash? Are you using the javascript method to load it or the old embed tags? I'm using the embed tags in the header snipper where the slide show resides. However, in the layout I am calling an external link to a version checking java script within the head tags, provided by the artist who did the animation. JS file is attached. -Kelly Attachments: http://www.ruby-forum.com/attachment/3145/AC_RunActiveContent.js -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Editing Styles in Radiant CMS
+1 for Its All Text! Textmate. Thanks for the reminder about the short cut; I hate looking for that little icon. I suppose, though, if you wanted a real IDE, one could write an Eclipse extension... (ouch my brain hurts) On 9-Jan-09, at 10:31 AM, Michael Kessler wrote: I'm using the 'It's All Text!' Firefox extension, which you'll find here: https://addons.mozilla.org/el/firefox/addon/4125?lang=de I configured Command-E as shortcut to start editing a textarea and configured Textmate as editor. Whenever I edit some content Textmate will be opened, and Command-S will write back the changed to the textarea. This allows comfortable editing but the workflow is not the best if you have to edit a lot. I planned to have a closer look at the dav extension, this would enable content editing in the database like a local project. But I haven't had time to test it. Michael On 9 Jan 2009, at 4:26 AM, Mark Muskardin wrote: Hello, I'm a newb to Radiant CMS :) I'd like to edit the HTML structure of my Radiant CMS entries. Inside of the Articles parent page, I've added a div around r:content. But after I click save, this new markup does not display in source. I would prefer to edit the markup from my text-editor instead of the admin browser interface, but I can't locate the files in my Rails project. Can you use a text editor to directly edit the files instead of using the browser interface? This would be a boon to productivity. Where are these files located in the file-system? Also, am I correct in assuming that you can only create Controllers and Models by creating Extensions? Thanks so much! //M ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Edit History Extension
On 5-Jan-09, at 9:09 AM, Manuel Meurer wrote: Wow, lots of ideas here. I will go for the acts_as_versioned plugin as Andreas suggested. Once that is working we can think about saving incremental changes, different published versions etc. Probably wise ;) Tim, why would you like the git option better? For me it seems cleaner to have all your stuff in one place, not the pages in a db and page versions in git. I wondered that too. It also revisions specific fields NOT the whole record so you can't really go back in time unless you know all the fields that need to be revisioned... and that is tough to do when you add extensions to the mix. Manuel On Mon, Jan 5, 2009 at 5:52 PM, Adam van den Hoven adam.vandenho...@gmail.com wrote: You should also consider that if you're going to keep a version history that only one revision (and certainly not necessarily the current revision) should be published. This will allow you make a number of changes to a page (especially useful if you extend the page preview extension to work with versions) without affecting the current public version. This would also allow you to reduce the size of the version history by keeping all the incremental edits once this version is published collapse the version history down to the published version. This gives you a history that includes all the published versions and all the incremental changes since the last published version. The core development team may want to consider a modification to the core status properties which will (a) make it easier to do versioning as I've mentioned and (b) make things clearer. The change is to break the current status into 2 two fields. The first would be called status and would have values like draft, reviewed, published. The second field would be visibility and would have values like visible and invisible. Visible and the three status values map directly to the current status values, and published + invisible is the same as the current hidden status. This allows you separate the purpose of a page (RSS, CSS, etc) from its status. I think this simplifies the meaning of things since whether or not a page is publicly accessible is completely independent of whether or not that page appears in navigation. It will also make it easier, I think, to create a workflow extension. My 2 cents . Adam On 5-Jan-09, at 8:14 AM, Andreas Roedl wrote: Shouldn't be too hard to implement, at least, when you use one of the following plugins: Acts as versioned (see the example code): http://wiki.rubyonrails.org/rails/pages/ActsAsVersioned A Rails plugin that uses Git to version ActiveRecord fields: http://github.com/courtenay/acts_like_git/tree/master Andreas ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Edit History Extension
You should also consider that if you're going to keep a version history that only one revision (and certainly not necessarily the current revision) should be published. This will allow you make a number of changes to a page (especially useful if you extend the page preview extension to work with versions) without affecting the current public version. This would also allow you to reduce the size of the version history by keeping all the incremental edits once this version is published collapse the version history down to the published version. This gives you a history that includes all the published versions and all the incremental changes since the last published version. The core development team may want to consider a modification to the core status properties which will (a) make it easier to do versioning as I've mentioned and (b) make things clearer. The change is to break the current status into 2 two fields. The first would be called status and would have values like draft, reviewed, published. The second field would be visibility and would have values like visible and invisible. Visible and the three status values map directly to the current status values, and published + invisible is the same as the current hidden status. This allows you separate the purpose of a page (RSS, CSS, etc) from its status. I think this simplifies the meaning of things since whether or not a page is publicly accessible is completely independent of whether or not that page appears in navigation. It will also make it easier, I think, to create a workflow extension. My 2 cents . Adam On 5-Jan-09, at 8:14 AM, Andreas Roedl wrote: Shouldn't be too hard to implement, at least, when you use one of the following plugins: Acts as versioned (see the example code): http://wiki.rubyonrails.org/rails/pages/ActsAsVersioned A Rails plugin that uses Git to version ActiveRecord fields: http://github.com/courtenay/acts_like_git/tree/master Andreas ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Shiny ooo-aaah AJAX navigation.
There really isn't any reason to use AJAX get this effect, unless you're talking about tens of thousands of pages. Simply start by loading your navigation in an unordered list. Include all the natural elements and none of the pagination controls. Then write javascript that will take your unordered list and wrap it so you get: div class=paginated a class=backwardlt;/a ul class='nav'/ul a class=forwardgt;/a /div or something similar. Then use CSS to position everything how you want. Your UL is going be how ever wide want and your LI elements are going to be inline. Here's the trick, use the CSS clip property to control the visible contents of the UL. The JavaScript events on your two forward and backward anchors would then change the clip to show the next window of stuff. Adam On 23-Dec-08, at 6:04 AM, Jeffrey Jones wrote: Hoi Tim, Not my site and not my choice unfortunately. I already pointed these flaws out. The other problem is that the navigation menus makes use of honking great images which means that the navigation menu wouldn't fit in the page if it were displayed in full. Again I am aware of the drawbacks of such a set-up (I will put in a sitemap page if I can) but it isn't my site and the owner has definite ideas about how he wants it to look, it is very much form over function. Cheers Arj Tim Gossett wrote: On Tue, Dec 23, 2008 at 4:20 AM, Jeffrey Jones j...@jones.be wrote: Lets say I have a simple Radiant based site. Pages with sub-pages etc etc. All very simple. However the user wants the navigation menu to be scrollable using little buttons Like the following NAV1 - NAV2- NAV3- NAV4 Clicking the button would change the nav to NAV5 - NAV6- NAV7- NAV8 and so on using AJAX to update the navigation menu. This navigation menu is going to be on the one layout this site will use so all the pages will have it without exception. Now, how can I do this? If you rely on AJAX to bring in parts of the navigation menu, then your site won't work for users without JavaScript enabled (read: Google won't be able to use the navigation menu). Also, you'll be creating superfluous requests to load a little bit of HTML, which is a big performance hit. Why not do this: Have your layout create a list with all of the navigation links that might otherwise be loaded by AJAX. (This will ensure that the site works for non-JS users). Use JS to hide all but the first four nav links when body.onLoad. Bind a function to your little buttons .onClick to hide those four and show the next four nav links. Your users won't have to wait for an HTTP request to complete before they can see the nav links they want, and your menu will be wicked-fast, leaving some headroom for sexy animations (slides, fades, etc.). No need to write an extension. -- Tim ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Radiant for Blogin - Shorthand?
If you wrote a simple parameterized snippet (you'd need that extension too), you could easily set things up so that you have: r:snippet name=amazon id=123456789 Some Cool book /r:snippet its not exactly what you want but it would be 80% of the way there! On 6-Dec-08, at 12:53 PM, Anton J Aylward wrote: Another Blog related question. I'm using KDE/Linux. The browser, Konqueror, has 'shorthand' or 'abbreviations', such as 'cpan', 'jeeves', 'google', 'ggmovie', 'wp' (for wikipedia). It occurs to me that I'm making a lot of references to Amazon in my blog. It would be nice to be able to write amazon:9620102 and have a reference to that isbn or product id. Even better if it also has my Associates ID in there as well :-) There's something like this on Rory Hansen's site http://www.roryhansen.ca/category/ruby-on-rails/ :-( Shame I'm not a programmer :-( The Amazon example is clearly useful. I can think of a couple of others that are marginal like YouTube and Twitter and Flickr. Perhaps a 'configurable' url-abbreviation-expander is the right idea, like in Konqueror. -- Atheism is a non-prophet organization. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Templates extension documentation?
Nate, It seems to me that what is missing is a blow by blood dripping, gut wrenching, soul ripping blow account (was that over the top?) of how to get something going with Templates. You should be writing down your experiences to share with the rest of us. I'm sure the Radiant Wiki has room for such a thing. Adam On 4-Dec-08, at 8:48 AM, Nate Turnage wrote: Also, Sean, there is one small problem with the Templates extension: there doesn't seem to be a way to change the page status from draft to published. I set my pages to published in the db, but that will get awfully tedious in short order. Is there any other way to set a page's status to published without setting it in the admin page view? It would be tremendous if that was possible in the page list in the admin side (wink, wink). Thanks, ~Nate ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] r:find question
I don't think that the issue at hand is the average user who is going
to be hacking with the source code. They don't exist. You start
hacking with source code and you need to be at a higher level of
expertise.
JSTL and JSP EL handle this more elegantly (how much more is a matter
of taste) where you can do (I'll freely mix radius and jstl for effect):
c:set var=myVarr:slug //c:set
a:href=${myVar}r:title //a
I'm in the process of turning all of HTML into a JSP TagLib (honest)
so that I can do (again mixing with radius):
a title=here is my title attribute
jspx:attribute name=hrefr:slug //jspx:attribute
r:title /
/a
which will produce exactly what you expect.
It may be verbose, but I actually like the later approach better and I
think that something like his might be valuable for radius?
On 3-Dec-08, at 6:29 AM, Chris Parrish wrote:
Actually, I should probably clarify. I agree that IF you are going
to use an XML paradigm, better to leave it be. That said as
Radiant's been growing in popularity, I've been seeing more and more
people hitting a wall here.
I'm starting to wonder whether using an XML paradigm is really
best. After all, I wouldn't think that the target Radiant user is
necessarily familiar with XML. (And a href=r:slug//
title=r:title//Link Text/a isn't all that elegant or XML
consistent either -- as Sean noted).
I realize that Radius' goal of maintaining simplicity is good -- I
want elegance too -- but has anyone given any thought to these kinds
of needs. My vote was with the desire for consistency, but that
does still leave the legitimate, requested need un-addressed here.
-Chris
Chris Parrish wrote:
+1
Sean Cribbs wrote:
Adam van den Hoven wrote:
EEEWWW NOO!
Please don't do this. If you are going to use an XML paradigm for
your DSL then stick to it. There is nothing that makes my skin
crawl more than seeing tags as attribute values.
Aside from pure aesthetics (which is considerable), there is the
matter of tooling. I can find extensible WYSIWYG XML widgets
(they're not as common or as cheap as I'd like) and none of them
will never be able to handle this (IMHO, extending XML widgets
may be better in the long term than wrapping textile or what have
you). And and you'll never be able to debug it.
I hate that we do this now for HTML attribute values, lets not
pollute the paradigm more. Otherwise rolling something into HAML
would be better (I'm guessing)
YAY! Someone who agrees with me!
The caveat, of course, is that often you need to put Radius tags
inside the attributes of HTML tags. But that's because Radius is
not strict XML, but interpolated. When explaining Radius to a
local web design meetup, one sorta-technical guy suggested we use
an XML parser/XSLT and I had to tell him no. It only looks like
it could be.
Sean
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] plugin jrails prevents adding page parts
If you are just using jQuery (presumably for your production site not the admin interface) why not save yourself the hassle and use the copy in Google's CDN? http://code.google.com/apis/ajaxlibs/ You can do things using Google's loader (which I'm not a huge fan of, though it is a neat idea) or you can simply use their URI: http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js . Save yourself the maintenance. On 3-Dec-08, at 2:44 PM, bruce davison wrote: Jim, Yes I am sure you are right I realised I don't need jrails, since I am not using it. I just needed jQuery, which I now have in public/ javascripts and works just fine. Thanks, Bruce Jim Gay wrote: On Dec 2, 2008, at 8:02 PM, bruce davison wrote: I need to use jQuery and added the plugin jrails. The code for jquery works find when I include the js in the layout, but when I try to add page parts only part of the page is showing no button to create etc. When I removed jrails from the plugins 'add page part' works again. Radiant isn't using RJS for adding page parts in 0.6.9, so it's likely that jrails is screwing up the $ function. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Modifying look-feel, and an error I'm seeing
Change the admin.subtitle and admin.title properties and you'll be good. You can do it through the console (which I don't like) or install the Settings extension and edit it directly in the UI (which I do like). On 28-Nov-08, at 10:47 AM, Robert Calco wrote: What's the trick to modifying existing pages (For example, in the admin pages, I want it to say something other than Radiant CMS)? Do I have to modify them in the gem or can my extensions override? An example of how to do that would be great! Also without any customizations to the basic project created in the usual way whatsoever the admin site works OK but when I go to just about any page except the about page I'm getting the following error: NoMethodError in SiteController#show_page undefined method `[]' for #Enumerable::Enumerator:0x236b648 /opt/local/lib/ruby/gems/1.8/gems/radiant-0.6.9/vendor/rails/ activesupport/lib/active_support/core_ext/string/access.rb:43:in `first' /opt/local/lib/ruby/gems/1.8/gems/radiant-0.6.9/app/models/ standard_tags.rb:884:in `absolute_path_for' /opt/local/lib/ruby/gems/1.8/gems/radiant-0.6.9/app/models/ standard_tags.rb:584:in `tag:find' /opt/local/lib/ruby/gems/1.8/gems/radiant-0.6.9/lib/radiant/ taggable.rb:16:in `send' /opt/local/lib/ruby/gems/1.8/gems/radiant-0.6.9/lib/radiant/ taggable.rb:16:in `render_tag' /opt/local/lib/ruby/gems/1.8/gems/radiant-0.6.9/app/models/ page_context.rb:10:in `initialize' /opt/local/lib/ruby/gems/1.8/gems/radiant-0.6.9/vendor/radius/lib/ radius.rb:275:in `call' /opt/local/lib/ruby/gems/1.8/gems/radiant-0.6.9/vendor/radius/lib/ radius.rb:275:in `render_tag' /opt/local/lib/ruby/gems/1.8/gems/radiant-0.6.9/vendor/radius/lib/ radius.rb:306:in `stack' /opt/local/lib/ruby/gems/1.8/gems/radiant-0.6.9/vendor/radius/lib/ radius.rb:274:in `render_tag' /opt/local/lib/ruby/gems/1.8/gems/radiant-0.6.9/app/models/ page_context.rb:18:in `render_tag' /opt/local/lib/ruby/gems/1.8/gems/radiant-0.6.9/vendor/radius/lib/ radius.rb:437:in `parse_end_tag' /opt/local/lib/ruby/gems/1.8/gems/radiant-0.6.9/vendor/radius/lib/ radius.rb:363:in `call' /opt/local/lib/ruby/gems/1.8/gems/radiant-0.6.9/vendor/radius/lib/ radius.rb:363:in `to_s' /opt/local/lib/ruby/gems/1.8/gems/radiant-0.6.9/vendor/rails/ activesupport/lib/active_support/core_ext/array/conversions.rb:57:in `to_default_s' /opt/local/lib/ruby/gems/1.8/gems/radiant-0.6.9/vendor/rails/ activesupport/lib/active_support/core_ext/array/conversions.rb:57:in `to_s' ... Sincerely, Bob ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Reorder Extension Question
I didn't have a problem with it when I used Import/Export to transfer pages from my old database to the new. It just adds a Position column. On 25-Nov-08, at 10:16 AM, Chris Parrish wrote: I see from the Readme that Reorder breaks Import Export. Is this still true? Is there a workaround? Or is there another extension to use to set the order of child pages? -Chris ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] help
Some how this conjures up a scene from a John Wayne movie for me. Adam On 24-Nov-08, at 2:24 PM, Sean Cribbs wrote: Anything specific we can help with? Sean Chris Hoad wrote: Chris Hoad Email: [EMAIL PROTECTED] Tel: +44 1763 852361 Mob: +44 7905 475916 ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Re: Rendering Partials within a Radius Tag
That pattern seems like a sufficiently good paradigm that some sort of
convention should be created to do this. Perhaps
tag my_tag do |tag|
@my_tag_data = MyModel.find_by_name(tag.attr['name'])
tag.render
end
end
would automatically use view/tags/my_tag.haml.html or something similar.
On 21-Nov-08, at 1:45 PM, Chris Parrish wrote:
David, I still use that code in my extensions today (though I'd be
interested to hear if anyone out there has come up with something
better).
Now that Haml is built into Radiant, it would also be safe to
convert to using that for your templates (it might be even easier to
do the binding bit but I haven't tried yet).
-Chris
David Piehler wrote:
Chris Parrish's solution to rendering partials within a Radius tag
works
great. It's been almost a year since he posted it though, and I was
wondering if this functionality should be done a different way now --
i.e. does Radiant has a built-in way to handle this now?
Thanks,
- Dave
Chris Parrish wrote:
[In the Model]
tag my_tag do |tag|
@my_tag_data = MyModel.find_by_name(tag.attr['name'])
parse_template 'path_for/_my_template'
end
end
private
def parse_template(filename)
require 'erb'
template = ''
File.open(#{MyExtensionNameExtension.root}/app/views/ +
filename +
'.html.erb', 'r') { |f|
template = f.read
}
ERB.new(template).result(binding)
end
[In
/vendor/extensions/my_extension_name/app/views/path_for/
_my_template.html.erb]
h1%= @my_tag_data.name -%/h1
pValue from my instance variable: %= @my_tag_data.value -%/p
This obviously isn't full-on rails parsing so it doesn't auto-mixin
helpers or anything fancy like that (I suppose I could require
ActiveView::Base or some such thing) but I didn't need that much
capability.
-Chris
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] help with dynamic_image extension
yeah that's what I'm using now... Thx, by the way, for the help. Adam On 19-Nov-08, at 6:31 AM, Sean Cribbs wrote: Adam van den Hoven wrote: I'll jump on IRC soonest (any suggestions for a good mac client?) Colloquy is what everyone I know uses. Sean ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
I'd like to see this too. I use it for exactly this purpose, to give non-technical people the ability to manage a simple website using a CMS. To be honest, I think that the mostly technical person doesn't really need an OS CMS, they can either hand code the HTML just as easily (maybe run some scripts to generate naviation) and upload the files via ftp/svn or write their own CMS. Its precisely when we have more complicated needs (of which multiple, non-technical users is a likely one) that Radiant becomes most useful. I have some thoughts on this: 1) What would be awesome would be a WYSIWIG editor plugin that is an EXTENSIBLE HTML/XML editor. This would allow one to create GUI elements for all of the common radius tags (override creating links, for example, putting an asset browser into there, etc) and have it create the necessary markup. Maybe a markup WYSIWYG editor will allow this too but I don't know of any 2) Normally when someone wants a custom template that captures something specific (a news article or a product) really its just a way to more seamlessly (and realiably) enforce content structure (here is you headline, here is your kicker, a product image goes in this box) but really all we want to do is generate structured markup for various parts. It would be wonderful if one could create page templates that imposed some sort of structure but behind the scenes simply added a page to the database with a number of parts with predefined markup. (I'm not sure if this is like the templates extension Sean released.. Haven't had a chance to look at it). Making it part of the pages structure keeps it clear where it appears. On the other hand, you can tell your client that if they really want all that they're looking at a system like Teamsite from Interwoven which would probably cost them in the range of a half million plus 10% per year (but don't forget to put your 4% markup on that)... Adam On 18-Nov-08, at 9:44 AM, Casper Fabricius wrote: Hi everyone, I've used Radiant for more than 10 web sites during the past 1,5 years, and I really like it. Definitely the best CMS for Rails. However, I have a client whose content editor is very frustrated with the system. She can only just tolerate using Markup, and she refuses to write any kind of HTML - Radius tags falls into this category from her point of view. According to her, a proper CMS would hide all this technical stuff and provide custom forms for all types of content. I know what the core team might answer: Radiant CMS was not built for this woman. It was built for small sites and content editors with a bit of technical insight. But Radiant is still the most user- friendly CMS that exists for Rails, and I don't really feel like coding PHP just get a more advanced UI, which will suck anyway. So my question is: How do the rest of you handle this? How do you hide away technical stuff such as snippets, tags and css classes? Do you: - Use any of the WYSIWYG filters? (I've done this a few times, it has its own problems) - Build very specific custom layouts for all variants for pages? - Use a generic templating interface such as radiant-templates- extension to wrap everything up? - Write custom extensions to wrap all kinds of elements nicely in forms? (such as newsletters, spots, list of various items, etc.) Can Radiant be palatable for content editors such as my client, or is it simply the wrong choice in this case? Med venlig hilsen / Best regards, Casper Fabricius http://casperfabricius.com ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
You just hit on an interesting idea for an extension. Frequently, people are going to reuse the same bits over and over. Instead of making them go find it, what if we put a scratchpad on the right hand side of the parts (which will consume some space from the parts but that should be OK the visibility is important). This will give them a place to retrieve commonly used bits and then copy and paste them back into their content. Give it an easy way to save new scratches without leaving the page (key to making it useful). Provide a separate UI to tweak the scratch (edit, give it a title and a description) and we can bootstrap a bunch of scratches which will ease their entry into the world of markup Adam On 18-Nov-08, at 10:33 AM, Steven Southard wrote: I think maybe you just need to take another approach with her. Seems sometimes web development is more psychology then programming. Does she just put her hand over her ears when you say Markdown or Textile? I've had a client like that! She just wants to make headers, paragraphs, and upload pictures right? Keep working with her, tell here to take a few breaths, and keeping reminding her that the filters are there to keep the technical stuff out of her way. My clients don't seem to mess with the snippets, tags, or css classes that much. They just use the filters and maybe one tag and some classes that they copy and past from where ever else it was used on the site. It takes a bit for them to get the hang of it but if they can see the simple patterns they'll be able to add their content. Steven On Nov 18, 2008, at 11:44 AM, Casper Fabricius wrote: Hi everyone, I've used Radiant for more than 10 web sites during the past 1,5 years, and I really like it. Definitely the best CMS for Rails. However, I have a client whose content editor is very frustrated with the system. She can only just tolerate using Markup, and she refuses to write any kind of HTML - Radius tags falls into this category from her point of view. According to her, a proper CMS would hide all this technical stuff and provide custom forms for all types of content. I know what the core team might answer: Radiant CMS was not built for this woman. It was built for small sites and content editors with a bit of technical insight. But Radiant is still the most user- friendly CMS that exists for Rails, and I don't really feel like coding PHP just get a more advanced UI, which will suck anyway. So my question is: How do the rest of you handle this? How do you hide away technical stuff such as snippets, tags and css classes? Do you: - Use any of the WYSIWYG filters? (I've done this a few times, it has its own problems) - Build very specific custom layouts for all variants for pages? - Use a generic templating interface such as radiant-templates- extension to wrap everything up? - Write custom extensions to wrap all kinds of elements nicely in forms? (such as newsletters, spots, list of various items, etc.) Can Radiant be palatable for content editors such as my client, or is it simply the wrong choice in this case? Med venlig hilsen / Best regards, Casper Fabricius http://casperfabricius.com ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Can Radiant be really easy to use for non-technical content editors?
A couple of thoughts. 1) In general, isn't it the case that the site developer is going to want to deal with content. When you're creating content, you're seldom calling for the the part of some other page (I prefer to do this sort of work in the the layout myself). I'm not sure exposing content in this way is necessarily a good thing. At the very least, provide me a configuration mechanism to restrict access (for example, restricting certain things by user role?). Similarly, some snippets are really only supposed to go into layouts and would do very bad things in content (especially if you're in the bad habit of opening a tag in one snippet and closing it in another). 2)Make it Extensible. On 18-Nov-08, at 12:08 PM, Chris Parrish wrote: Alright, since this post is already heading in this direction, I'll throw out some ideas that I've been working on. These are getting pretty refined in my mind and I'm looking into creating an extension around them (possibly waiting for the new UI, we'll see)... 1. I think the textareas need to come with a toolbar above them (page parts, snippets, layouts). These toolbars would be filter specific. 2. All filters (including none) would include the filter-selection dropdown (this makes it clear to the user what is controlling the toolbar content) 3. All filters (including none) would include one or more insert-site-item buttons. The goal here is to prevent the user from having to remember radius tag names and their syntax (that's coder stuff) and instead make working with radius more like any other gui application. The goal here is also to focus only on the tags used for day-to-day editing (I'm not sure a button to walk you through creating your site's navigation would be wise as it would just be clutter most of the time and that task is more technical in nature). Tag attributes could be handled graphically and automatically inserted into the tag. For example: * A page properties button would open up a properties browser (and maybe showing the current page's properties as examples). Items would include, title, slug, breadcrumb, author, etc. Selecting one of these properties would insert the appropriate tag (r:title /, r:slug / etc) into the content at the cursor's position. * A content button would open up a browser for page and snippet content. Here the user can look through the existing items and select an existing snippet or page part. Once selected, it would insert the appropriate tag (either r:find url=...r:content //r:find or r:snippet name=... /) at the selected position. * A link button would open a pages browser and allow the user to select one of their pages. This would insert the r:link tag appropriately. * Asset extensions should plug in here to allow users to browse assets and choose the one they want, select any options, then insert the corresponding tag. 4. Each filter would have its own button set but they would have a consistent flavor across filters. For example: * Markdown would come with: bold, italics, bullet list, numbered list, heading(s), insert link, insert image, blockquote (something like http://livepipe.net/control/textarea). The insert link button should probably work together with the one mentioned above to let the user select from their own pages or insert an external link -- both formated for markdown. * Textile would have something like Markdown (again, the buttons look the same but they insert textile specific elements). I would welcome feedback or any collaborators. -Chris Jim Gay wrote: On Nov 18, 2008, at 1:42 PM, Adam van den Hoven wrote: You just hit on an interesting idea for an extension. Frequently, people are going to reuse the same bits over and over. Instead of making them go find it, what if we put a scratchpad on the right hand side of the parts (which will consume some space from the parts but that should be OK the visibility is important). This will give them a place to retrieve commonly used bits and then copy and paste them back into their content. Give it an easy way to save new scratches without leaving the page (key to making it useful). Provide a separate UI to tweak the scratch (edit, give it a title and a description) and we can bootstrap a bunch of scratches which will ease their entry into the world of markup Adam development has stalled on it, but the start of a browser extension intends to add an area where things like this can be done: http://github.com/saturnflyer/radiant-browser-extension/tree/master there's nothing much there other than the interface, but my intent is to provide a list of draggable
[Radiant] help with dynamic_image extension
Hey all. I'm trying out the dynamic_image extension and I'm running into a small problem. I keep getting unable to open image `/public/ dynamic_images/19b15c4d2dbe9802f43d7a171b27196e.png': No such file or directory: in my output. Now I'm assuming that its a permissions issue but I'm not sure what permissions to give the directory. Or is there something else I'm missing (if it helps, i'm on Dreamhost running Passenger). Any thoughts? Adam ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] SnS Requests Anyone?
Sent from my iPhone On 13-Nov-08, at 9:13 PM, Chris Parrish [EMAIL PROTECTED] wrote: Adam van den Hoven wrote: Things I would like: something like a separate field for copyright notices so that you can minimize the JS/CSS without loosing (someone else's) copyright notice. You can accomplish this today by bundling multiple assets. For instance: --- JS file #1: prototype.js (not minified) --- /* Prototype JavaScript framework, version 1.6.0 * (c) 2005-2007 Sam Stephenson * * Prototype is freely distributable under the terms of an MIT-style license. * For details, see the Prototype web site: http:// www.prototypejs.org/ * *-- --- - */ r:javascript name=prototype.js.content / --- JS file #2: prototype.js.content (this has 'minify?' checked) --- ... the rest of the prototype lib goes in here ... That would serve up the prototype library just as you requested as 'prototype.js' Duh! That never occurred to me. support for external libraries I really just want 1 tag to use for all these assets they can be always as link If you really want to be cool, know ahead of time all the important libraries and their versions (kinda like how the google Ajax Libraries API works -- http://code.google.com/apis/ajaxlibs/) so I can do r:javascript library=jquery version=2.6 minimized='true' / But also just r:javascript url=http://scriptsite.com/ somelibrary / Sounds neat -- though I'm *positive* you don't want me anywhere near any project that requires constant maintenance to keep up-to-date with the latest libraries. Couple of questions, though: * If you know the url, what's the benefit of using the r:javascript / tag? I mean sure, it renders the link for you but that's not so bad to type manually. * How would it be helpful for SnS to have it's own list of libraries when the Google api you offered already does this? I'm really not trying to beat the you can already do this drum, but why not just type: script src=http://www.google.com/jsapi;/script script type=text/javascript google.load(prototype, 1.6); google.load(scriptaculous, 1.8.1); /script Perhaps I'm over doing it. I generally like having on way to do things, so using r:javascript and script together violates my sense of aesthetics. But maintaining a list of libraries is probably bad. How about importing from remote URL so we don't have to download then up load? Or, if you want to keep your list of google.load's in their own javascript file (named, say, google.loads), you could just: script src=http://www.google.com/jsapi;/script r:javascript name=google.loads as=inline / I want to make sure I'm understanding your ideas. (Thanks for the tip on google, BTW. I've never used that and think that it'd be a nice addition -- looks like they even minify stuff for us). I tend to toss ideas out to see what's good or not. This was probably not. What about interacting paperclipped? Not the bucket, per se, but the tags for sure are useful. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] SnS Requests Anyone?
On 14-Nov-08, at 3:01 PM, Chris Parrish wrote: Adam van den Hoven wrote: support for external libraries I really just want 1 tag to use for all these assets they can be always as link If you really want to be cool, know ahead of time all the important libraries and their versions (kinda like how the google Ajax Libraries API works -- http://code.google.com/apis/ ajaxlibs/) so I can do r:javascript library=jquery version=2.6 minimized='true' / But also just r:javascript url=http://scriptsite.com/ somelibrary / Sounds neat -- though I'm *positive* you don't want me anywhere near any project that requires constant maintenance to keep up-to- date with the latest libraries. Couple of questions, though: * If you know the url, what's the benefit of using the r:javascript / tag? I mean sure, it renders the link for you but that's not so bad to type manually. * How would it be helpful for SnS to have it's own list of libraries when the Google api you offered already does this? I'm really not trying to beat the you can already do this drum, but why not just type: script src=http://www.google.com/jsapi;/script script type=text/javascript google.load(prototype, 1.6); google.load(scriptaculous, 1.8.1); /script Perhaps I'm over doing it. I generally like having on way to do things, so using r:javascript and script together violates my sense of aesthetics. Ah. Makes sense. Actually I lean towards John and Sean's suggestions that tags not render markup (that way you can use them safely with filters or in pages that aren't html). That's why my tags just render the content by default and offer an as=url to render that property. Whereas the as=inline and as=link are viewed more as bonus or convenience tools. Possibly but I find script src=r:javascript name=foo as=url //script not just unaesthetic, its offensive. If you're using a tag paradigm to encapsulate functional bits, then mixing those tags into attribute values are only confusing and you will not be able to leverage an existing tool (like an extensible XML base WYSIWIG component... not that there are many but I can dream). IMO, if you're following this paradigm you should be thinking in terms of extending HTML not doing something independent of HTML. But maintaining a list of libraries is probably bad. How about importing from remote URL so we don't have to download then up load? Hmm. If you already have a URL why not point your browser there and copy the contents from your browser window (not download into a file). Then paste the body of a new javascript in the Radiant UI? Or do you mean SnS keeping a catalog of URLs so you wouldn't have to know that off-hand? But that's beginning to sound like maintaining a list again. Sorry. I jumped to a new idea. I should have signaled that better ;) I mean that I want to use jQuery and the Metadata plugin. JQuery comes from a public CDN so I can use it externally (unless I'm behind HTTPS) but even if there is a public copy of the meta plugin, I probably shouldn't be stealing someone else's bandwidth. So I need to import that into my machine. Right now, I have to download then upload it. But if I can just point to the tarball or bare code, on the originating server ( and easily update to the latest version) I can save a lot of time. But there is no maintaining lists. I give you the URL of some file or GIT repository which you then download, decompose and copy the contents into the appropriate asset Or, if you want to keep your list of google.load's in their own javascript file (named, say, google.loads), you could just: script src=http://www.google.com/jsapi;/script r:javascript name=google.loads as=inline / I want to make sure I'm understanding your ideas. (Thanks for the tip on google, BTW. I've never used that and think that it'd be a nice addition -- looks like they even minify stuff for us). I tend to toss ideas out to see what's good or not. This was probably not. No worries. I'm the same actually. Sometimes things get clearer in the communicating. It's challenging on my end too because I can come across as beating down all your ideas which can be discouraging. In my book if I throw out 200 dumb ideas and come up with one really usable one, that's a win. So keep 'em coming. What about interacting paperclipped? Not the bucket, per se, but the tags for sure are useful. Big on my list. Same with Page Attachments. So this is brings up something similar to what I just said previously. There are some javascript plugins that you are going to download that have some skinning. So you have javascript, css and images all in one tarball (or something similar)... when you explode the tarball, if you could present a tree view of the data and allow the user to select which bits to import, rewrite URLs in the CSS... Ok. maybe thats WAY too complicated
Re: [Radiant] Importing Exporting
On 13-Nov-08, at 2:00 PM, Chris Parrish wrote: * It's simple (read: non-technical users love it) * It's db-independent so if my local development environment is Sqlite3 but my server is MySQL or PostgreSQL (or I want to change databases/servers some day) it's no sweat to move content around. * It's collects all of the content (this means styles and scripts ala SnS, and whatever fun extensions I choose to add in the future). * My site's content can be fully restored via import. * Ideally it's in a human readable format so if it's kept in an scm, diff tools can identify changes. * Bonus points for packaging all the files up nicely (like a zip or tarball for download). * Bonus points for managing asset files such as images images (though I'm not holding my breath here). It seems to me that you want to keep a copy of everything in an svn repo so why not simply symlink your assets directory from the repository directory and symlink db/export from the SAME repository. Paperclipped (or what ever) will store all its changes in the symlink and the super_export (which is the only one of the two that will work for this) will put its files there too. Now you simply have to svn add and svn commit and you're laughing. Adam ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] SnS Requests Anyone?
Things I would like: something like a separate field for copyright notices so that you can minimize the JS/CSS without loosing (someone else's) copyright notice. support for external libraries I really just want 1 tag to use for all these assets they can be always as link If you really want to be cool, know ahead of time all the important libraries and their versions (kinda like how the google Ajax Libraries API works -- http://code.google.com/apis/ajaxlibs/) so I can do r:javascript library=jquery version=2.6 minimized='true' / But also just r:javascript url=http://scriptsite.com/somelibrary; / Adam On 13-Nov-08, at 3:31 PM, Andrew Neil wrote: I'm getting ready to roll out a new SnS version this weekend with some bug fixes and a column name change (requested and implemented by Andrew Neil to help it work with his file_system extension). As Chris says, I have been working on integrating file_system functionality into SnS. The column name change was simply to avoid a naming conflict between the two extensions, but it shouldn't cause any perceptible change in the behaviour of SnS. My file_system/SnS integration is not ready for release yet, but I shall announce it here when it is. Since I'm doing that, are there any other issues/feature requests out there? Now would be a good time to entertain those. I was going to suggest asset packaging... but then I had another look at the README and saw that it was already there! Cheers, Drew ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Articles extension
Be very careful about this before you go down this road. You may put in more effort than you get put of it. That being said, I'd look at the archive extension. This is probably the route you want to take: modifying the behaviour of a page. This should play well with pages. Adam On 13-Nov-08, at 5:21 PM, Philip Arndt [EMAIL PROTECTED] wrote: Hi everyone, I'm working on a site at the moment where the next thing I'll need to build is an extension to have articles These are pretty much the same as pages but need to have different groupings etc. Does anybody know of any existing extension that will do this or most of this and could be added to? Otherwise, once I'm done, I'll see if I can make what I get done public. But it'd be nice if somebody has already done that! Cheers Phil ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Page Attributes (was: So how did things go this weekend?)
On 29-Oct-08, at 7:21 AM, Josh French wrote: We have a Tag Library that will write out a value of a named attribute, assume the value of the attribute is the path to a JSP and include it, and others that let us do conditional logic (if attribute Foo has a value of bar do this else do that). Andrew and I have been discussing this, and he raises a good point: if we make the data accessible to tags (other than conditionals), these metadata do start acting more as parts/content. Over the weekend, the sprinters had a long debate regarding the use of these page attributes and how they differ from page content, and I think the resolution was that attributes should be used as filters, or to trigger behavior on individual pages, but stop short of being treated as content. To that end, I am envisioning a set of tags that acts on attribute _types_ rather than attribute content, e.g. a conditional tag for booleans; if_before/if_after for datetimes; and so on. There are some things you can do to prevent this from being abused (clearly its only an issue with strings), namely normalize the strings. Not fool proof but doable. We use it largely for conditionals as well. Right now, page parts are inheritable if the usage of the part says so, which is to say that the Radius tag has an attribute called inherit. In our application, we did it the other way. My inclination is to follow Radiant convention, unless someone can convince me otherwise. (I'm a pushover, so have at it.) In some ways its a matter of style. In our world (which is a rather complex business environment) its a HUGE time/cost/complexity saver so I figured I'd share the idea. If I set a masthead_image attribute on page /products/widgets to widgets.gif then every page in /products/widgets gets that value To me, this suggests the possibility of (ab)using attributes as foreign keys (e.g. to an asset stored in another table) as opposed to literals. We wrote an extension for a client that attempts to automagically draw some associations based on introspecting a schema similar to what we're using here, and I still have nightmares about dark things shuffling forth from join tables. So it's not something I was planning on attacking on this first pass, but I definitely see a strong use case for it and if anyone has a strong pattern for accomplishing this, I'd love to hear about it. Again, this may be a difference between Radiant and my world. We don't use a database for anything so there is no foreign key to abuse. Everything is encoded in plain old JSPs and everything we refer to like this is a JSP or a bare resource (like a gif). Adam j ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] So how did things go this weekend?
This is a brilliant idea. I know because I thought of it first ;). In our J2EE application we have a similar concept where any page can have an arbitrary collection of named attributes and we have code that can work with that code. We have a Tag Library that will write out a value of a named attribute, assume the value of the attribute is the path to a JSP and include it, and others that let us do conditional logic (if attribute Foo has a value of bar do this else do that). All of this, I expect, will make its way into radiant, if it hasn't already. There is one piece of behaviour that I suspect you haven't implemented, but which turns out to be VERY useful. Right now, page parts are inheritable if the usage of the part says so, which is to say that the Radius tag has an attribute called inherit. In our application, we did it the other way. When I author a page, I get to say whether or not a attribute is inherited or not (and it defaults to inherited). This allows us to set values for a whole section easily (sparse population of data). It works out the same as it currently does with the parts in radiant with one exception. If I set a masthead_image attribute on page /products/widgets to widgets.gif then every page in /products/widgets gets that value, this is the same. However, I want the masthead_image attribute for /products/ widgets/legal to have a value of pirate.gif but it only applies to that one page and /products/widgets/legal/privacy should have a value of widgets.gif. In our system, we simply flag the attribute on / products/widgets/legal as being local and it only applies to that one page, its descendants get their value from its parent. With the current logic, I would have to go in and set the attribute on each child page and if this is something I need for my visual design, a content author is not likely to know to set the attribute unless I tell them but on any sufficiently complex project that will be difficult to maintain. Adam On 28-Oct-08, at 7:04 AM, Josh French wrote: Josh French -- please fill us in on what you and your group did on Saturday; I missed a lot of that. Andrew O'Brien, Mike Hale, Luke whose last name I am blanking on (apologies), and myself started work on extending the page class to accept arbitrary attributes -- booleans, integers, timestamps, c. This pattern shows up in numerous extensions and we saw a need for a generalized solution. The primary goal was to expose a number of simple object types (single-dimensional data, like the existing metadata fields) and allow these to be managed via a mechanism similar to the page-parts interface. We're also aiming for a solution that can eventually be extended to accept complex data structures. You can follow our progress at http://github.com/jfrench/radiant-page-attributes. j ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Weekly wacky suggestion
Jay, I think its a good idea to make things unambiguous but taggs just feels wrong. Why not reuse taglib from J2EE? They're basically the same thing as our tags Sent from my iPhone On 25-Oct-08, at 5:56 AM, Jay Levitt [EMAIL PROTECTED] wrote: The term tags is, of necessity, overloaded in Radiant; we have Radius tags, and we have radiant-tagging-extension tagging as in '2.0' and tagclouds tags. That makes it difficult to search for questions, blog posts, etc. on either type of tag. But tags is the right word; it's what everyone else uses, and making up a new term would be both futile and confusing. Why not refer to the radiant-tagging-extension tags as taggs? The meaning is still clear, but it uniquifies the tagcloud meaning (modulo the occasional misspelling). Jay PS - Yeah, I'm procrastinating; what's it to you? PPS - I'm not sure if this suggestion would imply that the radiant- tagging-extension should be renamed to radiant-taggging extension... ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] [ANN] Conditional Tags Extension
On 23-Oct-08, at 9:46 PM, Chris Parrish wrote: Adam van den Hoven wrote: What I mean is: 1) I decide to use your tag instead of creating my own special purpose if_ and unless tags. I document it in my README 2) Like some existing extensions do, I inject a page or a snippet or a layout into the database that uses my extension and yours 3) A user installs my extension because my announcement was so mind blowingly awesome but doesn't really read the README 4) The user's site blows up because your extension is missing The problem isn't with your extension. The problem is that there is no standard way, no best practice to ensure at some point that the requirements are met and gracefully allow the user to remedy that. Its a Radiant problem. Why not test for your extension's dependencies on load? For instance, my soon-to-be-announced variables extension has the following line in the activate method for the extension: raise The Variables Extension requires that the Conditional Tags extension be loaded first unless defined?(ConditionalTags) Sure that works except that it is entirely too late IMHO. It should be raised when you install the extension (say in the update or migrate tasks) since that is when you are dealing with extensions. If you were to do that for a live site running passenger then suddenly your production site is down. You could argue that there are better ways (I'm not convinced that capistrano is reasonable approach for someone who isn't a dedicated Ruby coder) but it is a reasonable way (especially for a savvy non-coder), which is why I wrote documentation for just that sort of approach. -Chris ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] [ANN] Conditional Tags Extension
Chris, I love the idea you've got going here. I haven't had a chance to try it but I have a few thoughts: While the proliferation of tags can be bad for users, Radiant lacks any mechanism for ensuring dependancies are installed making using this extension within my own potentially destabilizes my extension. This is a sufficiently fundamental thing that I'd be happier to see it rolled into the core than distributed as an extension. The examples in the readme all refer to things that are properties of the page. It would be useful to better explain how something other than the property of a page can be referred to. As an aside, I think that there is a place for purpose specific conditional tags. Personally I'm not convinced that r: if cond=content['body'] exists? blah /r:if is more readable than r:if_content / to someone who isn't already a developer of some sort who understands what a conditional is. For example, I use Radiant for websites for a website that is managed by a bunch of grey haired folk who think about authoring for the web as a page was a piece of paper they put in their typewriter (figuratively, fortunately). Radiant is a great tool for these sorts of people, who legitimately need a good website but shouldn't have to pay me to $100/hr to type in their content. I've shown them how to create pages and write using Textile (which is nearly perfect for this... unless I can ben one of the WYSIWIG plug-ins to my will). Tags are not for them (fortunately). If these folk ever write any sort of tag, after I pick myself off the floor I'll have to go ask them what they're doing and try to do it properly. There are other classes of user between them and extension authors (notably people who are not developers by trade but are hacking with radiant to get things done) for whom purpose specific tags, while limiting, can be a great aid to doing useful and interesting things. I think that there is a place for these tags and I'd love it if there was an easy way to use this to create both if_ and unless_ tags. Something like: conditional_tags my_tag do |tag| #return a boolean false end which would then create if_my_tag and unless_my_tag tags. For the if_ tag, the contents of the tag is executed when block returns true, and the reverse happens for the unless_ tag. This syntax combined with your generic tags would probably provide the right level of excellence for all classes of user. Now all we need is to simplify looping, another common tag type that could be simplified for extension authors. A On 23-Oct-08, at 9:55 AM, Chris Parrish wrote: Hello all. I'm finally releasing an extension that I've mentioned over the last year on the list. I think that it has a lot of power and potential but I could use some input from the Radiant clan. The Conditional Tags Extension (http://github.com/SwankInnovations/radiant-conditional-tags-extension/tree/master ) creates r:if and r:unless tags that allow for flexible (and customizable) conditions. Start with the README there -- it covers what I'm thinking and a lot of what this thing can do. I want this extension to be very easy to use for users (read: non- developers) and also helpful to developers (I wrote it so that your extensions can plug into the conditionals framework to easily add your own values). Please help me make this one as useful as possible. Thanks, Chris BTW, I apologize if this ends up being a double post. I think I goofed something up when I sent it last night so I wanted to make sure... ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Re: script/extension install in production mode
Ben, If you look at the article on setting up radiant on Dreamhost, you'll see that I only install Ray using script/extension and after that I would use: rake production ray:ext name=gallery hub=pilu fullname=radiant-gallery There is nothing special about DH in this respect, I would suggest it to anyone. On 12-Oct-08, at 9:32 PM, Ben Morrow wrote: john wrote: Looks like you should also be able to set ENV['RAILS_ENV'] ||= 'production' Thanks for the suggestion John, but I already uncommented that line. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Re: [Radiant-Dev] Installing Radiant on Dreamhost with SSH
Clearly the wiki likes me better ;) On 10-Oct-08, at 9:14 AM, Tim Gossett wrote: On Fri, Oct 10, 2008 at 11:54 AM, Tim Gossett [EMAIL PROTECTED] wrote: I've made a couple minor edits to streamline the process. Thanks, Adam. Well, nevermind... my edits didn't work. -- Tim ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] [Radiant-Dev] Installing Radiant on Dreamhost with SSH
On 10-Oct-08, at 8:54 AM, Tim Gossett wrote: On Thu, Oct 9, 2008 at 11:11 PM, Adam van den Hoven [EMAIL PROTECTED] wrote: I've put a new article on the wiki at http://wiki.radiantcms.org/Install_Dreamhost_Using_SSH that outlines how to get radiant running directly on dreamhost without using sftp or Capistrano. It strikes me as the approach to take for someone who is using Radiant as just a CMS; that is someone who just wants to get to the point of writing HTML, CSS and JavaScript as quickly as possible and then hand off the whole thing to the content authors. Nice timing. I was just gearing up for a 14-hour Saturday in which I plan to go from registering a domain name to having a finish Radiant site on Dreamhost. Hopefully you've only got a 12 hours and a little less pain. Oh yeah. Its written in a rather personal style which someone may want to change. And its very opinionated in that I list 10 or so extensions that every installation should have... unless you have a compelling reason not to use one but then you're probably not the target audience for this article. ;) I suppose I should get my fork of Chris Parrish's SnS SVN repos updated since SnS and SnS Minifier are #9 #10. I'm going to add SnS Sass filter since I personally believe that every web developer everywhere should be using it. I do hope that the list of extensions everyone needs stays short. Me too. I don't have much (any) experience writing rake tasks but I think that one could create something to do the following: rake dh:bootstrap setup=empty dbHost=mysql.example.com dbUser=example dbPass=password I think that we're almost to the point with extensions that there is not enough tab space at the top any more (on a smallish screen there isn't). I know there's a UI refresh comming up and I hope to see a 2 level hierarchy (that is you add your extention to a child of a tab). Hopefully that will help wrangle the kittens I've made a couple minor edits to streamline the process. Thanks, Adam. -- Tim -- Tim ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Using one filter by default
I wonder if it would be possible to hook up the rake tasks for Ray to the UI (at least for those of us who aren't in a load balanced, multiple server situation) such that clicking the Disable button calls rake ray:dis name=some-extension and the Enable button calls rake ray:en name=some-extension. On 2-Oct-08, at 5:07 AM, Sean Cribbs wrote: This was removed way back in 0.6.5, primarily for technical reasons -- unlike PHP, you can't just make the change and expect it to take effect on the next request (without some knowledge of the deployment strategy). Sean Mohit Sindhwani wrote: Pacifists wrote: About your last suggestion - I've noticed that in 0.6.9 there are no checkboxes anymore to disable the extensions as it was before. That always looked strange to me, but I've never bothered to ask before. I hadn't noticed that you can't disable an extension from within the Admin area. I wonder why. I guess this has to do with the ability to set things at the command line but I don't know how that is done (never needed it). Cheers, Mohit. 10/2/2008 | 12:36 PM. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Re: google analytics as extension
Jasper,
I believe that Marcus' point was that instead of hard coding it into
the HTML, that you write some JavaScript code to do it for you.
Something like this should be more than fast enough for your needs:
(function (){
//Always isolate your JavaScript from the global scope
var links = document.getElementsByTagName(a),
this_host = window.location.host;
for (var i = links.length - 1, lnk; i = 0; i--){
lnk = links[i];
if (lnk.host !== this_host) {
lnk.onClick = pageTracker._trackPageview('outbound/ +
lnk.href + ');
};
};
})();
I haven't tested it but it should work, more or less correctly. You
could use a library to set the event, if you like, but looping through
the anchors this way is the fastest possible way to do it.
Adam
On 30-Sep-08, at 9:59 PM, Jasper Kooij wrote:
Hi Marcus,
How is the above ga tracking different from the new ga.js? That's the
one I'm using on my wordpress where I can specify by means of a
pluging
van joost de valk.
Here is the screenshot of the settings in wordpress for example using
the ga.js to tag:
http://screencast.com/t/l3orhxHo3wq
I'm not trying to reinvent the wheel, just measuring on a website
what's
working and what's not.
the outbound tag in
pageTracker._trackPageview('outbound/http://davidseah.com/blog/the-printable-ceo-series/')
and simply be replaced by a preset or specified one. I've checked the
analytics and the tagging works well that way.
The only thing is that the JS code needs to be loaded before the
pageTracker is being called.
So I'm going through the tutorial in creating an extension at the
summer
reboot http://wiki.radiantcms.org/Creating_an_extension_I
Jasper
--
Posted via http://www.ruby-forum.com/.
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
___
Radiant mailing list
Post: Radiant@radiantcms.org
Search: http://radiantcms.org/mailing-list/search/
Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] How to turn off markdown filter in Radiant 0.6.9 instance
On 22-Sep-08, at 1:46 PM, Sean Cribbs wrote: Jason Garber wrote: If you have a Radiant instance running off the 0.6.9 gems, how can you disable the markdown extension? I don't want my users to have the option of using Markdown or SmartyPants text filters. It used to be that you could deactivate the extension in the admin UI, but that appears to be gone in this version. If the answer is, you can't disable it, would you be open to me writing a patch that moves the markdown and textile extensions from the gem into the instance and prompts the user for which text filters he wants to install when he creates an instance with the radiant command? Or, no prompt; just delete the ones you don't want. The answer is to remove it from the list of extensions in environment.rb, which by default is [:all]. So if you only wanted archive and textile_filter, you'd put: config.extensions = [:archive, :textile_filter] It seems to me that it is reasonable to want to say enable all extensions except these four. With this approach, you have to edit the environment.rb each time. On that note. Does anyone know, can Ray disable/enable/uninstall extensions that it didn't install (say they came with the install or were installed from svn)? If so, then the easier solution would be: rake ray:dis name=markdown_filter Personally I like using rake for this sort of thing: rake ray:ext name=foo feels more right than script/extension install foo. Sean ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] [ANN] Radiant Template Contest
Maybe we need to run a T-Shirt Design contest first/simultaneously. The winner could get a copy of the winning theme... printed on a T- Shirt. :) Adam On 18-Sep-08, at 9:03 PM, Sean Cribbs wrote: Steven Southard wrote: I'd love to win the contest and have my design included in upcoming releases and this isn't going to stop me from entering in any way, but that t-shirt could use some work. I'd probably wear like it is because I'm crazy about Radiant; so whatever, forget that I said anything. Steven That was a VERY rough sketch that I did in about 10 minutes. Any constructive criticisms you have would be appreciated. Sean ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] New metatags for keywords, description feature
Jim, Where I work, I designed our system such that we have an in-memory representation of all the nodes in our site which was (somewhat) independent of the index.jsp that defines the node. We hang a lot of metadata off these nodes, a lot of which is inferred. This lets us do things like have a multilingual site (simply create index.jsp and index_fr.jsp or index_xu.jsp) and so on. One of the most useful idea we included (at least in so far as this thread is concerned) is the idea of node parameters. These parameters are name/value pairs associated with a node and can be used for absolutely anything you want (the list of parameter names is arbitrary). The useful bit is that when you define the parameter, you can say if its inherited no not. This is sort of the opposite of how this sort of thing is done in radiant where its the usage of something (a page part or a meta) that specifies if its inherited, I specify that at definition. This has a big advantage: sparse population. This lets me set a default on some node (say the root) and have it inherited. I can then change it for some descendant (so far no difference). However, if I want that change to ONLY affect that one page and not its parents, setting the value to being local (not inherited) means that the original value will be used for the children of the page that overrides the value. Since we use these value for more than merely creating HTML Meta tags, this becomes very useful. i would suggest that in addition to tests to see if meta is set (or not) that you include tests for the value. This will allow for some very interesting behaviour. On 22-Aug-08, at 9:56 AM, Jim Gay wrote: I'm resurrecting this thread so that I can express my personal hatred of the meta tags. I propose that they be removed, or handled in a different way (and yes I volunteer myself to write the code for it). I'll be doing some thinking about meta and how to better handle the many options for HTML, but if anyone is interested, I created this extension http://github.com/saturnflyer/radiant-seo_help-extension/tree/master which provides an inherit attribute on r:meta and adds r:if_meta and r:unless_meta -Jim On May 19, 2008, at 4:13 PM, Chris Parrish wrote: I can't speak for the core team but I wrote my own extension to do the same thing for clarity and simplicity in the UI. Page parts are for the page content (body) and the the other fields are for meta-data (kind of like HTML's head vs. body). It could be done without (for Radiant or HTML) but is nice for organization and comprehension. But you are right -- it's all just data. In fact, Radiant could move the slug, breadcrumb -- any field really -- into a page part and it would still be workable. my $.02 (though probably overpriced). -Chris On May 19, 2008, at 4:02 PM, Jim Gay wrote: Given the debate about how to implement an inherit functionality for something that already exists with r:content, I'd say this is bloat. I think there is a benefit in the user interface though, to have a text field rather than a text area to manage a small amount of content so I could be persuaded to leave it in for that reason. But I think that another option there might be to simply create a new way to add page parts in text fields near the title area (I don't recall what shards calls it). Add a part as a big text area in the tabs or add it as a text field. They could be functionally the same, but depending on the scenario they encourage (or discourage) a user in entering a certain amount of text. I use page parts on the home page, for example, to allow users to alter things like the footer text on their site. Adding Copyright 2008 Super Happy Funtime Inc. in a big text area isn't ideal (because of the size of the text vs the size of the area given) but it does the job. And it easily is inherited on every page. I recall seeing the request for r:meta on Trac a long time ago and just figured it wouldn't be added. I think, however, that something like a truncate attribute makes sense even for both cases... You can have users fill out a description part, or just use the first 50 characters (for example) of the body and use that in your meta tags. This would of course cause problems with HTML being entered so that would take a little more thinking. Having said all of that, I don't think its a major detriment that it exists, but I don't think it is necessary and probably shouldn't exist in the future. Should I feel out of place in this conversation since my last name isn't Cribbs? ;-) -Jim On May 19, 2008, at 3:34 PM, Sean Cribbs wrote: Jamey, That's great. In response to Jim, it was a common enough use case for people who do SEO for their sites and such a low overhead to implement, it seemed like a reasonable thing to add. I'd appreciate debates on this matter, however, as I'm open to culling
Re: [Radiant] Re: Disabled tabs in radiant backend
I think you've hit on something. its probably reasonable to assume that the common default installation is going to be someone who's using it for their own website. One user means one role so take the admin/developer/user behaviour out and move everything into an extension. That extension would be an expanded version of page group permissions. The only thing I would do is configure the core behaviour such that any other extension developer could specify group permissions without requiring a group extension installed (sort of how the help extension allows developers to add Help without requiring that help exists). Radiant can specify a core API for the role behaviour (so that anyone can create any role extension they desire) so that we can all work together. I'd actually suggest doing the same thing for user management. That would allow us easily create an OpenID user extension or extend users from Admin into pages. But that's a different thread. On 7-Aug-08, at 9:33 AM, Arik Jones wrote: Why isn't anyone extending on top of Page Group Permissions. I think that framework can be used across the board. What do you guys think? Personally I think the role administration in Radiant is rather lacking and for good reason. However, the rest of us need something. I love what Page Group Permissions has done. Solved a huge problem. But I think it could use some expansion in terms of what you're giving permissions to. Maybe eventually it could replace the current core role admin scheme. Thoughts? -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Re: Re: Disabled tabs in radiant backend
That's a good question. Perhaps, though, the question should be posed on the radiant-dev list instead? Its never clear which list is for what since they both seem to cover the same topics but it feels to met that this question (at least a discussion fleshing out the API and what not) properly belongs there? A On 7-Aug-08, at 10:36 AM, Arik Jones wrote: Adam van den Hoven wrote: I think you've hit on something. its probably reasonable to assume that the common default installation is going to be someone who's using it for their own website. One user means one role so take the admin/developer/user behaviour out and move everything into an extension. That extension would be an expanded version of page group permissions. The only thing I would do is configure the core behaviour such that any other extension developer could specify group permissions without requiring a group extension installed (sort of how the help extension allows developers to add Help without requiring that help exists). Radiant can specify a core API for the role behaviour (so that anyone can create any role extension they desire) so that we can all work together. I'd actually suggest doing the same thing for user management. That would allow us easily create an OpenID user extension or extend users from Admin into pages. But that's a different thread. I completely agree. I wonder what Sean Cribb's perspective is on this?! I'd love to see him chime in. -- Posted via http://www.ruby-forum.com/. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Re: Radiant Browser Support -- Drop IE6?
On 21-Jul-08, at 12:42 PM, Tim Gossett wrote: On Mon, Jul 21, 2008 at 12:04 PM, David Piehler [EMAIL PROTECTED] wrote: Chris Parrish wrote: Would anyone be left out if Radiant failed to support IE 6? I vote to drop IE6 to coincide with the new Radiant UI release and move IE6 support to an extension. I vote the same. And where can I register my extreme disgust for IE's (lack of) CSS support, anyway? You could try the IE blog but /dev/null will be more effective. Actually I suspect that when IE8 comes out the won't be nearly as craptacular as its ancestors and almost reach respectability. Passing ACID 2 goes a long way in my books (by comparison to IE6). -- Tim Gossett ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Radiant Browser Support -- Drop IE6?
You might want to try this: http://ajaxian.com/archives/iepngfix-2-now-supports-css-background-position-and-repeat I haven't tried it but it looks promising. Adam On 21-Jul-08, at 1:35 PM, Chris Parrish wrote: I can get PNGs to work just fine with IE 6 via pngfix.js or just using IE's proprietary filters in the CSS. But you can't do any fancy positioning -- just left/top aligned images for backgrounds. There are other ways to skin that cat, so there should be a solution there somewhere. I just don't want to have to support or maintain it. There will be other issues that crop up before we're done, I'm sure. -Chris Nate Turnage wrote: On Mon, Jul 21, 2008 at 9:38 AM, Chris Parrish [EMAIL PROTECTED] wrote: So, I agree with John Jim that we should shoot for IE 7+ support with the ability to add in IE 6 as an extension. Besides, I'm working on some of the harder parts now and it's looking like PNG support may be the only limitation (I had other ones in mind when I asked this I always use pngfix.js to get IE6 to work with transparent png files and it works like a charm. Find it here: http://homepage.ntlworld.com/bobosola/index.htm ~Nate ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Radiant Browser Support -- Drop IE6?
I say release without IE6 support and then create a Legacy Admin UI extension to add support for IE 7, WebTV and other fringe user agents. Adam On 19-Jul-08, at 12:49 PM, Sean Cribbs wrote: I'm of the opinion that IE6 is going the way of the dinosaur. Unless your client absolutely needs it, I would avoid bending over backwards for it. IE6 support on the front-end is a different story (alas you may need at least minimal support for it -- still has approximate 25% market share), but I think it's reasonable to require modern browsers for the admin UI. Sean Alex Wayne wrote: I would dance a god damn jig. Seriously though, I think public sites still need to support IE6. But gated admin areas that have a small number of users, I think its fine to declare IE7 the minimum. And, if we're lucky, the rest of the internet will follow suit. -Alex http://beautifulpixel.com On Jul 19, 2008, at 11:39 AM, Chris Parrish wrote: I have a question for all the Radiant users out there... Would anyone be left out if Radiant failed to support IE 6? I am working on some UI/CSS improvements for Radiant which require hacks and workarounds to support this browser. It can be done but I'm not sure it's worth it. IE 8 is already in beta and IE 7 is freely available for all but Windows 2000 -- and that OS is 8 years old (benefits of a public education right there, baby). And Win2k can easily install Firefox, Opera, or Safari so it's not like they're stuck. Thoughts? -Chris P.S. Please don't waste bandwidth with Microsoft or IE bashing (I'm not interested in why everyone should use insert your favorite browser here). I just want to know whether it would be a problem for Radiant admin users to need IE 7+. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Forum extension?
Since were green fielding this: Threaded Moderable Sticky Posts Post Types (question, announce, etc, = configurable list) Multiple Fora (Forums?) Forums in arbitrary places (maybe I have an corporate internal site with section for each project, I might want a unique set of forums for each project) Taggable threads Forum Users independent of Site admin/content authors. However, site admin/content authors should not need new user for posting. Spam Filtering On 10-Jul-08, at 11:29 AM, Tim Gossett wrote: I need to add a forum to a Radiant project. I've sifted through plenty of pages of search results for Radiant forum extension, but, frankly, there's just too much noise coming from results for forums about Radiant. If I can't find one by tonight, I'm going to build my own. Anyone have any ideas/requests/observations? -- Tim ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] Forum extension?
At this point would it not make sense to extend the user system to support Open ID? On 10-Jul-08, at 8:11 PM, Mohit Sindhwani wrote: Josh Schairbaum wrote: I'd be more willing to help write something that would sync user accounts between radiant and beast. :) Not-optimal, but probably the quickest for getting something with a lot of features out there quickly. I believe that if you used cookie sessions and had both apps share the same session key it would simulate SSO. Josh That would be very very cool! Cheers, Mohit. 7/11/2008 | 11:11 AM. ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] if_content with inherit
Actually I think you need to rethink things a bit. Specifically, I think that specifying multiple parts should be handled in an OR fashion. The reason is that there would be no way to create a div.sidebar if either a marketing or callout part exist and then put one or both of those part into the div. This is a completely reasonable use case (IMHO). At the same time, you can preserve the AND behaviour by nesting r:if_content tags. As you've proposed, I can see no difference between: r:if_content part=this, thatStuff/r:if_content and r:if_content part=thisr:if_content part=thatStuff/ r:if_content/r:if_content And that suggests to me that applying an OR to the first case is a useful idea. As to how inherit should work, I think you're on the right track; look for each part independently. Otherwise the following would not behave as you'd expect: r:if_content part=this, that inherit=true r:content part=this inherit=true /r:content part=that inherit=true //r:if_content Adam On 7-Jul-08, at 5:29 PM, Jim Gay wrote: I'm working on this feature, but one of the main reasons I put this out to the list for feedback is that it can become confusing, so I wanted to see if anyone else had thought about this. The next version of Radiant (0.6.8) will accept a list of parts in if_content r:if_content part=this, that It will display the contents only if all of those parts exist. This is useful for outputting information from customers (for example) where you want to display the customer description part only if it also has a testimonial part. If only some but not all of the listed parts are found, it will display nothing. In light of that, how would you expect inherit=true to work? Would you expect that it looks up the tree for the existence of each part no matter where in the tree that part is found? Or would you expect it to look up the tree to find any page that has all of the listed parts? My inclination is to make it look up the tree for each listed part regardless of the location of other parts, and as long as it finds all of them, it will output the contents of the if_content tag. I personally have had the need for r:if_content part=this, that r:if_content part=this inherit=true But I have not had the real-world need for r:if_content part=this, that inherit=true I'm working on it slowly to allow myself time to consider the pros and cons and to allow anyone to jump in with ideas before I get too far. I'd appreciate more feedback. On Jul 7, 2008, at 7:04 PM, Adam van den Hoven wrote: There are few things that make me more grumpy that empty elements that server no useful purpose. I'd love it. On 7-Jul-08, at 12:56 PM, Jim Gay wrote: Is there any interest in adding the inherit attribute to the if_content tag? In some instances I'll find the need to output something like div id=extras r:content part=extras inherit=true / /div But I don't have a way to conditionally render the div id=extras bit. If the parent or current page has an extras part, then it will appear, but if it doesn't I'll have an empty div element. Is there a simple way to handle this or would r:if_content inherit=true be a clear and welcomed addition? -Jim ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] if_content with inherit
I have to agree with Tim in this. I'm traditionally bad at picking names for things like attributes but I think that its critical that the meaning be clear; Find and collect strike me as being ambiguous, I though of require but that's overloading an important word. Adam On 8-Jul-08, at 10:25 AM, Tim Gossett wrote: Or better yet r:if_content part=this, that collect=all #this being the default r:if_content part=this, that collect=any Or r:if_content part=this, that find=all #this being the default r:if_content part=this, that find=any This looks like the best solution to the AND / OR discussion. -- Tim ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
Re: [Radiant] if_content with inherit
There are few things that make me more grumpy that empty elements that server no useful purpose. I'd love it. On 7-Jul-08, at 12:56 PM, Jim Gay wrote: Is there any interest in adding the inherit attribute to the if_content tag? In some instances I'll find the need to output something like div id=extras r:content part=extras inherit=true / /div But I don't have a way to conditionally render the div id=extras bit. If the parent or current page has an extras part, then it will appear, but if it doesn't I'll have an empty div element. Is there a simple way to handle this or would r:if_content inherit=true be a clear and welcomed addition? -Jim ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant ___ Radiant mailing list Post: Radiant@radiantcms.org Search: http://radiantcms.org/mailing-list/search/ Site: http://lists.radiantcms.org/mailman/listinfo/radiant
