# What I don't like about Radiant **URL:** \ **Category:** Radiant CMS\ **Created:** [October 27, 2010, 11:12am UTC](https://www.ruby-forum.com/t/what-i-dont-like-about-radiant/198150 "2010-10-27T11:12:45Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![Dobai-Pataky\_BSSSSl](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/d/77aa72/32.png) [@Dobai-Pataky\_BSSSSl](https://www.ruby-forum.com/u/Dobai-Pataky_BSSSSl)\ **Post date:** [October 27, 2010, 11:12am UTC](https://www.ruby-forum.com/t/what-i-dont-like-about-radiant/198150/1 "2010-10-27T11:12:45Z")
Folks, this is not about bashing Radiant. Instead, I’d like to mention a few things that make it harder to sell Radiant-based solutions to customers who often answer “Why don’t you use Wordpress for the job?” (1) Radiant is like a toolbox for websites, but not quite. From a developer perspective, Radiant doesn’t stand in the way while I’m building the next great website for a customer. It’s a great tool to build and develop. From a customer (aka. “end user”) perspective, Radiant is a bunch of input boxes where you have to enter cryptic stuff which looks a lot like code. Well, in fact it is. Thats why some of my customers wouldn’t ever trade in their wordpress UI for a nifty Radiant site. Which is a shame because they could do so much better. How can I sell Radiant to users who don’t recognize the simply aesthetics of Textile {or any other markup}? (2) Core Radiant isn’t enough to build a real-world website. HTML, javascript, css and images, that what you’ll typically need. Radiant (at least edge) handles the first three pretty well, considering (1). For images, you need the paperclipped extension. Why isn’t this core functionality? And even it it was: URLs like /assets/47/some\_image.png contain that database id, which changes with every installation and make them hard to remember. (3) Upgrading is a pain. Even if I dont like it: Upgrading Wordpress is a breeze. Upgrading Radiant usually involves SSH connections, terminal commands, some gem handling and server restarting. Not a breeze, not at all. I can do that, but end users typically can’t. How do you think about this? I’d love to contribute to make stuff easier, but I’m not sure where to start. Any comment is welcome. Kind regards, Christian p.s.: Will be at ArrrrCamp tomorrow. Who else? ---
**Author:** ![Christian\_Aust](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/5daacb/32.png) [@Christian\_Aust](https://www.ruby-forum.com/u/Christian_Aust)\ **Post date:** [October 27, 2010, 5:04pm UTC](https://www.ruby-forum.com/t/what-i-dont-like-about-radiant/198150/2 "2010-10-27T17:04:19Z")
On Oct 27, 2010, at 4:11 AM, Christian Aust wrote: > tool to build and develop. From a customer (aka. “end user”) > Radiant (at least edge) handles the first three pretty well, > do that, but end users typically can’t. > > How do you think about this? I’d love to contribute to make stuff > easier, but I’m not sure where to start. Any comment is welcome. > Kind regards, > > Christian > > p.s.: Will be at ArrrrCamp tomorrow. Who else? > > Upgrading Radiant usually involves SSH connections, terminal > > commands, some gem handling and server restarting. Not a breeze, > > not at all. It’s also likely that you’ll have to update a couple extensions before it’ll restart. ---
**Author:** ![Christian\_Aust](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/5daacb/32.png) [@Christian\_Aust](https://www.ruby-forum.com/u/Christian_Aust)\ **Post date:** [October 27, 2010, 5:39pm UTC](https://www.ruby-forum.com/t/what-i-dont-like-about-radiant/198150/3 "2010-10-27T17:39:31Z")
Regarding your concerns. 1 - I think the beauty of Radiant is that because it’s so developer friendly it’s up to _you_ to make sure it does what your customers want it to do. The best case study I could possibly come up with is with my least computer-savvy clients using it daily, and loving it. I sat them down in front of Drupal, Wordpress and Radiant and more often then not they’ve picked Radiant. Wordpress is great if you know where everything is, but if not - good luck to you. Same with Drupal. re: cryptic code - have you tried the wym editor filter? [http://ext.radiantcms.org/extensions/125-wym-editor-filter](http://ext.radiantcms.org/extensions/125-wym-editor-filter) And for what it’s worth, printing out a textile or markdown cheat sheet for a customer will get them a lot farther with a lot more control. I guess it all depends on how willing and progressive your clients are? If they’re stubborn then, yeah, it’s difficult. 2 - I agree. But core radiant alone isn’t what you should be using to build a real-world website. If you’re reluctant to find the extensions that help flesh out the rest of the requirements then … well, I don’t know what to tell you. 3 - Set up a staging environment. Use source control. Develop a process. It’s not _that_ hard once you get it down. I push code and an entire database to a staging environment every day. It works pretty well for me and takes, literally, less than a minute. (How? Git + Navicat). Bonus round : I have yet to be called at 3am for a security problem with Radiant. Can’t say the same for wordpress, or other PHP-based applications. On Wed, Oct 27, 2010 at 11:02 AM, Steven S. \ **Author:** ![Christian\_Aust](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/5daacb/32.png) [@Christian\_Aust](https://www.ruby-forum.com/u/Christian_Aust)\ **Post date:** [October 27, 2010, 9:06pm UTC](https://www.ruby-forum.com/t/what-i-dont-like-about-radiant/198150/4 "2010-10-27T21:06:13Z") I’m always happy to see comments like this. If we don’t know where there are problems, we can’t make the project better. Thanks, Christian. On Wed, Oct 27, 2010 at 5:11 AM, Christian Aust [removed\_email\_address@domain.invalid](mailto:removed_email_address@domain.invalid) wrote: > Folks, > > this is not about bashing Radiant. Instead, I’d like to mention a few things > that make it harder to sell Radiant-based solutions to customers who often answer > “Why don’t you use Wordpress for the job?” > > (1) Radiant is like a toolbox for websites, but not quite. > > From a developer perspective, Radiant doesn’t stand in the way while I’m > building the next great website for a customer. It’s a great tool to build and > develop. From a customer (aka. “end user”) perspective, Radiant is a bunch of > input boxes where you have to enter cryptic stuff which looks a lot like code. > Well, in fact it is. Thats why some of my customers wouldn’t ever trade in their > wordpress UI for a nifty Radiant site. Which is a shame because they could do so > much better. How can I sell Radiant to users who don’t recognize the simply > aesthetics of Textile {or any other markup}? If it’s cryptic, you’re doing it wrong. Sample Radiant sites are also doing it wrong too, so that needs to be fixed in our templates. But you should do everything you can to hide Radius from the typical user. For different users that changes, and overtime in may change with any user. I used to use Textile, but it requires too much knowledge about what HTML is and has an expectation that you understand it’s features. It feels more like HTML shorthand, whereas Markdown feels more like just marking up my content. So what you use, depends on your users. Not only that, but there are extensions to add wysiwyg editors. [http://ext.radiantcms.org/](http://ext.radiantcms.org/) and if you can’t find them there, you might find them at [Repository search results · GitHub](https://github.com/search?type=Everything&language=&q=radiant+editor&repo=&langOverride=&x=0&y=0&start_value=1) > (2) Core Radiant isn’t enough to build a real-world website. > > HTML, javascript, css and images, that what you’ll typically need. Radiant (at > least edge) handles the first three pretty well, considering (1). For images, you > need the paperclipped extension. Why isn’t this core functionality? And even it it > was: URLs like /assets/47/some\_image.png contain that database id, which changes > with every installation and make them hard to remember. Why would you try to remember an image path? There are radius tags for that in paperclipped itself. Core Radiant has been plenty for many “real-world” websites (whatever that means). Some sites may not need uploading of images. Others can add an extension to do it (and there’s more than just paperclipped: page\_attachments, mediamaid, cy\_image, upload, and more). Eventually, we’ll have some image handling capability in the core application, but Radiant didn’t become popular because it had everything in it; it became popular because it was so simple and extensible. > (3) Upgrading is a pain. > > Even if I dont like it: Upgrading Wordpress is a breeze. Upgrading Radiant > usually involves SSH connections, terminal commands, some gem handling and server > restarting. Not a breeze, not at all. I can do that, but end users typically > can’t. PHP and Ruby are fundamentally different languages. If you want an end user to be able to upgrade Radiant, you’ll need to write the piece that does that (and it will be complicated). The main reason you can do that in Wordpress is that someone made it so. I’m personally working hard to make upgrading Radiant easier (and part of that is just plain old planning), but there are still a lot of ideas and code to be hammered out. But you said it best when you began here “Even if I dont like it…” I’d much rather enjoy my work everyday and have an occasional upgrade hiccup that not like working with the tool and have the upgrades go smoothly: “Yay, I can easily use the next version which I will enjoy just as little as this one.” > How do you think about this? I’d love to contribute to make stuff easier, but > I’m not sure where to start. Any comment is welcome. Kind regards, > > Christian I want good ideas from anywhere. Radiant isn’t built to be just like project X or to have all the features of project Y. It’s build to be whatever we decide and it’s getting more powerful and more flexible with each release. Where to start? Wherever you care. I started by writing extensions and then realized that the existing \ tags needed serious work and additional features. That got me into more and more. I found kindred spirits in the community and bounced ideas off of them. John Muhl and I would work on fixing bugs before either of us even had commit rights. I’d write to the previous maintainer, Sean C., and let him know that fixed some bug or that I pulled in features from other forks and all tests passed for me. Where should you start? How about here > **[Issues · radiant/radiant](https://github.com/radiant/radiant/issues)** > > Radiant is a no-fluff, open source content management system designed for small teams. - Issues · radiant/radiant Or here [GitHub - radiant/radiant-prototype: Prototype of the user-interface of Radiant CMS. · GitHub](http://github.com/radiant/radiant-prototype) Or contribute to [GitHub - saturnflyer/radiant-help-extension: Help documentation extension for radiant cms · GitHub](http://github.com/saturnflyer/radiant-help-extension) Even if you don’t understand some piece of code, you eventually will by trying to figure it out or someone will help you out with it. > p.s.: Will be at ArrrrCamp tomorrow. Who else? I _really_ wish I could be there. – Jim G. Saturn Flyer LLC > **[Saturn Flyer](https://www.saturnflyer.com)** > > Home info 571-403-0338 ---
**Author:** ![Christian\_Aust](https://www.ruby-forum.com/letter_avatar_proxy/v4/letter/c/5daacb/32.png) [@Christian\_Aust](https://www.ruby-forum.com/u/Christian_Aust)\ **Post date:** [October 27, 2010, 9:40pm UTC](https://www.ruby-forum.com/t/what-i-dont-like-about-radiant/198150/5 "2010-10-27T21:40:12Z")
Just my $0.02… (1). I think that what Radiant provides in terms of content control to develop and maintain a website is great. It’s mixture that developers (like myself) love for its power of customization, and it’s not too hard for a non-developer to quickly pick up. If a content editor can’t understand page parts and radius tags and how to use them, perhaps they should not be meddling with content. I think by dumb-ing things down too much for your average user will get in the way of Radiant’s power users and/or developers. (2). There I can’t agree with you more. From personal experience, the largest drawback for Radiant is lack of page access controls. Yes, there are extensions like members and reader, that allowed us to create our own login system to serve personalized content. But these extensions (and our system based on them) are ugly hacks (e.g. piggy- backing on class-methods to make current\_user available in tags, etc). I think page access control (with something like Roles) with personalized content is something that is a must-have for a serious CMS. (3). I have mixed feelings about this. Yes, upgrading should be easier. But if you use a lot of extensions, some of them may not be maintained by authors, and may not work with new Radiant versions, etc. Radiant is a developing CMS, and it’s APIs change all the time, so there is a lack of stable API, which makes any meaningful attempts of straight upgrades hard (or even impossible) a lot of the time. At the same time, I feel uneasy letting end-users conduct upgrades to software components. Speaking from experience, I see this as a source of many problems.