Which Ruby CMS Should I use

Radiant Acts As Solr Extension

2010-02-23T00:00:00+00:00

I set out to try and build an extension for Radiant that would incorporate Solr search into the CMS. First thing I have to say is:

WOW!

It is not an easy task to accomplish. What I wanted to provide is a fully customizable configuration to Solr with the ability for the user to select certain settings, which tables to index, etc. A bit à la Drupal’s Apache Solr Module but for Radiant (of course). That is easier said than done, the Drupal module is big and provides a good amount of features and customizations. I only had a few days to have a usable product (by few I mean less than a week).

I definitely could not build something from scratch, so I turned my focus towards building something on top of a library/plugin/gem that has been built for Rails. The one that pops up in all the searches is the acts_as_solr pluging. The plugin is easy to use, check the wiki page for more information. Unfortunately the life of the plugin has had some ups and downs, twists and turns. The repository has been forked many times on GitHub and it is unclear what its future will be. Regardless, it will be a start…

Before going on about the extension, I wanted to share something cool. If you are a Rails developer, you’ve probably heard of cucumber. I had used rspec on my Rails projects and I try to use a new or different tool each time I start a new project, factory_girl was an example for my last fun project, and cucumber is what I wanted to try out this time. Unfortunately I didn’t do much with it this time around, but when I installed it for the temp app I was planning on using for developing the extension I got some blinking stuff (what might be seen as blinking cucumbers) in the console. Here’s the screenshots:

Back to the extension…

What I decided to do is create a search controller and a search page. The search page will include the search form and the facets if they exist. The controller will handle filtering the search results based on the selected facet. The following screenshots illustrate the search page:

Each section of the page is in its own partial, and the layout of the page can controlled through CSS, which will control where the facets div will be placed in relation to the results div. The extension is configurable through a YAML file, where the admin can specify which models are to be indexed, which fields for each model to index and which fields to include in the facets, and among the configuration options is the layout from which the search page will inherit.

I installed the extension in the demo instance that I used in my previous posts, and specified the layout that I created then to be the one used for the search page, as is shown in this screenshot:

For more information, check out the GitHub repository or on the Radiant extensions registry entry

There is definitely a lot left to do, but this is a start! I hope it will be a useful extension for people and feel free to grab the source and improve it as you see fit.

Evaluation for Project

2010-02-10T00:00:00+00:00

I have been commissioned to prepare an evaluation for which CMS best fits a project with the following criteria:

Ability to publish news articles
A Blog
A Forum/Message Board
Newsletters
Multimedia (videos and public service announcements)
Static Pages
Community
Users with different privileges relating to the different parts of the site

The site will server as a source for people suffering from certain difficulties (will keep that under wraps for privacy reasons) where they can find helpful information and support for dealing with their situation. The individuals in question will be able to come to the site to have their questions answered or find valuable information that will be helpful to them. The site will also perform the role of a community portal where members will be able to post to a forum or receive the latest information through news articles or blog posts.

The CMS will have to allow for many scenarios including the ability for certain users to have the required privileges to post the static content of the site, such as an “Information” page or a “FAQ” page. Other users will be allowed to post news articles and some will have privileges to post blog posts. The CMS needs to also allow for user registrations and those users will then have user profiles, the ability to post and read messages in the forum and will be listed in the “Community” page where other registered users can track their activity.

The concept of the site is not new, many existing websites follow the same idea. My mission is to provide an evaluation of the Ruby CMS options that would provide the best platform to accomplish this goal.

One way to figure out if a certain CMS is capable of providing certain functionality is to search through the extensions list. A CMS’s primary function is to provide an easy way to create a website that is content heavy but where most of the content is static, so we do not have to worry about that aspect of the project. So here is a list of extensions for each CMS that might contribute to the solution we are looking for:

	BrowserCMS	Radiant	adva-cms (all the extensions come with the CMS, look at the previous posts for more info)	Wild Card Entry: Community Engine
News	news	news
Blog	blog	Radiant is built to support blogs out of the box but a couple of extensions provide more support: blog – blog-tags	adva_blog	built in
Forum		forum – group-forum	adva_forum	built in
Newsletters		reader – reader-group. The reader extension is used across the board (users registration, forum, etc.)	adva_newsletter	built in through private messaging
Multimedia	available through attachments	paperclipped – paperclipped-player – paperclipped-uploader
Community/Users		members – reader	adva_user – adva_activity	built in

Judging from the table above, it is easy to say that Radiant is ahead of all the other options. What Radiant does not provide out of the box, it makes up for through its extensions. Radiant’s extensions are the most developed and extensive. But if you have been following along with the posts you should know that Radiant is less flexible than the other mentioned CMS projects. Radiant allows you to extend its functionality only through creating extensions. Which means that if additional requirements come up and those requirements have not been covered by existing Radiant extensions, fulfilling those requirements might be a more challenging task. Community Engine presents a good case for itself. Although it might be missing one or two key functions, it covers the majority of the requirements. Unfortunately, I have heard from fellow developers that, unlike what the website says, developing for Community Engine is a pain and not recommended. BrowserCMS and adva_cms are the most flexible of the bunch, BrowserCMS in particular provides the easier interface to develop for, and they both plug-in to your application, so you have the freedom to create a custom app that hooks into your CMS.

The question then becomes: is it worth it to opt for flexibility in developing custom functionality over existing ones?

Developing for Radiant is possible, just more tedious compared to BrowserCMS. Additional requirements are not guaranteed and it does not seem prudent to choose a solution other than Radiant since it provides an easy implementation for each item in the current set of requirements.

Given a bigger budget and more time (more than 5 weeks for the entire implementation and launch), it would have been interesting to develop the site using BrowserCMS and extract from the end product the missing modules (forum, newsletter …) and make those available for the community. As the situation stands though, Radiant looks to be the favorite for this project.

Recap of First Two Weeks

2010-01-12T00:00:00+00:00

Time for a recap. Most of you are probably been waiting for this post. This is the results post, where I break down the experience gained from the past couple of weeks and try to give you all the information you need, as organized as possible, to make a decision on Which Ruby CMS Should You Use when starting your next project.

