l i n u x - u s e r s - g r o u p - o f - d a v i s
Next Meeting:
July 7: Social gathering
Next Installfest:
Latest News:
Jun. 14: June LUGOD meeting cancelled
Page last updated:
2004 Jun 19 14:18

The following is an archive of a post made to our 'vox mailing list' by one of its subscribers.

Report this post as spam:

(Enter your email address)
Re: [vox] Content management system recommendations
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [vox] Content management system recommendations

Thanks, everyone, in your CMS recommendations.

After reviewing many of them, I've found Mambo Open Source to be the most
appropriate.  It lacks in a few areas (especially security and some
extended features of the add-ons) but things are put together logically
enough that I can extend on it and secure it down with a little time.
The real seller was the awesome administration panel and the
multi-language add-on.

Here are the CMSes that I reviewed and rejected:

  Drupal - A close second, but the administration tool was too
    complicated. Couldn't even publish a single page and the
    interface didn't make me want to spend the time to figure it
    out.  With an interface like that, I couldn't ask people with
    less knowledge than me in web publishing to manage the site
    after I'm gone (which is in about two months.)

  eZ publish - Too slow. Period. Approximately three second rendering for
    each page.

  WebGUI - Unlike the other CMSes I tried, this is PERL-driven, which I'm
    fine with (though I prefer PHP for manageability since I know PHP
    more.)  But setting up all the PERL modules was a pain. When I finally
    got to a point where I could render the first page (CPAN rules!), it
    displayed lots of errors (darn it!)  After some reading I found this
    CMS is for a large enterprise company, and it expects to be the only
    thing running on the webserver.  This is not what I need, so I dropped
    it. But this system seems to be the most flexible, and would
    take a second look if I ever setup a stand-alone, non-shared
    webserver. *But* this system is supposed to be slow without some

  phpWebSite - In the true sense of open source, initially developed
    at a university for internal use, then gained support to become an
    open-source CMS.  That's probably the primary selling point.  But
    it still seems to be in its infancy, especially it comes to inter-
    nationalization.  Since I need internationalization badly, I didn't
    look too much more into it.

  PHP Nuke, Land Down Under - Though both are free for non-profit use,
    neither are open source, and modifying at least some portions of the
    system (like removing the copyright notice) requires a fee.  I might
    have looked into these more but I didn't feel very welcome and felt
    somewhat restricted and commercialized using them.  Probably would
    have looked more into them had I been more desparate, but I wasn't.

Also, when I was evaluating each CMS, I found that many CMS are
news-driven -- Each page you make, for example, is considered to be a news
article, so each article is stamped with a title, a date, and the author.
This is very annoying for me who just wants to make a normal website
without driving the whole site with news.  Even the front page gets a
little header with a tiny title, author's name, and a date, with no sane
way to make a normal, plain PHP/HTML page with a little introduction to
the website.

So while I was evaluating each CMS, any CMS with a news-driven homepage
was quickly moved down on my list of viable candidates.  This includes PHP
Nuke, Land Down Under, and Drupal.  The ones that aren't news-driven are
eZpublish, Web GUI, and phpWebsite, at least from what I could.  I
rejected the latter three (eZpublish, WebGUI, phpWebsite) primarily
because of the cons I list above, and I rejected the former three (PHP
Nuke, Land Down Under, Drupal) primarily because of the news-driven-ness
with less weight given to the reasons I mention above.

Mambo Open Source, my pick, is actually news-driven also, but I didn't
realize that because Mambo's own homepage isn't news-driven.  Well, that
turns out to be because Mambo's homepage (mosforge.net) doesn't run Mambo,
but instead runs G-Forge, a Sourceforge-fork that lets you create and
track software projects.  (In this case, to host the Mambo project as well
as all of its add-ons, which I must say gives me a very nice interface
from which to download add-ons and create some, too, if I ever choose to
do so.)

Anyway, it wasn't too hard to figure out how to turn off the news-like
stamping, hence my reason for staying with Mambo Open Source.  Again, the
administration tool is very easy to use and relatively easy to understand
with a little time.  My only problem with how you control the stamping is
that you have to turn it on/off for the entire website -- you can't pick
and choose the which sections get stamped articles and which don't.  So
now none of my news pages have stamping, though I'm sure I can modify the
code to adjust that should I want to.

