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
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
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
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
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
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... -_-'
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
Mark K. Kim
AIM: markus kimius
PGP key fingerprint: 7324 BACA 53AD E504 A76E 5167 6822 94F0 F298 5DCE
PGP key available on the homepage
vox mailing list