In the past few weeks I have mainly discussed three Ruby CMS projects that are available but a few others are also worthy candidates. And here is what I have learnt.

	Drupal	BrowserCMS	Radiant	adva-cms
Links	homepage – documentation – modules repo	homepage – repo – documentation – modules repo	homepage – repo – documentation – modules repo	homepage – repo – documentation
Documentation	Core documentation is ok, but very brief and rarely helpful. Forums are messy, long and badly organized. Documentation for Drupal 5 gets mixed with those of Drupal 6.	Not complete, there is enough to get you started and the responses to the mailing list are fast. But documentation definitely needs completion and expansion.	Extensive documentation with more than a 100 wiki pages. Great support on the mailing list and by community.	Limited documentation (probably because there is little to document!).
Installing	Manageable: download the source code, configure a settings file or two, create your DB and run the installation script (all of it has to be done each time).	Easy: Install the gem (once), create your Rails app using the template, create your DB and run the rake tasks.	Easy: Install the gem (once), create your Radiant app, create your DB and run the rake tasks.	Very Easy: Create your DB, create your Rails app using the template, and fill the simple form.
Upgrading	Ridiculously difficult, specially if you are using SVN in your team for source control.	Piece of cake, install the appropriate gem version and regenerate the file.	Fairly simple, also requires updating the gem and then updating the Radiant assets in your project	No clue, sorry!
Theming	Requires creating multiple templates (one general page template and then one for each section or view) and multiple hook functions. Keeping track of all the places to commit changes can get too cumbersome. People using a CMS want to develop their website in their web browser and Drupal forces designers to work with source code.	Have to create template files, but development can happen in the browser. Only need upload a CSS file with your project.	Everything happens in the browser, even creating stylesheets. ALso provides ability for templates to inherit from other templates.	Everything happens in the browser, with also the ability to upload existing files into your theme.
Modules/Extensions (list)	A huge list of modules is available, one of the compelling things about this CMS	Very short and limited list, but that might change soon. And the ease of writing your own makes up for it.	A good size list with probably everything you might need.	Small number of extensions that all come with the template.
Modules/Extensions (creating your own)	It requires writing PHP code, need I say more? I guess I will anyway, you will need to know all the hooks and weird function names that will make your module work. No separation of code between business logic and view logic. Did I mention PHP already?	Develop Rails models that hook into the CMS through magic words.	Create a Rails app using all the awesome things it provides and then copy the necessary files over as an extension.	Can use the Rails Engine plugins system to create extensions. Or create your custom MVC content just like you would with a regular Rails app.
Extended Custom Functionality	Done through modules.	Achieved just like in any other Rails app.	Done through extensions.	Achieved just like in any other Rails app.
Hooking to Existing App	It is your app!	Seamless integration. The CMS runs through the gem and is completely separate for the rest of the app.	It is your main app. With possibility of integration through Rails Rack.	Allows the possibility to import existing app into the project (involves copying the files over). Building a custom application on top of the CMS is the better way of going about it.
WYSIWYG/Rich Text Editor	Available through a module.	Native.	Available through extension.	Available through the extension, has to be enabled through settings.
File Attachments	Available through a module.	Native.	Available through extension.	Native.
Extra, Cool Features	Views and CCK.	Some sort of in place editing. Ability to create subparts of pages that can be easily shared.	Ability to setup a blog quickly through the database template at installation.	Multiple Site support.

Final Verdict

As the header of this blog suggests, the answer to the questions Which Ruby CMS Should I Use? is…

wait for it…

wait some more…

“It Depends!”

Do you know you want to use a CMS from the start AND you know you have the need to use contributed extensions extensively?: Your best bet is Radiant. Arguably the most developed and supported Ruby CMS out there right now.
Do you know you want to use a CMS from the start AND you do not have the need to use contributed extensions extensively, and would rather develop your own custom code?: adva-cms is on your side. If all you need is a blog, a forum or a wiki out of your CMS to support your custom app, adva-cms is perfect for that.
The need for a CMS came up late in the development process?: BrowserCMS is your friend. Probably the most flexible CMS available but is relatively young.

Honestly, all of the projects I have looked at have been impressive. If you are a Ruby fan, I recommend you to take a look at one of them for your future CMS needs. I hope the information provided has been helpful. On this note, I will conclude the first phase of this project.

Day Two with adva-cms

2010-01-08T00:00:00+00:00

Previously, we looked into installing a new adva-cms run website and customizing the look and feel. Today I will go a bit deeper into the extended functionality that is available with this CMS. The documentation for this project is spread out in multiple places. Some of it can be find on the main website, others in the README file and some at the GitHub wiki pages. And even if you go through all those sources, the documentation still feels incomplete. Regardless, I will attempt to look into the extra functionality available to us.

Remember that last time I did install all of the engines and plugins available by executing the following:

rake adva:install:all
rake adva:assets:install

So they are all available to us, what is left to do is enable the ones that require extra steps to be enabled and then find out where in the admin interface to go to start working with them. adva-cms claims to provide the functionality of creating multiple sites. But if you were following along with what we did last time you would notice that this option was not available to us. That is because you have to explicitly specify that you want this enabled. To do so, create a new initializer file in your application:

`-root_directory
 `-app
 `-config
  `-initializers
   `-...
   `-adva_init.rb

You can name that file whatever you want, I named it ‘adva_init.rb’ and that is where I would add any configuration code related to the adva-cms plugins. In that file add the following lines:

# adva_init.rb
ActionController::Dispatcher.to_prepare do
  Site.multi_sites_enabled = true
end

Those lines will enable the ability of multiple sites for your project. You will notice a new tab being added to your admin panel. Make sure you have restarted your server after editing the initializer file.

Navigating to the “Sites” tab will display the list of all the sites you have created,

and gives the ability to create new ones.

So lets go ahead and create a new site with the following settings:

The important thing to notice is the host name field. Since we are working locally and we want to have both sites running at the same time, we have use a different port number. For this case I went with 3001. Now, in the terminal, go to your project directory and execute this line:

./script/server -p 3001

This will start another server running on port 3001. Using your web browser, navigating to http://localhost:3001/ will take you to the newly created site.

