CMS Shootout, the book (deprecated)

This tree is deprecated. We chose Drupal.

CMS Shootout!

The contenders:

Shootout summary

Please add information/properties as you see fit.

Property Joomla! Drupal
Must haves
Easy to update content Yes: web interface Yes: web interface
Timely security updates ?? ??
Post meeting information Yes Almost: issues with formatting front page
Post maps/photos for meeting Yes Yes
Highly desirable
Mailing list/forum integration ?? Yes
Match meeting topics and presenters ?? Maybe -- event module
Dynamic library page ?? Yes -- steph's plugin
Professional appearance Yes Sort of: (all Drupal sites look similar)
Easy to upgrade Yes (?) Yes (?)
Easy to customize look and feel Yes Not really: there are themes, but we do not know how to
customize the structure
Calendar support (website events) Yes Yes: event module
Code quality Does not validate Validates as XHTML strict
Nice to haves
Easy input syntax ?? Yes: bbcode plugin
User blogs Yes Yes
Modular design Yes Yes
Text-based browser support Almost: Front page Javascript Yes: tables w/CSS
RSS feeds for content ?? Yes, but not for specific forums.
Wikis ?? Sort of: book module
iCal support for calendars This should be a wash. phpicalendar will install most anywhere. All built-in calendars seem to have a high degree of "suck." --richard
Private Messaging yes IIRC Yes
Group mailouts Yes ??

CMS decision

Include your vote and any supporting evidence you would like to give.

marko votes: Drupal
marko says:

richard votes: Drupal

richard says:

john votes: Joomla
john says:

Website Details

Front page

What should the front page contain?

Meeting details: next meeting, future meetings.

Feed of what is happening on the mailing lists/blogs/forums.
(I liked the feed in the old PHPNuke site -- pnijjar)

I like the front page very sparse. Like a good business site. Just who, what, where, when, and why in
the most common form. Everything else should be linked below that. --richard.

Links to other content: library, forums, meeting location, about us, site map

What should other pages be?

(Also see: Child page)

What access rights should people have?

pnijjar votes: not everybody should have admin access, but every member should be able to post content to wikis/blogs/forums. Non-members should be allowed to read everything but not post everywhere.

richard votes: concur. Except the wikis. I don't like wikis. I don't know why. Perhaps because the remind me of clowns.


Do we need forums?

