[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