Notice that the second site we have created does not inherit the theme. Each site you create is totally independent and does not share settings with your other sites. Some people might want their sites to share themes, but with the ability to export and import themes the process is very easy and simple.

So we have now added the ability to create multiple sites using the adva-cms. Why not also add a WYSIWYG editor? To accomplish that, the idea is basically the same as what we did previously. One of the plugins that we have installed is the FCKeditor plugin. We just need to enable it by adding the following line to our initializer file and restarting the server:

# adva_init.rb
Fckeditor.load!

And voila:

If you have been following along with the previous posts, you know that the demo site I build with each of these CMSes is a conference site. Part of every conference website are events and a calendar. So lets create some events. The first you need to do is create a new section for your site and specify the type to be “Calendar”. Once you’re done you’ll be redirected to the “Events” page for that section. The list will start off empty. Click on the “New” button to create a new event. You should then see the following form.

Fill in the form and you’ll have your first event created. If you navigate to the calendar page (“/calendar”) you will see your events listed there along with a search form and a monthly calendar.

That’s pretty much it for events. Lets also take a look at creating photo albums. The process is pretty much the same. Create a new section of type “Album”, then under the “Photos” tab in the admin UI upload your images. If you want to group the pictures in photo albums or sets, create a new set and then select the checkbox corresponding to the set you want your picture to be published under.

You can view your pictures by going to the album page (“/album”) as well as your sets.

The is the same for the other content types available such as Wikis, Forums and of course Blogs. adva-cms does provide a bunch of good stuff out of the box. It is a CMS that is supposed to extend your custom Rails app and give you the tools you need to create typical content such as static pages, blogs, etc. With this note, I conclude Day Two with adva-cms.

Day One with adva-cms

2010-01-07T00:00:00+00:00

After looking at two of the most popular or talked about Ruby CMSes out there it is time to look at what else is out there. Searching (or Googling) for “Ruby CMS” or “Rails CMS” brings back a few results but most of them are blog posts, articles or questions about the topic. You are required to do some deep digging before getting a good list of available CMSes. AjaxLines has an article about the Top 20 Ruby CMS but the post is from August 2006 and the information on there is outdated. A more recent post can be found on A Fresh Cup which provides more current information. The post provides a good list of projects. I would like to add to it that even though Comatose is listed under the inactive list, it is still an alternative worth looking into. RailFrog is another project that looks to have good documentation and shows signs of life. It also has to parts of the project, one that allows you to create you CMS project immediately and one that hooks to your Rails app through the Engines system. Another CMS worth investigating is Community Engine, which seems to give you a lot out of the box and does that well but I have heard that developing for it is a pain.

All of the afore mentioned projects look to be good candidates, but I have decided that today I will take a look at one of the probably lesser known ones called “adva-cms”. You can find adva at its home and the repo on GitHub. Looking at the README file of the project, the first thing that catches my eyes is the following:

Different from others, adva-cms lives in vendor directory and keeps your main
app directory clean and dandy. So you can reclaim app directory and use it
only for your own application files.

adva-cms makes it extensible: you can only pick those engines/features you really
need for your application and omit the rest. All engines are designed to work
together seamlessly, so the whole platform feels much more consistent for
similar but separate Rails applications.

That is the kind of thing developers like to see in a system that they want to use. So lets get started. You can find more information on the wiki page but I will take you through the basic steps here. First make sure you have the Rails 2.3.4 and ImageMagick gems installed then create you adva-cms app using Rails templates.

# use '-d mysql' if you want to use MySQL instead of SqlLite (or any other engine)
rails my-app -m http://github.com/svenfuchs/adva_cms/raw/master/templates/adva-cms.0.3.0.rb

The installation spits out this fine tip, which you might want to follow:

# this might take a bit, grab a coffee meanwhile :)

If you have not created your database before hand you will see something like this:

rake  adva:install:core -R vendor/adva/engines/adva_cms/lib/tasks
rake aborted!
Unknown database 'adva_demo_development'

(See full trace by running task with --trace)

This can be easily fixed by following these steps:

cd /path/to/app
rake db:create
rake  adva:install:core -R vendor/adva/engines/adva_cms/lib/tasks

You should now be set, navigate to http://localhost:3000/ to start the installation:

After you fill the easy and shot form you should see the success screen which also has a link to the admin part of the side.

The instructions for the installation mention the following:

# config/initializers/new_rails_defaults.rb
# either comment out the following line or set it to true
ActionController::Routing.generate_best_match = false

So be sure to follow them before going forward. After finishing the vanilla install of the site, you will want to install the engines and plugins that come with the CMS. You have the option to either install all of the, the core ones, or specific ones you specify. Check the README file for more info. For this demo I will opt to install them all:

rake adva:install:all
rake adva:assets:install

Which will install the following:

installing engines: adva_activity, adva_assets, adva_blog, adva_calendar, adva_cms, adva_comments, adva_contact_mails, adva_forum, adva_newsletter, adva_photos, adva_rbac, adva_spam, adva_themes, adva_user, adva_wiki
installing plugins: adva_cells, adva_context_templates, adva_fckeditor, adva_google_analytics, adva_meta_tags, adva_post_ping, adva_url_history

For today, the important engine that we are interested in is the adva_themes one. This is what we will use to create our theme and layout for our site. The current admin panel looks like so:

Click on the “Themes” tab. You should see an empty list. Create a new theme by filling the form.

Once you are done filling the “New Theme” form you will be redirected to a page that shows you all the associated files. By default you should only see a preview image file associated with a new theme. With your theme, you usually want template, stylesheet, javascript and image files associated with it. To do so you can create new ones or upload existing ones into the theme. Check the documentation for more detailed information. For this demo I will override the default layout template, create my CSS file, a few partials and upload the corresponding images. To override the default layout, create this file:

