[CALUG] Recommendations for a CMS

Bryan J Smith b.j.smith at ieee.org
Tue May 10 10:46:04 EDT 2011

Understand your delima.  There are Enterprise CMS solutions which are geared 
towards regulated entities such as corporations and agencies, let alone are 
typically powered by a J2EE compliant application server for all sorts of 
support.  Then there are plenty of Web CMS solutions that vary greatly, from 
J2EE down to a simple LAMP store and presentation.  You just want a solution, 
not a support nightmare.

As in many cases of "introducing/breaking down" a technoloyg, Wikipedia articles 
are actually very good at covering various concepts, and helping one know the 
terminology to use when looking for a solution.
- http://en.wikipedia.org/wiki/Content_Management_System  
- http://en.wikipedia.org/wiki/Enterprise_content_management  
- http://en.wikipedia.org/wiki/Web_content_management_system  

And is often the case, Wikipedia does have a good (even if incomplete) 
list/survey of solutions, broken down in several classifications:  

- http://en.wikipedia.org/wiki/List_of_content_management_systems  

Additionally, I want to point out one more aspect of any solution ... the 
cloud.  Yeah, I know, hate the buzzword as well, but CMS is one area where it 
actually applies well.  If you want to avoid a fixed infrastructure you have to 
maintain, then you might want to consider a cloud deployment, especially for low 
traffic where costs are minimal.

The Wikipedia article also lists a few options and providers for Software as a 
Service (SaaS), but it's largely incomplete.

The biggest problem with cloud deployments is that once you write for one, 
you're locked into that API, possibly even that provider.  Although there are 
different options, even some standards out there, everyone should be following 
what Red Hat is up to with DeltaCloud.  It's one of the reasons why Red Hat is 
getting very popular with major industry partners, both traditional solution 
providers and solely on-line ones -- from HP to IBM, from Amazon to Rackspace.

Red Hat's DeltaCloud is the only abstract API that lets you tap several, major 
on-line providers, as well as support a number of HyperVisors on internal 
systems.  I.e., you can use external or internal clouds as you see fit.  So you 
can start with a small, on-line implementation that doesn't cost you too much, 
but then move internal when the bandwidth charges start to rack up.  Although 
some portions of DeltaCloud are still Red Hat emerging technologies (ET), there 
are already several providers fully supported (using HyperVisors that vary from 
VMware to Xen) along with Red Hat's own KVM-RHEV for internal (with other 
HyperVisors in various stages, even Hyper-V).

Which brings me to Red Hat's free, on-line cloud for developer prototyping, 
OpenShift (fka Makara):  


OpenShift a generic Platform as a Service (PaaS) offering that costs nothing, 
and lets you try out various options on top of Linux, and migrate later to any 
internal/external PaaS with a DeltaCloud connector.  The idea is to develop and 
prototype on OpenShift, then move to what you want -- even non-Red Hat is your 
final choice of platform (i.e., there are even DeltaCloud connectors and related 
components in development for Windows, if you can believe that).  So if you're 
just trying to "get something running," check out Makara.  Again, still ET here, 
but it's usable today, and will let you "play with options" and get running now.

Just an option, if you don't have hardware lying around, and something you can 
build and move to another PaaS thanx to DeltaCloud when you do find something 
you like.  Red Hat is definitely not trying to lock anyone in, quite the 
opposite -- trying to address a major issue with prototyping in clouds right now 
(where other on-line options do lock you in).  Those who know anything about Red 
Hat's history on on-line ET it has created, but left to other providers to take 
up (e.g., Mugshot anyone?  A social network concentrator well before its time, 
its technologies now leveraged by others), should know this.

Bryan J  Smith       Professional, Technical Annoyance 
Linked Profile:     http://www.linkedin.com/in/bjsmith 

----- Original Message ----
From: Joe <joe_tseng at hotmail.com>
To: calug at unknownlamer.org
Sent: Tue, May 10, 2011 7:38:03 AM
Subject: Re: [CALUG] Recommendations for a CMS

"CMS:MS sites take us two or three days to develop, Drupal sites take about 
a week but require less maintenance in the long run."

Can you recommend any online resources or books that can help me understand 
Drupal and make my time getting started in the muck down to a week?

-----Original Message----- 
From: Michael Orlitzky
Sent: Monday, May 09, 2011 9:30 PM
To: calug at unknownlamer.org
Subject: Re: [CALUG] Recommendations for a CMS

On 05/09/2011 11:24 AM, Joe Tseng wrote:
> I recently took over management of a website for a youth
> sports/activities league/nonprofit from the original maintainer.  There
> are a number of activities for boys and girls and sometimes both;
> currently I am the one who takes updates from the league's commissioners
> and post them on the site.
> I have been looking at various possibilities of rolling out a
> PHP/MySQL-based CMS and all of them seem to have some kind of
> shortcoming.  I had considered Drupal but it looked way too complicated
> and was completely unintuitive.  Right now I'm considering Joomla
> because it can allow for contextual viewing/editing of content (e.g. a
> football parent can look at public and football-related content, but
> they can't see anything else; a football commissioner can see public and
> football-related content but can only edit football content).  It
> doesn't seem like it can create a contextual scheduling calendar.  I was
> also considering phpBB, not only as a forum, but also to have it drive
> the user management authentication and management.
> Has anyone done anything like this before and do you have any
> recommendations?  Is there a CMS that can do alot of what I'm looking
> for; if not, is there one that's easily extensible so I can make my own
> features?  Or am I simply better off designing my own portal from the
> ground up?

We use two: Drupal[1], which you've already met, and CMS Made Simple[2].

CMS Made Simple is perfect for small sites where there's a bunch of
content, and you just want to edit it. It's easy to edit pages --
there's a place called "Pages," and there's an edit button that does
what you'd expect. You can also create new users and set up permissions
pretty easily. Forms can be installed even by non-technical users, and
news, themes etc. can all be configured through the CMS with a little work.

Drupal on the other hand doesn't do a goddamn thing out-of-the-box, and
the things it does do are unintuitive. But, it's easy to extend, and the
idea of content/views is really useful once you figure out what they
actually do.

With content/views, you can e.g. create a content type called
"newsletter" that has fields for title, date, file, and so on. When the
user goes to create a newsletter, he's presented with a form that has
fields for title, date, file, etc. This turns out to be *much* easier
than having him edit the "newsletters" page, add a new bullet item in
the correct chronological order, put in the title, upload a file, and
link the title to that file.

In essense, CMS:MS will do most of what you want simply and
out-of-the-box. But the things it doesn't do are harder to implement.
Drupal is the exact opposite. CMS:MS sites take us two or three days to
develop, Drupal sites take about a week but require less maintenance in
the long run.

Both have decent core dev teams.

For what it's worth, we had to do exactly the same thing a few years ago
and wound up going with Drupal for the tac_lite module[3] which limits
access exactly how you described.

[1] http://drupal.org/
[2] http://www.cmsmadesimple.org/
[3] http://drupal.org/project/tac_lite

More information about the CALUG mailing list