Maybe a web interface to mailing lists is good enough (see, for example, the Linux Kernel Mailing List frontend.

Counterpoints: the LKML interface is one-way, I think. People cannot POST to the list using the web interface.

Newbies tend to prefer web forums to mailing lists. Integrating the two would allow experienced people to have more interactions with newbies.

Should forums exist independently of mailing lists?

pnijjar votes: no. It is better to have no forums rather than forums that are ignored. Integration or death!

richard opines: Let's consider that then. Whack the forums. Use that front page real estate to point to the mailing list only. Less maintenance required. No tricky integration required. Just use a nice mailman (or whichever) page to access. Make the archives prominent, too.

What forum categories should exist?

pnijjar votes: keep it minimal -- announcements and discussion, both tied to the mailing lists. If we need further forums then we can create them later.

richard votes: Okay. Announcements and Discussion is fine. Topic / thread separation by Subject: line seems a natural addition and an easy filter to apply with existing tools. But let's keep in mind that we can get rid of the forums too.

Library module

The library module will keep track of what books/media are in the LUG library, and who has checked what out. The purpose is to make the library more accessible so that it gets used more.

What capabilities does it need?

Should library entries support comments?

steph votes: yes, so that people can post reviews of the books.

pnijjar votes: undecided. Maybe people could post reviews to the forums? Maybe to their blogs?

richard votes: no. I like the library. I appreciate the work that went into making the module for us. I haven't heard members asking to review books. I think it will go unused.


Drupal deals with taxonomies and categories. It may soon have support for tagging. What categories should we have?

Type tags

These tell us what type of posting the person has made.

Items: "review", "howto", "question", "announcement", "event", "meeting", "job posting", "cry for help", "editorial", "rant"

Next attempt: "howtos and tips", "LUG related", "employment", "reviews and editorials", "help me!", "buy and sell", "links and resources", "other events"

This is not perfect but it does have 8 items and not much overlap. It is not clear where politics and ranting would fit in. I am tempted to put something about "announcements" but that should not overlap with "LUG related".

Non-items: "tip" (same as "howto"?)

pnijjar says: we probably would like these to be disjoint if we are making a vocabulary set -- there should not be much overlap between the words.

pnijjar says: we can combine related terms into one category. Maybe we could arbitrarily say we want between 8-10 categories total? Keep in mind that we can create new categories as we go along.

Somebody posted the following list (I think it was me --richard): "business", "expert", "for sale", "hobbies", "howto", "link", "member announcement", "meta LUG", "newbie", "play", "presentation", "regional", "tip", "wanted", "work".

richard throws the list of distros in pnijjar's direction: While we at KWLUG are distro-agnostic, apolitical and care not at all for the whole vi vs. EMACS fracas, is not the ability to search for things related to a specific distro important to our members? From Newbie to Wizard, distro choice implies many things about how you will do things. One taxanomy must be distro. It can be ignored for non-distro posts. And multiple items can be selected when overlap is appropriate.

richard continues; it's a caffeine thing: Taxonomies will also offer guidance to members / posters. Is it possible to select both "Wedding announcement" and "For Sale" on the same blog post? No? Then perhaps I should reconsider offering my new spouse for sale on the LUG.

Content tags

These tell us what the content of the post is about.

Items: "hardware", "server", "desktop", "distro", "application"

pnijjar says: I don't know how useful these will be.

richard asks: hunh. Is this that tagging thing again? Like taxonomies / categories this is useful if it makes searches easier. If it is only for those infinite font collection tag clouds, I think we can leave it off KWLUG.

Book Module

richard asks: should we allow grandchild pages?

pnijjar says: When pages are getting very long maybe it makes sense to have granchildren. Until then why not keep things on a single page?

richard replies: I think that was posted to see how the grandchild page / comment displayed. I have nothing against many levels of heirarchy when it makes sense.

pnijjar asks: should we use the book module or the wiki module?

pros of book: it comes standard, it supports revisions.

cons of book: it doesn't have Wiki-syntax, it does not have nice hyperlinking abilities.

pros of wiki: it may allow wiki-syntax, easy linking, it's called a "wiki"

cons of wiki: it is an external module, it is not clear what the advantages are over book.

richard says: Pros of book module. It's not a wiki.

Now pnijjar says: I was wrong. The book module wants every new header to be on its own page, I think. That implies we need lots and lots of grandchild pages.

richard can't shut up: That's okay. Shorter pages are easier to keep the paragraph tags straight.

Things to Do/Fix

Add to this list as you see fit, and sign up to do things!

New Website: Possible Feature List

What features would you like to have on the new KWLUG web site?

Add a potential web site feture on each child page. Arguments for and against on the grand-child pages? Is this a good way to use the book module?


Provide a calendar display of past, present and future events at the LUG.

Discussion Forums

Threaded Dicussion forums are a prominent feature of the Old KWLUG web site

Threaded discussion through a web GUI interface appears to be popular with those who first contact KWLUG. Is this because the registered web forum is the best place for their initial contact? Or is it because it is the first type of contact presented to the new visitor to the KWLUG site?
Are the threaded forums required? Would a web GUI interface to the KWLUG mailing list (r/w please!) offer the same ability to post from a browser, but allow contact with a larger audience (namely the mailing list)?

KWLUG Member blogs

KWLUG Member Blogs

Drupal has made the possibility of individual blogs for each KWLUG member a possibility. What are the advantages and disadvantages of KWLUG member Blogs? What is are the uses for a blog, versus a forum post, versus a mailing list post?

Member blogs have their own RSS feeds. Interested readers can syndicate just the writers they choose to follow, or all of the KWLUG bloggers at once.

Mailing list

The new web page could have an associate mailing list

Okay, this page is a softball.
The mailing list subscribe, confirmation and unsubscribe controls should be available from the web site. The archive should also be available.

Where to find us

We meet monthly, usually on the first Monday of the month. Please check the Next Meeting link for details. There is a parking lot behind the building and parking after 6pm is free (last time we checked). We meet at:

The Working Centre
43 Queen Street S.
Kitchener, Ontario

Want to find us on a Map?

Meetings are free and open to those with an interest in Linux. All levels of Linux experience are welcome at our meetings. Come on out and meet us.