Here are some pros/cons about Mambo:

  - Great administration interface, if I haven't mentioned it already.
    They call the administration interface the "back-end", and this is
    where you can do anything, and comes with a separate log-in page.
    But you can also do things from the "front-end", too, where normal
    users can log-in and visitors can browse the site.  Unfortunately,
    however, not all functionality of the back-end is available to the
    front-end, so even if I want to transfer certain features to users,
    I can't.  But all the important things, like publishing pages, can
    be done from the front-end, and the things I think are important
    that can't be transferred will need some coding.  Again, Mambo is
    very well organized so adding such features shouldn't be too
    difficult, though I may have to sacrifice forward compatibility.

  - Nice internationalization control.  I would like it for the content
    to be translatable by the person submitting the page from the
    front-end, but it's currently possible only from the back-end.  I'd
    like to see it fixed, and I might take a stab at that.

  - User control.  This is a little confusing.  Each user is assigned
    to a group, and permissions can be controlled at the group level.
    Unfortunately, there are only set number of groups:

      1. Visitor: People who hasn't logged in.

      2. Registered: People with the least amount of privilege.
      3. Author: People that can create pages.
      4. Editor: People that can create pages, and edit other people's
      5. Publisher: People that can create pages, edit other people's
         pages, and make them appear on the website (pages are invisible
         until they're marked "published.")

      6. Manager: People that can do all of the above and have minimal
         access to the back-end.
      7. Administrator: Manager + do almost anything in the back-end.
      8. Super Administrator: Can do anything.

    #2 to #5 are called "front-end users" and #6 to #8 are called
    "back-end users", for obvious reasons.  But #3 to #8 are also called
    "special users".  So basically, there are 8 levels of users, but
    each (except #1 which is a group all on its own) belongs to two groups
    -- front/back-end, and registered/special.  Confusing?  Yeah, it is.

  - Components - Things you can be used to extend the website. Awesomely,
    these things are *.zip files that you just upload.  The website
    takes care of unpacking and installing them.  Probably the best
    system I've seen, and many of the interesting components are
    internationalized, and though many don't have Korean that's easily

  - Modules - Things that go on the sidebars.  Also uploads as *.zip
    files.  Unfortunately, many projects use both components and modules,
    so you need to upload both *.zip files instead of simply uploading

  - Patches - Things to extend the website that aren't possible with
    components.  You have to manually upload these and unzip 'em into
    the directory; there is no `patch -p0 < patchfile.patch`.  Too
    many of these -- even two of 'em -- or even mismatched versions
    can break the website.  I've had to do some manual merging and
    file verifications to patch things safely.

  - User profile - Very minimal. There's an extension patch that isn't
    very nice and I'm gonna try to fix that.

  - User registration - It's either open-registration or admin-controlled
    registration.  There's no "open but needs approval first"

  - URL - There's no good URL organization.  Things are all in the
    format, "http://www.website.com/index.php?blah=blah2&blah3=blah4";.
    There's an option to make the URL not use GET-style arguments to
    get search engines to index the pages, but the URL still looks bad:
    "http://www.website.com/blah,blah2/blah3,blah4/";.  And not all modules
    and components adhere to such syntax, so sometimes you click a page
    and it goes right back to the GET argument style URL from time to
    time.  Quite annoying.  And because of this craziness, the most
    reliable URLs are absolute URLs, which of course means you can't
    mirror the site.  The website may not even be movable if one of these
    absolute URLs get into the database!

  - Security - There's not much of it. Each directory has a blank
    index.php, but that's it.  Any file is accessible unless you secure it
    down.  Logins are plaintext, and although I tried to at least put the
    back-end on SSL connection (which is on the same server but under
    a different domain name for us), it barfed because it jumps
    back-and-forth between the back-end and front-end in order to log into
    the website and the cookies (which is also required for logging into
    the back-end) don't transfer well between different domains.

  - Add-ons - Very nice support, but most add-ons don't have all the
    features I want.  But as long as the framework is there at least
    I can extend on it.  I'd especially like to see some extended user
    profiling, media galleries (not just photo galleries),
    user-controllable i18n content.  Also, some components let you enter
    text using HTMLArea (allows the user to see a word-processing-like box
    instead of a plain text box) but some use BBCode.  It's a little
    inconsistent.  Oh, and the smilies are inconsistent, too! -- some
    components use the yellow smiley icons, and some use green, etc.,
    because each comes with its own iconset.  Kind of annoying.

There are some nuances and such, but for now I'm willing to deal with
them.  Although the back-end control comes with a database backup
functionality, I got phpMyAdmin installed so I can get a little more sane
control over the database... -_-'

-Mark ^.^v

On Fri, 11 Jun 2004, Rod Roark wrote:

> On Friday 11 June 2004 04:52 pm, Mark K. Kim wrote:
> > Does anyone have a recommendation on website content management systems?
> PHP.  ;-)
> Seriously, I'll be interested to hear what you come up with.
> -- Rod
> _______________________________________________
> vox mailing list
> vox@lists.lugod.org
> http://lists.lugod.org/mailman/listinfo/vox

Mark K. Kim
AIM: markus kimius
Homepage: http://www.cbreak.org/
Xanga: http://www.xanga.com/vindaci
Friendster: http://www.friendster.com/user.jsp?id=13046
PGP key fingerprint: 7324 BACA 53AD E504 A76E  5167 6822 94F0 F298 5DCE
PGP key available on the homepage
vox mailing list

LUGOD Group on LinkedIn
Sign up for LUGOD event announcements
Your email address:
LUGOD Group on Facebook
'Like' LUGOD on Facebook:

Hosting provided by:
Sunset Systems
Sunset Systems offers preconfigured Linux systems, remote system administration and custom software development.

LUGOD: Linux Users' Group of Davis
PO Box 2082, Davis, CA 95617
Contact Us

LUGOD is a 501(c)7 non-profit organization
based in Davis, California
and serving the Sacramento area.
"Linux" is a trademark of Linus Torvalds.

Sponsored in part by:
Appahost Applications
For a significant contribution towards our projector, and a generous donation to allow us to continue meeting at the Davis Library.