[Actionchix] Choice of CMS

jennyw jennyw at dangerousideas.com
Mon Mar 20 09:21:16 EST 2006


I had hoped to setup a server this weekend w/ Plone for y'all, but it's 
not working out (other projects have run away from me). This coming week 
is pretty busy, so the next time I'd be able to set up a server is most 
likely next weekend. That said, there is a demo of Plone up at 
http://demo.plone.org, though, which should give you a pretty good idea 
of using it from a user's perspective.

A couple of us made a case for Plone earlier, but some people here 
probably haven't seen it (it was on volunteers). So here goes ...

Mary wrote:

 >This is the discussion I'd really like to get over fairly fast. At the
 >moment, the loose consensus view is Plone, primarily because the
 >current site is already on Zope and our current admins have some
 >Zope expertise.

The reason we suggested Plone was because, as Mary said, we're already 
on Zope and it seems like the easiest migration path. I'm not sure that 
Plone is the CMS to end all CMSes for LinuxChix, but it's a step up from 
where we are now. I think one thing we should think about is not only 
the CMS we're moving to in the near future, but also the migration path 
from that CMS to a future CMS. Plone and Zope are relatively easy to 
migrate documents from -- you have DAV and FTP interfaces, so you can 
essentially pull HTML documents out of them as if it were a file system. 
Also, there's an xml-rpc interface, and of course you can access the 
ZODB programmatically from within the projects.

 >Here's the requirements:
 > - ability to maintain current site (check www.linuxchix.org) structure
 > and content
 > - ability for multiple users to login and edit pages

Check. The current site is already in Zope and Plone is built on top of 
Zope.

 > - ability to have a front page newsfeed with RSS or Atom feeds

Check. I think there's a feed from the current site now that Mary or 
someone setup (it shows up on live.linuxchix.org, anyway).

 > - good support for our designers: ability to apply a skin across the
 > entire site

Check here, too. We can also have different templates applied to 
different sections of the site. For example, chapters could be given 
their own sections that have their own looks.

 > - mature codebase

Plone was started in 2001 and has been used in production by large sites 
for several years.

 >Here's some things that are nearly essential:
 > - ability to retain current URLs

Check, but I think this will be case with anything. As Clytie's friend 
suggested, we can set these up in mod_rewrite (or equivalent).

 >Here's some things that would be good:
 > - automatic (or somewhat automatic) index/sidebar generation
 > - calendar of upcoming events

Plone can do both of these.

 > - ability to manage multiple sites (on different domains) with one
 > backend/auth system -- chapters might like this

I'm pretty sure this is possible, too, but I haven't done it. I think 
the easiest way would be attaching them all to the same Plone instance 
and connect them using some mod_rewrite (with mod_proxy) magic. It might 
be possible to connect multiple instances with the same auth model, but 
I'm less clear about that.

 > - ability to either backend into a version control system or maintain
 > revision history itself

This is provided by a Plone product called EnSimpleStaging:

http://plone.org/products/ensimplestaging

I haven't used this myself, but I've talked to the developers about it 
and it sounds great (won't know for sure until we install it, though!). 
This provides both versioning and also the ability to stage changes. In 
other words, a contributor might be able to edit a page but the changes 
wouldn't be published until approved. I'm not sure whether we'd use it, 
but, if for example someone was running a course and wanted to open up a 
document for a lot of people to edit, this might be a way to have them 
see all the changes before they go up.

 > - ability for people to use their own editor on their own machines and
 > then send/upload/save pages onto the site

Plone supports this in a variety of ways. You can type your HTML in and 
then we can run it through a filter like Tidy. You can also access 
content using Web DAV -- even mounting Plone as a file system on your 
machine. Plone also supports external editors, although it's not 
something I've used.

 >So, are there any standout alternatives to Plone for this? Here's what
 >we need to know in your response:
 >
 > 1. What language is it written in?

Python and Zope (Zope is written in Python, too, but it's also kind of a 
world of its own).

 > 2. Which of the above features does it have?

Everything.

 > 3. Have you used it?

Yes. I was the project manager for a large Plone implementation, and 
have used Plone for a couple of smaller setups, too.

 > 4. Have you used anything else? How does it compare?

I looked at a bunch of possibilities, including Drupal, before choosing 
Plone. At the time, Plone not only looked like the best of the bunch, 
but addressed content management with a higher level of sophistication 
than the PHP CMSes I saw (Zope has another CMS called Silva which also 
looked good, but it seemed Plone was more appopriate for the project I 
was working on). They were the furthest along in terms of accessibility 
issues (first with tableless layout, first with WAI-AA, etc.), creating 
custom content types, and having search-engine-friendly URLs. The DAV 
and FTP interfaces also seemed unique to Zope-based CMSes. Since that 
time, other CMSes have come a long ways, with Drupal being a clear 
leader (e.g. CivicSpace), but I haven't kept up with them. I have the 
impression that the philosophies of Plone and Drupal are pretty 
different, though -- most of the big Drupal sites I've seen seem to use 
blog aggregation a lot. I know some people who have been excited about 
Apache Lenya, but not being a big Java fan I haven't looked much into it.

FYI, Plone (and Zope) are different from PHP-based CMSes in that they 
typically don't run directly through the Web server using some module 
(e.g. mod_php). Instead, it runs as a separate server process and can 
listen on multiple ports (e.g. one for Web, one for ftp, one for WebDAV, 
etc.). You would then setup Apache, Lighttpd, or whatever Web server to 
proxy to the Plone/Zope server (I think we skip this step right now -- 
judging from the HTTP headers, we have direct access to Zope w/o another 
Web server in between). Plone/Zope support advanced caching, which you 
can take advantage of by setting up your Web server with caching. You 
can also setup Squid in front as a Web accelerator (this is what we did 
for that other site I mentioned). If you use caching, you can also have 
a non-cached interface, say on edit.linuxchix.org, that can even display 
a differnt look and feel than the public site.

I don't think Plone is perfect, by the way. I do think it's a pretty 
good CMS that meets the needs Mary outlined above, plus is a natural 
step up from what we're using now. I'm sure that we'll eventually have 
more requirements, hence my suggestion about planning to have a 
migration path from whatever CMS we choose. In an ideal world, I'd love 
to develop a custom solution with other LinuxChix, not so much because I 
think we can do better than any other CMS project, but because I think 
it'd be a great learning and teaching experience (plus more targetted to 
our specific needs). I suggested running a Ruby on Rails CMS development 
project as a long-running course earlier. This might be a good idea 
whether it's used by LinuxChix or not, since there's a lot to learn 
about programming, cooperation on an open source project, Ruby, Rails, 
Ajax, and Web technologies just by working on a project like that 
whether or not it goes anywhere. If anyone else is interested in getting 
a course like this going, please let me know and we can work on 
proposing something together (Chris mentioned she's interested, too).

Jen



More information about the Actionchix mailing list