# templates/layouts/default.html.erb
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
    <title><%= @section.title %></title>
    <%= theme_stylesheet_link_tag 'nvc', 'nvc/vet10.css' %> 
    <%= yield :head %> 
  </head>
  <body>
    <div id="top"><a href="#content">Skip to content</a></div>
    <div id="wrapper">
			<div id="header">
				<%= render :partial => "/partials/header_image" %>
			</div>

			<div id="aside">
				<div id="nav_left">
					<%= Menus::Sections.new.build(self).root.render(:id => 'sections') %>
				</div>
					<%= render :partial => "/partials/medal_image" %>
			</div><!-- #aside -->

			<div id="content">
				<div id="intro">
					<h2><%= @section.title %></h2>
				</div><!-- #intro -->

				<div id="content_main">
					<%= yield %>
				</div><!-- #content_main -->
			</div><!-- #content -->
			<div style='clear:both' />
			<div id="footer">
				<%= Menus::Sections.new.build(self).root.render(:id => 'sections') %>
			</div>
    </div>
  </body>
</html>

a few things to notice:

<title><%= @section.title %></title>

In adva-cms, a page is called a section and each section can have one or more articles. That is why to get the title of the page I used the @section object.

and:

<%= theme_stylesheet_link_tag 'nvc', 'nvc/vet10.css' %>

You have some helpers that are available to you for including other files in your code:

theme_stylesheet_link_tag theme_id, stylesheet_name
theme_javascript_include_tag theme_id, javascript_name
theme_image_tag theme_id, image_name

and:

<%= render :partial => "/partials/navigation" %>

There is no special way to create blocks or partials with adva-cms. You need to create a new file that follows the Rails convention for naming partials and then include it in your template just like you would if you were doing any normal Rails views or templates.

One thing to note, when creating a new file, the name you give it specifies the directory structure. For example, if you name a file “nvc/vet10.css”, a new folder called “nvc” will be created under the stylesheets folder (determined by the extension of the file, would be under the javascripts folder if the extension was .js) and the new file will be created in the new directory. For images, you will have to go back and edit the name of the file after the upload is complete.

Looking at the source code for the adva_cms plugin, specifically at the default layout file you can learn a few things about editing your layout. For example, the following code can be used for menus:

<%= Menus::Sections.new.build(self).root.render(:id => 'sections') %>

The source code is probably the best way to look for the way adva-cms does things if you can not find the appropriate help in the wiki pages. So at this point we have created our theme…

Created the necessary files and uploaded images…

And we have our site ready.

In adva-cms, you can create as many themes as you want, then activate the one you want your site to use and deactivate the others. Another thing to point is that when creating new sections in your site you can specify which layout file you want it to inherit from. This shows how closely adva-cms follows the Rails conventions and developing for it should feel very familiar if you are used to developing using Ruby on Rails.

I must confess, using it for the first did feel a bit weird and different from using other CMSes (which could be a good thing for some people). Some of the plugins that I installed at the beginning of the day seem to be hidden. You do not see any tabs for them on the admin pages. But they are there. For example, the wiki plugin can be used when creating new pages by specifying the type of page you want (Page, Blog, Calendar, Wiki, etc). With this note, I conclude Day One with adva-cms.

Day Three with Radiant

2010-01-06T00:00:00+00:00

As with any usual project, there is always the need for creating custom content and custom content types. That is why, in Day Three with Radiant I will look at adding custom behavior to Radiant. I think this is an important part of any CMS and the way the system allows you to create custom content is very critical.

If you look at the directory structure of a typical Radiant project you will notice that the app folder that is usually found in a Rails application is missing. This means that the normal way of creating models, views and controllers that is available in Rails is not offered to us by Radiant. To achieve this goal we have to resort to using extensions. A number of articles can be found on the subject on the wiki page Creating Extensions.

The first guide to look at is the How-To: Create an Extension. The method they suggest in this tutorial is to create a separate Rails application that contains the models, views, controllers and migrations. Make sure that this application contains all your logic and data that you require, then copy the necessary files to the extension directory that you have created. Then run the migration and update script. When that is done, you can now add the routes required by your extension and you are done, or are you?

If you need to add custom page types, which are pages with custom behavior, your work is not done yet. You will need to follow the instructions on this page. And if you require custom Radius tags, you will have to do something like what is suggested in this tutorial.

This whole process looks tedious to me. It seems that the work required for a developer to be able to add new models or content types is doubled by the fact that the developers have to maintain a temporary application where the new models are developed and tested. It is possible to create your extension straight in your Radiant project but you will not have the assistance of the generators, which can be very helpful and time saving. The tutorial does mention the following:

Until there is an extension scaffolding generator

So hopefully a future version of Radiant will include these generators and make this task less time consuming and easier on the developers.

One concern that I still have is the fact that Radiant takes the dominant role of the project owner or project parent which means that the application lives within Radiant. This is opposed to the case where the CMS is an extension of the original application. This might present problems for projects where a CMS became a requirement or a necessity after the original code base has been developed. A project that will include Radiant, is a project that needs to be created as a Radiant project from the start or has to be exported into a Radiant extension. Most CMS systems out there present the same conundrum for developers. So in the case where a CMS is needed to enhance a website by providing a means to create static pages or a blog, a CMS that can be installed as an addition or extension to the application (such as BrowserCMS) has an advantage over a CMS like Radiant.

Overall, Radiant seems like a good candidate for projects where you know upfront that you will be using a CMS. It has good core documentation by the Radiant developers and an extensive list of extensions. Extending the application yourself is possible and relatively easy even though it requires a number of steps to be taken. Following the mailing list and browsing the wiki pages give me the impression that the project is in full swing and development on it is always progressing. Also, the community provides great support. At the conclusion of Day Three with Radiant I can say that this CMS is worth a shot if you are starting a new project and want to take advantage of the things that Ruby and Ruby on Rails provide you.

Day Two with Radiant

2010-01-05T00:00:00+00:00

Radiant uses extensions to, as the name suggests, extend the functionality of the CMS. These extensions can be found on, but no limited to the Extension Registry. If the extension you would like to use is found in the registry, you’ll be able to use the built-in script to install it. Otherwise, you will have to use the manual installation process. You can find more information about how to install and uninstall extensions on the wiki.

For this demo I am building a conference site and awesomely enough there is an extension for that. The extension that I will look at is called, appropriately, Conferences. If you look at the Conferences Extension GitHub Repo you will see in the README file that there are some dependencies that you need to install before getting to the extension itself. There isn’t any information on how to get those dependencies installed so follow along with these instructions:

