# Repost: KCKCC redesign and RadiantCMS **URL:** \ **Category:** Radiant CMS\ **Created:** [January 19, 2007, 4:29pm UTC](https://www.ruby-forum.com/t/repost-kckcc-redesign-and-radiantcms/82347 "2007-01-19T16:29:29Z")\ **Posts on this page:** 1\ **Page:** 1
**Author:** ![smc7000](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/s/ed655f/32.png) [@smc7000](https://www.ruby-forum.com/u/smc7000)\ **Post date:** [January 19, 2007, 4:29pm UTC](https://www.ruby-forum.com/t/repost-kckcc-redesign-and-radiantcms/82347/1 "2007-01-19T16:29:29Z")
First, my apologies to those who are also on the Ruby On Rails Higher Ed list for reposting this. I thought you guys might find it interesting, and evidence that Radiant is ‘production-worthy’. ## Cheers, Sean Jason, Sure! I actually have a set of blog posts I want to write about building the site, but having just released it last week, we’re swamped with change requests and irate staff. (You know how it is!) But I’ll give you the sort-of-short version. Using Radiant for the live site was not our first choice. We wanted to purchase a very expensive enterprise-level CMS, but the funding or the will to pay for it just wasn’t there. After we were forced to find an Open Source alternative, the only option that had most closely met our requirements was ezPublish. However, we quickly found that it was a pain to use and too inflexible (or too flexible? I’m not sure) and the performance would be abysmal. So in the end we chose Radiant, partly because of its ease-of-use, and partly because I had enough experience with it and with Rails to build anything extra we needed. We had also used Radiant for prototyping our navigation design for usability testing, so some of the team was familiar with it. Luckily, just before we began building the site, Radiant’s up-and-coming extension system came to a stage where it was workable, so I took the plunge. While the rest of the team worked on sanitizing content, I built several extensions and along the way found some bugs and submitted patches to the core. On the live site there are six extensions that I wrote or ported: 1. Events calendar - powers the academic calendar page and some dates here-and-there. It’s a basic CRUD application with Events belonging to multiple Calendars, etc. It implements basic tags for accessing the data that can be used in any page. 2. Expiry tags - just two tag definitions that allow you to have time-sensitive content. Based on my most recent blog post to [radiantcms.org](http://radiantcms.org). 3. Mailer - a port and modification of Matt McCray’s original Mailer behavior. This is in use ALL OVER the site. Except for very few cases, where there’s a form, it’s the Mailer extension. 4. LDAP/Personnel Directory - One of our major goals was to stop being responsible for keeping personnel data up-to-date on the site. So we worked with the IT people to get full-read access to the Netware directory. This is a combination CRUD/integration extension. I created saved or “canned” LDAP queries that could be run easily from a tag in any page. The admin interface is neat too because it uses Ajax to allow you to test your query as you are creating it. 5. Search - based on the old, original Search behavior, except I stripped out the live-preview functionality and added a little tag for truncating and stripping tags from results pages (so you can see a little snippet like Google shows). In the future, I’d like to port the acts\_as\_ferret version, as it will produce more reliable results. 6. Syllabi - One of the mainstays of the old site were the “course descriptions”. This extension combines a basic CRUD app (3 models - Prefix/Department, Course, and Syllabus (acts\_as\_attachment)) with two special page-types that assist in displaying the syllabi. One page just lists the prefixes with links to the virtual subpage which displays the individual courses and links to the syllabi. This one deserves a detailed blog post. As I mentioned, constructing all of these made me even more intimate with the source code of Radiant. Thus, I found bugs and submitted these patches: 1. Added a Rake task for running tests in your extensions and fixed the generated test\_helper.rb 2. Fixed some Javascript issues with showing/hiding the slug/breadcrumbs in the Page edit view. 3. Factored out the SiteMap Javascript class into a separate file, rather than being at the top of the template in the Page edit view. Just last week, John L. accepted me to the core team, so I’ll be squashing more bugs in the future. Now, the big problem everyone has with Rails apps is how to deploy. Because I had tried it out and loved it, we went with Litespeed server. It’s practically a no-brainer to set up Rails applications and its speed executing Rails and PHP scripts is legendary — something like 30% faster than FastCGI! It’s been awesome having a web-based admin that makes sense and is easy to use, too. So far, we have had NO problems with it. Probably the best part is no zombie FCGI processes! So, it looks like I made the short story long. Overall, Radiant has worked beautifully for us. Our whole team has enjoyed using it, and it’s like night-and-day from what we used to do. I would highly recommend it to others with this caveat: Radiant is not at the stage where people who are not especially computer and web-savvy should be entering content. Although it is a boon for web developers and designers, it would scare away the poor Math department secretary. It also has a long way to go in terms of providing flexible user-privileges, although I could see an extension handling that. But if you have a ticket/change-request system already, it will make edits that much faster because you don’t have to FTP them up to the server. The only other thing that I think it lacks is a nice asset-management interface, but there are a few extensions out there for it and I have one of my own up my sleeve. In terms of Radiant’s longevity, who can say? I think it is gaining momentum, but even if it weren’t I wouldn’t worry as much because it is open-source. Moving to something else in the future is always going to be painful, but we felt Radiant’s hands-off approach to managing content would ease a transition because the content is so close to the rendered page. Hope this answers your questions… Cheers, Sean C. Web Services, KCKCC [http://www.kckcc.edu/](http://www.kckcc.edu/) > > > removed\_email\_address@domain.invalid 1/6/2007 9:03 AM \>\>\> Sean, Congratulations on finishing the KCKCC site redesign! If you have a few minutes, would you mind sharing a bit on how it went? I see that you used RadiantCMS and I’ve seen your posts on the Radiant blog, so I’d like to hear about your use of Radiant: how well it’s worked, how you’ve extended it, how content creators have accepted it, etc. Would you recommend it to others? Where does it fall short? Is it something you predict will be around for a long while (increasing momentum) or will it die off in a few years and require a painful transition to something else? Hope you don’t mind sharing your experience with this group. Thanks in advance! Jason G. Eastern Mennonite University