# Install the fastercsv gem
sudo gem install fastercsv

Download the file_column plugin into the vendor/plugins directory and if you are using a Rails version earlier than 2.1 you will need to do the following as well:

# Install the tzinfo_timezone plugin and tzinfo gem
sudo gem install tzinfo
git clone git://github.com/rails/tzinfo_timezone.git vendor/plugins/tzinfo_timezone

Then continue installing the extensions:

# Install the members extension
./script/extension install members
# Install the tinymce_filter extension
./script/extension install tiny_mce_filter
mv vendor/extensions/tiny_mce_filter/ vendor/extensions/tinymce_filter/
rake radiant:extensions:tinymce_filter:update

Notice that we had to rename the folder for the tiny_mce_filter extension because of naming error and then rerun the update manually. Now you are ready to install the conferences extension:

./script/extension install conferences

ActionMailer spits out an error in the current settings, to fix it we must install the plugin and the extension:

# Install the Action Mailer & TLS plugin 
git clone git://github.com/collectiveidea/action_mailer_optional_tls.git vendor/plugins/action_mailer_optional_tls/
# Install the mailer extension
./script/extension install mailer

To see the changes make sure you restart the server. If you navigate to the extensions page from the admin panel you will see the list of extensions installed.

You will also notice the new tabs that are now available for you (Submissions, Conferences, Profile).

And if you navigate to the “Conferences” tab you will see all the configuration options and links to create new conferences. Enjoy!

Installing this one extension has honestly been a pain. I had to dig around to figure out what the dependencies were and how to solve some of the problems like the ActionMailer error and the renaming of the tiny_mce_filter forlder. I hope installing other extensions is not as difficult as this one. The documentation for the extensions is lacking, even though the documentation for Radiant itself seems to be good so far. I have been on the Radiant mailing list for a while and I have seen a good response time and a lot of people willing to answer questions, so that might the best resort for help. On this note I conclude Day Two with Radiant.

Day One with Radiant

2010-01-04T00:00:00+00:00

After taking a brief look at BrowserCMS, it is time to examine another ruby CMS. For the next few days I want to take a look at one Ruby’s more known and probably most used CMS, also known as Radiant. Just like any open source project in the Ruby world, you can find Radiant at its GitHub repo accompanied by its Documentation.

Installing Radiant follows the same steps as installing BrowserCMS:

$ sudo gem install radiant

But to create a new project you have to do the following:

$ radiant --database [mysql|postresql|sqlite3|sqlserver|db2] path/to/project

Once you run this command, you will get a message after it completes that instructs on how to proceede:

== Installation and Setup

Once you have extracted the files into the directory where you would like to
install Radiant:

1. Create the MySQL/PostgreSQL/SQLite/SQL Server/DB2 databases for your Web
   site. You only need to create the "production" database, but you may also
   want to create the "development" and "test" databases if you are developing
   extensions or running tests.

2. Edit config/database.yml to taste.  There are example files available for
   various databases in the config directory.

3. Run the database bootstrap rake task:
   
     % rake production db:bootstrap
   
   (If you would like bootstrap your development database run 'rake
   development db:bootstrap'.)
   
   If you get the error "no such file to load -- spec/rake/spectask" please
   install Rspec (gem install rspec).

4. Start it like a normal Rails application. To test execute:
   
     % script/server -e production
   
   And open your Web browser on port 3000 (http://localhost:3000). The
   administrative interface is available at /admin/. By default the bootstrap
   rake task creates a user called "admin" with a password of "radiant".

When using Radiant on a production system you may also need to set permissions
on the public and cache directories so that your Web server can access those
directories with the user that it runs under.

Once you have installed Radiant on your own Web site, be sure to add your name
and Web site to the list of radiant users:

http://wiki.github.com/radiant/radiant/radiant-users

You can also find these instructions online along with a more detailed help section on the wiki.

When you follow the instructions given you will notice that Radiant will ask you to provide the name, username and password for the admin user to be created, or just use the defaults:

Create the admin user (press enter for defaults).
Name (Administrator): 
Username (admin): 
Password (radiant): 

Initializing configuration.........OK

The it will prompt you to select a template for your website, which I think is very cool specially if you know you are going to create a blog like site:

Select a database template:
1. Empty
2. Roasters (a coffee-themed blog / brochure)
3. Simple Blog
4. Styled Blog
[1-4]:

Now you are ready to start building your website. I created an empty site for the purposes of this demo and when I fire up the page I am automatically redirected to the admin login page. Once you login, you will see the “Pages” page where all you site pages will be listed.

Using the empty template you will not have any pages listed, nor any snippets or layouts. You will have some extensions installed though:

As per the process used to discuss the first Ruby CMS we have looked at, the first thing I will be accomplishing today is creating the layout for the website. To do so, navigate to the “Layouts” page and create a new one. The form will look like this:

The form is simple, you provide the name and the body of the layout and if necessary a “Context-Type” (such as text/css or text/xml). Lets create our layout:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
<head>
	<meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
	<title><r:title /></title>
	<link rel="stylesheet" type="text/css" href="/styles.css" />
	<script type="text/javascript" src="http://www.jeroenwijering.com/embed/swfobject.js"></script>
	<script type="text/javascript" src="/javascripts/prototype.js"></script>
	<script type="text/javascript" src="/javascripts/scriptaculous.js?load=effects,builder"></script>
	<script type="text/javascript" src="/javascripts/lightbox.js"></script>
</head>
<body>
	<div id="top"><a href="#content">Skip to content</a></div>
	<div id="wrapper">
		<div id="header">
			<r:snippet name="header_image" />
		</div>

		<div id="aside">
			<div id="nav_left">
				<r:snippet name="navigation" />
			</div>
			<r:snippet name="medal_image" />
		</div><!-- #aside -->

		<div id="content">
			<div id="intro">
				<h2><r:title /></h2>
				<r:if_content part="extended">
				<r:content part="extended" />
			</r:if_content>
		</div><!-- #intro -->

		<div id="content_main">
			<r:content />
		</div><!-- #content_main -->
	</div><!-- #content -->

	<div id="footer">
		<r:snippet name="navigation" />
	</div>
</div>
</body>
</html>

More detail on some of the parts will come later…

Since our project was created using the empty template, we will need to create some pages to view the result of our layout work. Under the “Pages” tab, you will see an empty list of pages and a button saying “New Homepage”. That would be a good place to start. The new page form is quite impressive in its content:

Other than the usual title and body, you can specify a number of page options (Layout, Page Type, Status) as well as editing options (Filter). Clicking on the “more” link would provide you with, well as the name suggests, more:

The more impressive part about this method of creating a new page is the available references that provide help for the editor, such as the filter reference that provides help about the chosen filter and the tags reference that provides a list and description of the available tags in the page to be used by the editor.

These references will provide help for editors without the need to dig around in overwhelming documentation in order to create simple pages. This means less time training editors and content contributors, making the developer a lot happier.

Also notice the two available parts for the content. The first part is the body and the other one named “extended”. Radiant provides the ability to create multiple parts of a page where the body is the main one and the others are additional parts constructed on top of the body. Through the layout you create you will be able to specify how these parts are created. And to add or remove parts just use the icons available at the right of the tabs.

One part of creating pages involves creating “blocks” that can be inserted into a page. Using BrowserCMS we accomplished that by creating partials, and with Drupal by creating blocks. With Radiant these parts are called snippets. In our case we want to create two snippets, one for the header image and one of the medal image below the navigation menu. Radiant does not provide a mechanism out of the box to upload images, so I will add the images used for these two snippets in the images folder of the app and link to them from the snippet.

After creating the snippets, we need to add our CSS to get the desired theme. Radiant handles CSS in what I think to be a peculiar way. Unlike most frameworks or CMSes, instead of adding a .css file to your source code you will need to add a page that contains your CSS. To do so, you need to first create a layout to handle how a CSS page would be rendered, then you need to create new page that would be the child of your home page using the new layout and add to it your CSS code.

Make sure that the slug for the page has the .css extension and then link to your page in your layout.

<link rel="stylesheet" type="text/css" href="/styles.css" />

Radiant does not provide a menu system, so you will have to create your own snippet that will include your navigation links:

And then include the snippet in your layout:

<r:snippet name="navigation" />

You can get more information about creating your navigation from the wiki page.

So far we have created a layout, added to the layout some CSS and a few snippets including the navigation snippet. We have also created our home page and added content to it. The result is as follows:

One thing worth noting is the use of the page parts. Using the “extended” part I am able to create in the case our demo an intro part of the page that would be included under the title of the page. Which is a cool way to have flexible means for content contributers to provide an intro or any other parts of the website.

We have covered installing Radiant, creating a layout and adding pages and snippets. This concludes Day One with Radiant. Next time we will look at adding some of the available extensions and enhancing the functionality of the website.

Day Three with BrowserCMS

2009-12-30T00:00:00+00:00

In many cases, when building a custom website for a client, the word “custom” is actually key because the client wants to provide functionality that is unique and not present in any of the systems available to work with (or at least so they think). In the occasion where that is actually true, you (the developer) have to create custom content to fill your needs. This is precisely what I explored on Day Three with BrowserCMS.

This blog post will be short and sweet. Following the HOWTO of the Developer Guide page is straight forward. Creating a custom content type follows the same principles of creating new content with any regular Rails App. Using a keyword or two in the generation process is all it takes to integrate your new model with BrowserCMS’s content.

The only caveat of this approach is that it involves what some people will call “coding”. Many “site admins” like using a CMS because of the ability to do pretty much everything from an administration panel without having to write any piece of code. That is why most of the CMSes available are “user friendly” and geared towards designers (basically, people with no programming experience), which also make them a nightmare for developers who are trying to extend the CMS’s capability and add new functionality. Make no mistake, BrowserCMS is not one of those systems.

Even though the BrowserCMS Documentation says:

BrowserCMS is a general purpose, open source Web Content Management System (CMS), written in Ruby on Rails. It is designed to support three distinct groups of people:

1. Non-technical web editors who want a humane system to manage their site, without needing to understand what HTML or even Rails is.
2. Designers who want to create large and elegantly designed websites with no artificial constraints by the CMS.
3. Developers who want to add a CMS into their Rails projects, or create CMS driven websites for their clients.

I would consider BrowserCMS more suitable for the third type of person mentioned in the above quote.

What does this mean? The answer was well put by William Wallace saying:

They may take our lives, but they’ll never take our FREEDOM!

Basically, this method of creating custom content gives the developer all the freedom he enjoys developing a regular RoR application. There is little need for learning new hooks or magic methods and tricks to be able to extend a CMS or add new behavior. This finally provides a way for a consultant like me who is asked to develop a site using a CMS to actually be charging for time spent doing actual work, actual programming instead of arm wrestling with a system.

There is still a case to be made for something like Drupal’s CCK Module which provides an interface to create custom content from the browser without delving into coding. But in my opinion you will still be bound by the module’s limitations and at best you can get into hacking or monkey patching, which in my experience has been the worst thing I have done as a web developer.

What BrowserCMS offers is the ability to develop The Rails Way while still providing your users with the interaction and usability of the typical CMS. With that note, our little experiment with BrowserCMS comes to an end. Next time I will take look at another Ruby CMS.

Day Two with BrowserCMS

2009-12-29T00:00:00+00:00

Now that we have explored some of the “out of the box” functionality of BrowserCMS and modified the theme, it is time to extend its functionality through the use of modules. If you are familiar with Drupal, you are used to downloading the source code of a module to one of the folders where Drupal looks for them and then installing it through the admin menu. With BrowserCMS the process is a bit different. The modules I will be using today are the Event Module and the Event Registration Module.

Installing a BrowserCMS module requires the following steps (check the documentation site for more info):

Downloading the source code
Getting the Gem installed
Telling BrowserCMS to use that Gem
Pulling the module specific code into your project (like migrations)
Running migrations

Once you have completed the instructions and installed the module, you can navigate to the content library of your project and you will see a new content type added, in this case called “Event”:

And new portlets:

And new category types:

Adding a new event is just like adding any new content. Each content type of course requires its specific set of fields. The event module comes with a page that contains both portlets available. This page shows the list of events created, grouped by the month, and if you click on one of the events it displays the details of that event on the same page.

One thing to note is that the date fields in the form will show a calendar that pops up, even though there was no indication of it on the page.

It is disappointing though that the event content type does not come with the flexibility of adding a time of an event. If you are building a conference website, you would want to provide the time of each session. Another limiting factor is the lack of ability to add or remove or edit fields belonging to a content type. For example, in the case you want to add a time field to the event content type I did not find a way to accomplish that. It will be interesting to see what sort of mechanism is available to build custom content and to configure modules.

After adding the Event Registration module not much changed in what was available for us to work with. The only added functionality was the ability for a user with CMS permissions to a new registrations via the “add content form”. The form was not available as a portlet to include in a public page. This is probably because of the fact that the modules are still young and not fully developed yet.

Until I looked around a bit and found that you can add a registration portlet. You will have to add a registration portlet for each event you create. Since the documentation is basically non-existent at this point, I had to dig around to be able to find it. Hopefully the documentation will be expanded soon. So creating a registration portlet for an event is pretty straight forward because the code is already populated for you, all you have to do is just choose the event it corresponds to.

Once you create your event registration portlet, add a new page where the portlet will be added. Then use the path to the page for the “Registration URL” field of the event. You will have to edit the “Event Details” portlet and change the way it displays the URL to use an anchor tag:

<p><b>Registration Url:</b> <a href='<%= @event.registration_url %>'><%= @event.registration_url %></a></p>

Once a user clicks on the link they will be redirected to the page with the form. There the user can fill the form and register for the specific event. For the purposes of this demo I left the redirect path for the form to be the same page as the form, you might want to create a new page with some sort of feedback and use it for the “Success url” field.

The result of the registration can be shown on the admin side under “Event Registration” in the content library.

After looking into these couple of modules and examining the list of modules available at the BrowserMedia Public Repo, I can only say that the ecosystem is young and still requires a lot of development to reach a stage where it’s mature enough to provide most the common functionalities needed these days. But if you have worked with Rails you know how easy it is to develop in this framework, which means that any new functionality can be added without much hassle. Extending a module can be done as simply as adding a file to the lib folder of your app with the required code.

Views is one of the most powerful module available to Drupal users. Using portlets we saw how easy it is to get a similar functionality, the “Event List” portlet is a good example:

<div>
  <% @events.group_by{|e| e.starts_on.year}.sort_by(&:first).reverse.each do |year, events_grouped_by_year| %>
    <!-- <%= year %> -->
    <% events_grouped_by_year.group_by{|e| e.starts_on.month}.sort_by(&:first).reverse.each do |month, events_grouped_by_month| %>
      <b class="month"><%= Date::MONTHNAMES[month] %></b>
      <% for event in events_grouped_by_month.sort_by(&:starts_on).reverse %>
        <div id="event_<%= event.id %>" class="event">
          <span class="event_starts_on"><b><%= event.starts_on.to_s(:long) %></b></span>
          <br/>
          <%= link_to "<b>#{h(event.name)}</b>", event_path(event.route_params) %><br/>
          <% unless event.description.blank? -%>
            <p><%= simple_format h(event.description) %></p>
          <% end %>
        </div>
      <% end %>
    <% end %>
  <% end %>
</div>

As a conclusion to Day Two with BrowserCMS, I can say that the BrowserCMS module world still needs some time for development in the way of providing both functionality and documentation. But once that is available, there will be little that this CMS can not provide. Next time we will look into adding custom content.

Day One with BrowserCMS

2009-12-28T00:00:00+00:00

For the first Ruby CMS I decided to try out BrowserCMS. The home page for this CMS can be found at BrowserCMS.org and that is where you can find all the links you need for the project such as the GitHub repository and Documentation.

The first thing that is required is to install the gem, using the following:

$ sudo gem install browsercms

Then create your Rails app using the BrowserCMS template like so:

$ rails my_new_project_name -d mysql -m http://browsercms.org/templates/blank.rb
$ cd my_new_project_name
$ script/server

Once that is done, navigate to http://localhost:3000/ using your favorite browser and you should see the following:

To start editing got to the admin login page at http://localhost:3000/cms/login which looks like the image below and enter the default admin username/password which are cmsadmin/cmsadmin

After signing in successfully you will notice the admin panel appear at the top of the page.

You will notice that the first thing this CMS provides you are two links. The first one is to edit the default template and the second one to create a new template. This means that you can start creating your site’s layout immediately. Most projects I have worked on that used a CMS were projects where we had to port an existing base. What that means is that the first step towards the migration, before adding any new functionality to make use of the CMS, is to take the existing pages or code and recreate them under the new system. The major part of it usually evolves around the layout and the theme. Which is where we will start for this demo.

As I mentioned in the introduction post, I will be building a demo site based on my latest project using Drupal. In that project I resorted to creating a block for a header image to help the content editors change the image without much problem or digging around in code. BrowserCMS provides us with the ability to create page partials, which will substitute for Drupal’s blocks. Heading over to http://localhost:3000/cms/page_partials will show us a list of all available partials. To start with there will not be any available. The first step is to add one by clicking on the “Add” button and then provide the following information:

Name
Format (default: html)
Handler (default: erb)
Body

Now that we have created our header partial, we need to insert it into our template. Go to http://localhost:3000/cms/page_templates/ for the list of available templates. Unlike the partials, templates already comes with a default one called “Default” (d’oh!). You can choose to create a new one, and just like the page partials provide the following information:

Name
Format (default: html)
Handler (default: erb)
Body

What’s cool about it is that you get a default body already filled in and all you have to do is make the appropriate changes:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
    <title><%= page_title %></title>
    <%= yield :html_head %>
  </head>
  <body>
    <%= cms_toolbar %>
    <%= container :main %>
  </body>
</html>

In our case we will edit the default template to match our previously developed template for Drupal. After re-ordering a couple of things and adding missing divs, the template looks like this:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">
  <head>
    <meta http-equiv="Content-Type" content="text/html;charset=utf-8" />
    <title><%= page_title %></title>
    <%= yield :html_head %>
    <%= stylesheet_link_tag "nvc/vet10.css" %>  
  </head>
  <body>
    <%= cms_toolbar %>
    <div id="top"><a href="#content">Skip to content</a></div>
    <div id="wrapper">
			<div id="header">
				<%= render :partial => "/partials/header_image" %>
			</div>

			<div id="aside">
				<div id="nav_left">
					<%= render_menu %>
				</div>
					<%= render :partial => "/partials/medal_image" %>
			</div><!-- #aside -->

			<div id="content">
				<div id="intro">
					<h2><%= @page_title %></h2>
				</div><!-- #intro -->

				<div id="content_main">
					<%= container :main %>
				</div><!-- #content_main -->
			</div><!-- #content -->

			<div id="footer">
				<%= render_menu %>
			</div>
    </div>
  </body>
</html>

Which is much simpler than the 110-line template used for Drupal. Notice this part

<%= stylesheet_link_tag "nvc/vet10.css" %>

This is where I link to my custom stylesheet which is located under:

`-public
 `-stylesheets
  `-cms
  `-nvc
   `-vet10.css

The folder ‘cms’ is where BrowserCMS keeps its stylesheets and this is followed anywhere BrowserCMS has copied its own specific files such as the images folder. The ‘nvc’ folder is not necessary but I have chosen to use this kind of separation for this demo.

Our page now looks something like this (I did not copy all the content, just a few stuff for the purposes of this demo):

And on the admin side:

Notice the icons at the top of the content:

BrowserCMS allows you to add blocks of content to a page and this content can be one of the following:

Text (can include attachments through the use of a rich text editor)
Portlet (Dynamic Portlet, Email Page Portlet, Login Portlet, Tag Cloud Portlet)
File
Image

And once you have added a block, it is possible to re-order/edit/remove any block on the page. You also can add pre-existing blocks which is very useful because on my Drupal project the client wanted “Back to top” links and a horizontal line after any long content and with the way BrowserCMS handles adding blocks this becomes easier than just a copy/paste of the code.

Adding images to your site is also very easy. You can do it in multiple ways: Either through the content library, adding an image block to a page or even attaching an image to a text content.

One of the most tedious and annoying thing I have experienced with Drupal is upgrading its core. If your code base is under source control using SVN, to update the Drupal core you must delete the existing one and insure that it is removed from the repository and then download the new version of the code and commit it. This could really become a messy affair specially because the Drupal core is huge. With BrowserCMS, on the other hand, upgrading or downgrading is very simple and easy. The gem I had installed at the beginning of the day was at version 3.0.5 which introduced an error (For more info check this thread). So I had to downgrade to the previous version (3.0.4) for the fix. I was able to do it with only a couple of steps (from the wiki page):

sudo gem install browsercms -v=3.0.4
cd /path/to/your/project
script/generate browser_cms
rake db:migrate

This pretty much concludes Day One with BrowserCMS. The basic layout is in place and we are able to crate static content. Next I will look into installing and using some of the available modules. Since the demo site I am building is a conference site, I will look into the event module and the event module registration.

Introduction

2009-11-23T00:00:00+00:00

As a web developer in a consulting company, one of the most common ways to pay the bills is to pickup short projects that usually evolve around the need for an easy and quick way to produce static content. This falls under the domain of Content Management Systems ( CMS ) and the web is dominated by websites built on top of some flavor of a CMS. The most common ones are blogging CMS such as WordPress.

The complexity of these projects resides in many areas some of which are the custom needs of the client and the flexibility of the CMS. It is difficult to design a system that is powerful enough to be able to perform all possible tasks and remain simple to allow developers to customize some of its functionality. A CMS is usually marketed as a quick and dirty way to get someone’s content published without any knowledge of programming or system administrating. What this means is the fact that those systems are designed and built with a non-programmer in mind and thus a developer’s task to customize such systems becomes a hard and frustrating chore.

Currently, the leading CMS all come from the PHP world with WordPress championing the blogging realm, Moodle for the education sphere and Drupal, Joomla and ExpressionEngine for all other needs. The focused ones seem to do their job very well and expectedly so. The rest on the other hand are a nightmare for developers to deal with. If the project you’re working on involves more than just installing and configuring a few modules, you are in for a lot of WTFs/minute and as we all know that is not a good sign. Software development can be fun and some tools allow that more than others. Developing in Ruby and working with the Ruby on Rails framework have always been enjoyable experiences which is why I have decided to finally test the Ruby CMS waters.

As I mentioned before, the tools that are focused on accomplishing a particular task have mostly done a good job at it and therefore I will not be discussing things like Jekyll which this blog is built on. The focus of this project will be systems that would rival or be candidates to replace a CMS like Drupal. I will be referencing Drupal in some comparisons and may use it as a reference point because of my experience developing with it, that of course does not mean that Joomla or ExpressionEngine might perform the same tasks discussed as well or even better than Drupal. I have more experience using Drupal and it is arguably the most popular CMS currently in use so I believe that it provides a good reference point for future discussions and comparisons.

The entire Rails ecosystem is still relatively young and so is the Ruby CMS world. It is a growing field and I believe that it has recently reached a maturity level that is good enough for it to contend on a high level. That is why I consider this to be a good time to embark on the type of project that you will see documented on this blog. After all this talk, what is this project I speak of?

The open source community prides itself on providing documentation and help of any form possible to its members. What I hope this to be is a source for people trying to work with a Ruby or Ruby on Rails CMS to get a feel for what they are getting themselves into. The idea is still developing but the early stages consist of the following:

Identify three CMS with a decent support/adoption community
Develop a small site using each of the systems (a website for a conference with some sort of user registration and social media integration)
Document the experiences
Come up with a comparison of each system using the fact that the site developed is the same and is used as a common ground for a fair evaluation of each CMS
Try to identify which CMS provided the best overall and specific experience

What I hope to gain from this is some personal experience in a new avenue of web development, but also share that experience with the rest of the community. Surely I am not the only one proposing such a task but I still hope that my efforts are fruitful and able to provide a better grasp of the technologies that are available for us to use.